What is technical debt:
Any code violations, undocumented code, lack of or less coverage of unit tests, lack of integration testing, build deficiencies, lack of code review process resulting in any or all of the above. In short, any areas that that cause impediments in delivering quality software.
Identify and deal with it:
Help/Coach the team understand and quantify the technical debt, so that it is more visible and not just a topic of side discussions that cause anguish and slows down quality software delivery.
What is required is the recognition and admittance that it will get more costly to take care of technical debt as time goes by. The ScrumMaster/Product Owner recognize this as a need and garner support by management to allow the team to be empowered to work on the technical debt.
Here comes the need for balance where along with empowerement comes the responsibility on the team to strike a balance between business value delivery and reducing debt.
The initial impact of focusing on technical debt might slow down in the feature delivery, but the expectation is that it will pick up once technical debt is paid off.
Remedy: Create technical Debt backlog and address it short Sprints.
Goal: Identify the 'need' vs. 'want' and plan to address that.
Creating a backlog was also resonated by Johanna Rothman, who was a speaker at the AgilePalooza in Boston last week.
1. Create stories around the major areas identified.
2. Let the team meet and brainstorm on ideas to fix the issues, come up with a game plan. Make this as tasks under stories, just like you would break down user stories.
3. At this stage treat technical debt backlog as product backlog and prioritize from the perspective of what is most urgent. Another way to prioritize is to ask some questions for e.g. 'What should be do first to achieve continuous integration, because that is killing the software delivery'
4. Apply the same principles of story points, estimation and plan on who works on what.
5. Create a 1 week or a 2 week iteration to focus and burn off technical debt
6. Measure burndown rate of the team against the technical debt backlog to help in future planning.
Finally, the scrum teams employ good software practices to ensure that technical debt does not become a systemic issue.
Thursday, November 5, 2009
Friday, October 9, 2009
Agile: Effective and shorter planning meetings
In all my years of being a scrum master/project manager for various sized teams, I have realized that the one of biggest resistance teams in adopting agile is the thought that they are time boxed in a room doing planning for two days !
Well, as a SM coaching teams to help in better planning, here are some tips on having shorter and effective planning meetings: essence 'Team work'.
1. Activity: In preparation for the Iteration Planning Meeting: the PO/SM/dev leads constantly groom the backlog. 2 weeks prior to the end of the current iteration, they have a pre-planning meeting and prepare a prioritized list of requirements. The backlog is available for the team in the tool of choice or relayed over email.
2. Tip: The stories need Acceptance tests defined, these are the criteria from User acceptance standpoint or view them as lite weight functional specs.
3. Activity: Ideally the team members volunteer for work rather being assigned work. The team divides into sub groups taking one story as discussion point and brainstorm to identify the work needed to be done in order to meet the acceptance test criteria, this does not have to be a full time occupation, this is done in the 3 hours of a day that we do not account for in Agile planning.
4. Activity: Demo and take back the learning's into the next iteration. Identify any technical debt/infrastructure/spike stories.
5. Tip: Ideally the above 3 activities are done before the 1st Iteration Planning Meeting (IPM), then in the planning meeting cover the breadth of the stories and high level task estimation rather than cover just couple of stories and break down to the last detail. The result of this planning is a prioritized list of stories for current iteration.
6. Tip: Joint planning is important at many levels, so we cannot do away with story/tasks discussions during the planning meeting, this allows to share ideas and brainstorm. This is the essence and spirit of scrum, but be mindful of the time that is spent on the discussions. The SM or the meeting coordinator needs to keep a check on this.
7. Tip: Team needs to be more comfortable on using the tool or get notepad in the planning meetings to jot down their stories/tasks, which they can take back, discuss with others where needed and do estimation. Do not expect the meeting coordinator to do all the typing, this saves time.
8. Activity: Everyone enters detail tasks with the time estimates as much as possible into the tool of choice come prepared for the 2nd planning meeting. This also is the basis for self driven team that feels empowered and committed to the work planned.
9. Activity: 2nd planning meeting focus is to take care of any unaccounted work, help a team member with estimation where identified, review the stories in accordance with the priorities expected from the team. The other focus is to do capacity planning and see what fits into and iteration and what does not. This typically should not last more than an hour if the team (including PO, SM, QE, Dev, doc) did their due diligence and have the iteration populated. At the end of this session the iteration is locked down and work begins.
Well, as a SM coaching teams to help in better planning, here are some tips on having shorter and effective planning meetings: essence 'Team work'.
1. Activity: In preparation for the Iteration Planning Meeting: the PO/SM/dev leads constantly groom the backlog. 2 weeks prior to the end of the current iteration, they have a pre-planning meeting and prepare a prioritized list of requirements. The backlog is available for the team in the tool of choice or relayed over email.
2. Tip: The stories need Acceptance tests defined, these are the criteria from User acceptance standpoint or view them as lite weight functional specs.
3. Activity: Ideally the team members volunteer for work rather being assigned work. The team divides into sub groups taking one story as discussion point and brainstorm to identify the work needed to be done in order to meet the acceptance test criteria, this does not have to be a full time occupation, this is done in the 3 hours of a day that we do not account for in Agile planning.
4. Activity: Demo and take back the learning's into the next iteration. Identify any technical debt/infrastructure/spike stories.
5. Tip: Ideally the above 3 activities are done before the 1st Iteration Planning Meeting (IPM), then in the planning meeting cover the breadth of the stories and high level task estimation rather than cover just couple of stories and break down to the last detail. The result of this planning is a prioritized list of stories for current iteration.
6. Tip: Joint planning is important at many levels, so we cannot do away with story/tasks discussions during the planning meeting, this allows to share ideas and brainstorm. This is the essence and spirit of scrum, but be mindful of the time that is spent on the discussions. The SM or the meeting coordinator needs to keep a check on this.
7. Tip: Team needs to be more comfortable on using the tool or get notepad in the planning meetings to jot down their stories/tasks, which they can take back, discuss with others where needed and do estimation. Do not expect the meeting coordinator to do all the typing, this saves time.
8. Activity: Everyone enters detail tasks with the time estimates as much as possible into the tool of choice come prepared for the 2nd planning meeting. This also is the basis for self driven team that feels empowered and committed to the work planned.
9. Activity: 2nd planning meeting focus is to take care of any unaccounted work, help a team member with estimation where identified, review the stories in accordance with the priorities expected from the team. The other focus is to do capacity planning and see what fits into and iteration and what does not. This typically should not last more than an hour if the team (including PO, SM, QE, Dev, doc) did their due diligence and have the iteration populated. At the end of this session the iteration is locked down and work begins.
Subscribe to:
Posts (Atom)