Below is a post that I have mulled over for a while. I'm not satisfied with it but I would love some feedback.
I'd like to address two areas that are often considered taboo in the Agile field; Accountability and commitment. Just like the pig in the "Chicken and Pig Make Breakfast" story, agile teams make commitments. Teams commit to stories and they commit to estimates. As an agile project progresses through the 5 Levels of Planning it also moves through progressively higher levels of accountability; Nice Idea, Best Effort and Commitment.
Making Commitments
The Accountability Model above is meant to illustrate how each level of planning helps the team zero in on an actual commitment. Since agile teams accept that requirements will change, the most detailed design estimates are held off until just before implementation. So, project stakeholders can expect The Release Plan to be more accurate than The Road Map and the Iteration Plan to be more accurate than the Release Plan.
With higher levels of accuracy come higher levels of accountability while lower levels of accuracy call for lower levels of accountability. Let's take a look at the levels of accountability:
Accountability is a hard subject to address in this field. A person can "be" accountable, "be held" accountable or account for someone else. In general, developers are accountable to the user, the team and themselves. Holding a team accountable for the completion of a project is usually a huge morale killer and often does more harm than good. Holding someone (coach, scrummaster, etc) accountable on behalf of the team will most likely fail as well.
So who is accountable? How is accountability expressed on an agile project? On agile projects, developers hold themselves accountable. They hold themselves accountable to the team, the users, their pair partner, themselves, etc. For Agile teams to be successful a culture of accountability must be nurtured but not forced.
Nurturing Accountability
Nurturing a culture of accountability is easier said than done, but it can be done. The usual tools of evaluations, reviews and threats have no place on a self organizing team. You can apply incentives, a sense of accomplishment, team ownership and a little peer pressure.
A good incentive suggested by Scrum is a burn down chart. On some teams the build server plays music or turns a light green when a build passes all tests. Involving the "Whole Team" in the planning and design is a surefire way of building team ownership. This leads to buy-in and allows developers feel a real sense of accomplishment. Also, large information radiators are a good way to keep the team focus.
Final Thoughts
So, what I'm suggesting is that teams should want to commit to an estimate. Teams who have "bought-in" to a project are more likely to hold themselves accountable. Kent's discussion about accountability was my original inspiration for this.
I'd like to address two areas that are often considered taboo in the Agile field; Accountability and commitment. Just like the pig in the "Chicken and Pig Make Breakfast" story, agile teams make commitments. Teams commit to stories and they commit to estimates. As an agile project progresses through the 5 Levels of Planning it also moves through progressively higher levels of accountability; Nice Idea, Best Effort and Commitment.
Making Commitments
The Accountability Model above is meant to illustrate how each level of planning helps the team zero in on an actual commitment. Since agile teams accept that requirements will change, the most detailed design estimates are held off until just before implementation. So, project stakeholders can expect The Release Plan to be more accurate than The Road Map and the Iteration Plan to be more accurate than the Release Plan.
With higher levels of accuracy come higher levels of accountability while lower levels of accuracy call for lower levels of accountability. Let's take a look at the levels of accountability:
- Nice Idea
The Vision and the Project Road Map serve as guidelines for prioritizing during the more detailed planning that takes place closer to the Iteration. As new requirements and unforeseen changes expose themselves The Vision and The Road Map WILL change. Management should shy away from holding anyone accountable for changes that occur in the Nice Idea level. Rather, they should embrace the change as nessecary or find ways to mitigate the change. - Best Effort
The Release Plan is a best effort estimate based on yesterday's weather. Iterations are timeboxed and most teams track velocity. This allows a project manager to produce an iteration schedule. The Release Plan, while more accurate than the Road Map, is less accurate at the front-end than at the back-end. For this reason, managers should consider using a confidence range chart or some other measurement of accuracy. Tracking a project's rate of change can also help mitigate risk. Managers should encourage change in the early iterations of a release but changes should stay within the scope of the current vision and roadmap. If you see either the vision or the roadmap changing you should consider wrapping up the release and starting a new release plan. - Commitment
Iterations are short and easily estimated. Teams with a well established velocity and a long history with the current project will be able to make the most reliable estimates. These teams should be able to fully commit to an Iteration of work.
Accountability is a hard subject to address in this field. A person can "be" accountable, "be held" accountable or account for someone else. In general, developers are accountable to the user, the team and themselves. Holding a team accountable for the completion of a project is usually a huge morale killer and often does more harm than good. Holding someone (coach, scrummaster, etc) accountable on behalf of the team will most likely fail as well.
So who is accountable? How is accountability expressed on an agile project? On agile projects, developers hold themselves accountable. They hold themselves accountable to the team, the users, their pair partner, themselves, etc. For Agile teams to be successful a culture of accountability must be nurtured but not forced.
Nurturing Accountability
Nurturing a culture of accountability is easier said than done, but it can be done. The usual tools of evaluations, reviews and threats have no place on a self organizing team. You can apply incentives, a sense of accomplishment, team ownership and a little peer pressure.
A good incentive suggested by Scrum is a burn down chart. On some teams the build server plays music or turns a light green when a build passes all tests. Involving the "Whole Team" in the planning and design is a surefire way of building team ownership. This leads to buy-in and allows developers feel a real sense of accomplishment. Also, large information radiators are a good way to keep the team focus.
Final Thoughts
So, what I'm suggesting is that teams should want to commit to an estimate. Teams who have "bought-in" to a project are more likely to hold themselves accountable. Kent's discussion about accountability was my original inspiration for this.
2 comments:
Good post overall,
Including developers on estimates is definitely an excellent way to nurture accountability. I've used it on my projects, and combined with a public burndown chart, it's very effective .
I love the idea of the build box flashing green lights,and playing music whenever the build is successful . Talk about real time feedback! If you have any URLs that you could point me to such a setup that would be great.
In terms of the kinds of accountability,I'm going to throw something at you a little bit from left field .
One problem I see on many projects is that business users are accountable for business results specified in a business case. Examples include building a system to support the increasing sales, producing support turnaround time,lowering operational costs , etc.
These business objectives, measurable by business metrics, are then transformed into requirements. Sometimes these requirements are detailed, sometimes they're not as most agile process is prescribed.
The major issue here is that technical resources are now on the hook for requirements not business objectives.
If I were to change anything I would state that senior technical resources, such as application and enterprise architects need to actually be on the hook for business objectives just like business stakeholders are, that will empower technical resources to argue to value of a particular requirement or feature on an even footing with business resources.
Increasingly, technical resources have just as good of an insight or better concerning the ability of technology to support business objectives, they just do not have the proper rewards or incentives to challenge the business properly.
Jeff Anderson
http://agileconsulting.blogspot.com
The problem of mapping requirements to and from business objectives is a very real issue.
I see SOOOO many PMs and other business users that are very good at outlining specific business objects, thus making the "business case."
I'd like to see more time spent distilling the business objectives/goals into real User Stories. In doing so, User Stories could more easily be mapped back to a business objective.
Post a Comment