Challenges in Release/Milestone Planning

2008-12-17

Dictionary: Iterative Development, iterations, Business Analyst (BA), milestone planning, release planning.

We refer to our milestone plan as the little baby; not because it’s a lovable thing, but because it’s still in the very early stages of development. Like a baby, our plan needs nurturing, food, a safe place to live, and lots and lots of attention; without these basic necessities it will fail to thrive and wither away.

Surprisingly, on my current project it’s been difficult to find these basic necessities – mostly because of an absence of business involvement on the project. This is a critical learning – that without supportive business engagement from all levels, you can scavenge daily for the food the baby needs, but scavenging will continue for the duration of the project until something changes.

Regardless, we started a grass roots movement to feed the baby. Specifically, we set up time in one of the large boardrooms (with whiteboard walls), invited business analysts (BAs) from all teams, and sat down for an entire week to work out what each of the teams were working, where cross team dependencies exist, and how we could collaboratively work together.

What came out of this movement were a whole host of learnings that can be beneficial to anyone in a similar situation. Some of these may seem intuitive, but in an organization that has a tradition of siloing teams and rewarding cowboy behaviours, these learnings were eye opening to those involved.

The Wonderful

  • In bringing teams together to talk collaboration and alignment, what came out were discussions of team blockers and cross team issues. Further to this, the group quickly discovered that these issues could be resolved as a group and not in isolation. On a handful of teams there was an immediate (and tangible) jump in productivity.
  • In identifying cross dependences teams were able to make plans moving forward and solve issues around Team A waiting for Team B to complete tasks so everyone could work effectively at the same time.
  • There was a general recognition of a common path with common goals and issues.
  • People learned a new way of doing their job. More than one light bulb went off during the process and the ah-ha moments spread like wild fire.
  • There was a moral boost amongst people who felt they were spinning their wheels in individual silos. People felt like they were finally moving forward and that their knowledge was being used.

The conversations that started in these planning session were beneficial to the project as a whole and even now (a month later) conversations that started in the session are still going. After a week of working session things were not over and even though we’d made process there was an undercurrent of activity that derailed this progress.

The Not-So-Wonderful

  • Progress made at the BA level was diminished because there was no overall buy-in. People switched back to previous work habits when they received negative or passive feedback.
  • Constant and continuous path changes derail any type of planning and creates throw away work. This ties back to a general disconnect from the program as a whole.
  • Even after working together for a week some people still believed that one person should be responsible for release planning without much interaction with the business. This ties back to rewarding a culture of cowboy/hero behaviours and an acceptance that this is how things get done.
  • There was a constant stream of resistance to adopting iterative development practices. Alternatively, there were many misconceptions around how iterative development is done. Some teams came into the meeting thinking they already knew what to do and were defensive; and, one team refused to send someone for this same reason.
  • There was no high level program focus / goal from above. Pinning this down was often like trying to hit a piñata in a dark room full of people and there was a general feeling that program planning was not viewed as important. As a result, the business switched focus periodically and people abandoned planning activities with ease. The ultimate result is a reactive office culture.

For those in the room for our planning session, one of the light bulbs that went off was the realization that teams can’t work in isolation. However, on the floor, buy in was non-existent. As a result, there was constant effort put into foraging on a daily basis (remember the baby) – but nothing permanent and consistent came from this.

Hindsight is 20/20 Recommendations

If we could do this all over again, what would we do?

  • Developing a release plan should never be done in isolation from the business. There should be business involvement, an analysis of the costs, and an understanding of organizational pain points early on before moving forward.
  • I cannot stress enough the importance of putting the business knowledge people with the developers and getting them working together. Further to this, teams should develop a common language (business and working terminology) and make sure everyone understands this common language.
  • Understand the roles people play at the different levels (e.g. manager level, iteration level, developer level); put this into writing and constantly promote/socialize. In understanding, people tend to take ownership of their role and there is less confusion around how teams work together.
  • Having uninterrupted time and space to work through a plan is very important and will make the process go a lot faster. Put the planning wall in an open area (not in a room used for meetings) so it can be viewed and easily accessed by everyone.
  • Start looking at the plan early in the game. One constant struggle for us was trying to re-align teams that were developing in isolation. In some cases it took months to re-align, if it happened at all.
  • Quickly develop a healthy backlog of stories or capabilities (epics) that can be broken down into stories. This gives people something to focus on.
  • Determine how to bring release plan information back to teams and managers early in the process so they are in the loop. Marketing the benefits in a way that people understand and retain is essential.
  • Work out a plan for handling counter-productive behaviours. Recognize patterns of behaviour and do what you can to head them off.
  • Finally, stick with it… constantly. Follow up with some sort of weekly update stand-up to see how iterations are progressing.

The question I ask the most these days is: how would you have approached project planning differently given what you know now? It’s really hard to understand some of the challenges we face unless you are directly immersed in the project, however, I’m interested in what people have to say. Any words of wisdom out there?

You may also like...

Leave a Reply

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