This is the first in a series off entries based on harvested lessons from agile teams I'm working with. Some of the findings are common sense but so many times common sense is not commonly applied. Hope you enjoy the series.
At a recent retrospective one of the teams challenged the value of the planning tool being used. The product release programme was using Rational Team Concert for work item management and planning across the global teams. It was being used in fairly typical way showing all the epics and user stories by product area split into a product backlog and those for the current sprint. However due to a misunderstanding, some of the technical teams had a separate plan called their "bubble chart". This chart showed all of the stories they had left to do, broken down by months, they were told in agile you couldn't do this. Some but not all of these items were in the official plan. Then there were was considerable technical debt from the previous release to dig out plus defects to fix from this release. None of this additional work was in the official Rational Team Concert. Leaving it invisible to the teams and senior management and killing any chance of predictability.
With this setup there was no way of finding out, in one place, where the projects were and then rolling that up to where the product release was. Without all of the information the planning tool was becoming a burden that added no perceived value to the teams.
Many teams I work with still have more than one plan either knowingly or unknowingly. They have a formal plan that shows the project managers view of the tasks they believe are left to complete. The developers then have a list of additional work they need to do as a group and then individuals have their "to do" lists on top of that. Ditto for the testers and so on for the other roles. In reality the "to do" lists are the real plan that we're working to, like it or not. That's the work the team will actually do.
Ironically the management group were equally frustrated because they were constantly chasing the team to update RTC and didn't understand why they weren't. They didn't know about the other plans, the real plans, the "bubble chart" and "To Do" lists. The result was that effort was being wasted and any level predictability was missing .
From this retrospective the key things the team did was to get management to accept their "bubble chart" into the main plan with all of it's "extra" activities, so that there was now only one plan.
The other key thing was to explore how to simplify the configuration of Rational Team Concert so that it's as quick enough to be used as a "To Do" list tool.
A programme or project must have only one plan. The plan can be at many levels of detail but it should contains all the work needed to be done at the level of accuracy and precision appropriate for where the project is and for as far ahead as it's possible to plan. The plan should be built up from the individuals "to do" lists. The plan must be visible to the whole team.
So in summary what it is typically missing:-
- Backlog work items with sizing estimates for the release
- Developers "To Do" lists some of these related to work items but some were work the developers wanted to do (it's also easier to identify potential over-engineering if there's only one plan)
- Non-development tasks including setting up of test environments
A plan that doesn't include all the effort required to complete the project has little value to anyone.