Release mgt. is that agile?

Yesterday I got the question “is Release Mangement agile”? As I understand this question we could ask “is predictability of releasing business functionality possible to control”, so this blog will deal that is question.

Yes, it is possible and yes it is agile thinking too. Remembering what agile is about I like to quote the agile manifesto “Responding to changes over following a plan”, it dosn’t say “Responding to changes don’t follow any plan”. This is very important when interpreting the what agile is, because as you lay you focus on ex. Responding to changes you still have to have a plan, a goal, a vision, but don’t make the plan comprehensive so you don’t feel like changing it when the business like to change any little bit in the scope.

You can plan ahead and still welcoming changes as long you don’t change the scope doing the scope. “Responding to changes” is also focusing on getting feedback as fast as possible so we can inspect this experience and adapt to this knowledge, this could be testing early securing fast failure, Continuous integration so teams integration happens constantly, team retrospective and team demo that provide vital information for the team to handle for the next iteration.

I like to give one example one how release management can be executed (on a high level).

The Product Vision we lay out the target or what we expect the future will look like and already now we try to control the process forward trying to reach this target. Yes we will be wiser as we go along but for now this Product Vision (or Part of product Vision (POPV)) is the best we have.

Now the Product Owner starts the Product Backlog and as the backlog evolve the items on the backlog is GROOMED first by the stakeholders in workshops where trying to cut the releases in a vertical cut (providing customer value in each release) instead of the horizontal cut (providing finished functions that alone bring no customer value leaving the process reaching a milestone instead of a release). Helping you to make this vertical cut you can use many methods – I recommend User Story Mapping.

There is no easy rule for which release in a product vision (POPV) you should work on first, but if you what to be transported from one place to another (A to B), you don’t need to do this in a BMW but can get it done in a LADA (smaller release and a lot of customer value…. not so much coolness points, but is that important for the customer there have the need for transportation?

Now the hole predictability is depended of the quality of the product backlog so if you want predictability you must have a good well Groomed backlog meaning it is appropriated Detailed, Emergent, Estimated, Prioritized (DEEP). Please mark – This is a point of failure! You would like the developer team to use around 10% of their developer time to Groom, thats a lot of time to use upfront. Later in this blog I try to explain why. Some might say that this is design upfront – I say that it helps us the be able to gain the TRUST by management because this is the only way we can be sure to “walk the talk” (personal integrity) about what we promises every sprint to deliver (see more about grooming)

Now we have a backlog that are DEEP meaning that the items in the backlog for the next iteration is groomed and “Ready Sprint Planning” because the developers also has worked with these items and found implementations details, estimates and risks. Estimates are in man days and we know how many man days we have available in the sprint, so we can plan what is expected outcome of the sprint. This is close to the standard process of scrum planning and there is no magic here. Now if you need a sprint more to predict you need to make that scope DEEP and so fort. The point of failure here is to make sure that the team are able to deliver what the plan and commit to…. yes COMMIT TO have done-done in the end of the sprint.

Now we got the planning, the executing of the developing with the commitment and the scope cut vertical into customer value focused releases. By knowing the velocity of the team in average (work done during a sprint) and knowing the estimates of the backlog items by fine grained groomed item equals fine detailed estimates while coarse-grained items has a rough estimate with much higher risk in estimate.

As we go forward we groom more and more coarse-grained items into fine grained items with better estimates demands us to refine and evaluate our release plan making it constantly change as the environment around the plan changes.

Release planning is done by Product Owner and stakeholders either using the User story mapping or just paper cards where we get the first priority with the only variable as Customer value missing the cost. The Release plan has a variable uncertainty as we progress. The releases in the end is low prority and we have very little knowledge of these. The nearby release is pretty predictable while the release hereafter is unsure. We have to accept this uncertainty because if we don’t have a release plans we can’t really inspect and adapt the release plan to our continuously changing reality.

Remember at the single point of failure for making a predictable plan is, if the GROOMING isn’t done thoroughly Product Owner and by developer team.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>