The Four Pillars of Agile Adoption

for them. Once the bugs had repercussions in the Legal department, the organization's blame reflexes kicked in. Too bad they didn't have the benefit of a good retrospective to identify these dynamics and find a constructive way to address them!

Failure to Sustain Agile Feedback Mechanisms
Another key leverage point that managers neglected is the extremely vital feedback loop between team and stakeholders. A strong product owner actively engaged with both the team and the stakeholders is necessary for agile teams. Like well-run retrospectives, this prevents a host of problems that are very difficult to address in firefighting mode. Once a team loses the trust of their stakeholders everything is an uphill battle. Although projects vary in their demands on product owners, it is always wise to invest in keeping that feedback loop healthy. Give them time to perform the role.

Comet team's product owner was feeling pressure to minimize the time devoted to his role. The executive sponsoring the agile adoption programme (the agile champion) should have been making sure that people in key roles were allowed the necessary time. A product owner's manager won't be willing to cooperate unless they have bought-in to their own role in the agile adoption programme. The programme must have sponsorship high enough to span business and technology departments.

A reminder from the agile champion would be all that's needed to keep the product owner properly engaged, if the right agile sponsorship groundwork had been laid.

Summary of Empowerment issues
In summary, Comet's management needed to do these things to prevent the problems stemming from insufficient empowerment:

• Recognise the importance of facilitation skills and grow those skills
• Act on issues arising from retrospectives that are outside team's control
• Support the project manager when he/she gets inappropriate pressure to direct the team
• Support the need of product owners for time to perform duties of their role

Takeaway Lesson
Without the right empowerment, the goal of sustainable bug-free code cannot even be achieved. A properly empowered agile team is the means to generating sustainable bug-free code.

Problems With Pillar #3: Team's Work Stream
An agile team ‘pulls' work from the product backlog into a time-boxed iteration. After a couple iterations they know how much they can do in a given period; they have established a velocity. A common problem for managers new to agile is that they want the team to do more than the amount their velocity indicates. So they pressure the team to give artificially low estimates, or to work long hours, and so on. [7]

Velocity as an emergent property
An essential idea of a pull system is it recognizes that the team cannot control everything that has a bearing on their velocity. The team is part of a bigger, interconnected system. That system can produce almost bug-free code at a certain rate, full stop. That's the velocity. It might be stated as so many story points per week. If faster output is needed then the interconnections between the agile core team and the rest of the system need to be understood and improved to generate a higher velocity.

Velocity is an emergent property of the system. It cannot be directly commanded. If you get fifty story points this week by working twelve-hour days, when the usual was forty points, you are not working sustainably. You're simply robbing future production to get a peak now. Perhaps a tool to do data profiling would result in higher velocity. Tools are an example of an interconnection between the core team and the organizational system. So is training. If the team is given training to help