Enterprise agile – Part 1 : Preplanning

This post is all about how to “square the cycle”: adopting Agile practices in an enterprise company. Here I will share with you my scrum team’s challenges, dilemmas and conflicts – and hopefully some solutions – that stem from developing new software in HP using the Agile and Continuous Delivery (CD) development methodologies.

 

About Me: Alon Zanbar, feature team lead at HP Software. I have been practicing Agile for the past two years while struggling against diehard waterfallers (including myself).

My Scrum Team: A feature team of 4-7 talented developers who, for the past 2.5 years, have taken part in the development of HP Agile Manager.

 

Post 1:  Pre-planning

 

The first ritual in our sprint life cycle is pre-planning. This ceremony (which is defined by numerous Agile/scrum experts – see here for example) is a relatively new component in our Agile-based development.

In the past, each of the teams (3-5 developers) took ownership of specific areas in the product, and in time developed expertise around these areas. This situation often led to anomalies in the backlog execution. For example, one team would handle low priority items, while at the same time another team struggled to complete top priority user stories. In some cases those gaps where identified during the sprint when there was little or no time to change the plans. In other cases we identified the gaps only in later stages of the release, which resulted in not delivering the product according the predefined criteria. This situation led us to two conclusions:

  1. Strict “by area” division is a bad practice in the long run. I may develop this idea further in a separate post.
  2. If we address the first conclusion by sharing our responsibilities across the entire product, we must coordinate between the scrum teams before the beginning of the sprint. This is where pre-planning comes in.

 

So what is pre-planning all about?

  1. Pre-planning takes place one day before the team planning. By this time the teams know (almost) exactly what was accomplished in the previous sprint, and what will be postponed.
  2. The participants in this meeting are the scrum masters (mostly TLs, but this is a matter for another post…) and the PMO.
  3. Before the meeting the scrum masters validate their capacity for the next sprint, and move all the non-done stories to the next sprint’s bucket.
  4. During the meeting the PMO outlines the priorities for the next sprint, and reviews the stories that the group is likely to be capable of delivering in the next sprint (based on its average velocity in the previous sprints).
  5. The final stage is the story allocation. This is the trickiest step, but also the core of the pre-planning. In this step each scrum master “grabs” the stories that most suit him/her from the top of the backlog, and fills the team’s estimated capacity. This initial distribution serves as the basis for the detailed sprint planning that follows within each team, but should not be binding. Therefore, if during the team planning it turns out that the team cannot commit to completing one of the high priority stories, the team’s scrum master can notify a peer scrum master, and suggest that he take it on, knowing that in the pre-planning he took stories with a lower priority.

 

Now, I think that the most challenging part of this methodology is trying to avoid imposing the pre-planning “plan” on the team; to not, even unintentionally, turn the pre-plan into the actual plan. My rule of thumb to prevent this from happening is “plan freely”: do not consider the pre-planning during the planning whatsoever; just view the backlog (filtering out what was already taken by other teams), and plan regardless of what the scrum master took in the pre-planning.

 

That’s what I currently have to share on our pre-planning ceremony. In my opinion it’s an essential stage of the scrum for large groups. I guess that with time, after I gain more experience with pre-planning, I will be able to share some more insights. So please, fellow Agilers, let us know what you think about this topic: Do you pre-plan? What do you think about the way we do it? Anything you have to say on this issue is important to us.

 

Post author: Alon Zanbar

Labels: DevOps
Comments
RulyWeisbach | ‎05-27-2013 01:42 PM

I defiantly agree with the approach that the guiding rule should be backlog priority  and not division by area but assuming switching between teams is not always possible we can reach a situation where team is taking high priority feature even if its bad fit

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Seasoned architect with over 12 years of experience in the enterprise software business, contributing to setting the roadmap / vision, high ...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.