The Four Pillars of Agile Adoption

commitment that cannot be fulfilled is of no help to the organization but can become a magnet for blame. Managers must understand that they have a responsibility to regulate the flow of work to agile teams. It is a simple, effective way to help teams keep their credibility.

The worst thing an agile team can do is erode trust with their customers. Each iteration should build up that trust.

Agile teams that form spontaneously "under the radar" are very often undermined because management has not acknowledged any obligation to regulate their workload. They are flooded with too much to do, no time for learning new tools or for maintaining a unit test infrastructure, and they can only hold the line so long.

Takeaway Lesson
If teams have mastered bug-resistant code and are empowered, they can still be destroyed by the failure of management to regulate the flow of work to them, i.e. allow them to pull the work in at their sustainable pace. Managers at every level have got to buy into the idea that they must never jam more work into a pipeline than its proven capacity. The good news is there are legitimate ways managers can increase that capacity.

Problems With Pillar #4: organization's Work Stream
One of the worst things that can happen to a good Agile team is to be assigned to a weakly supported project. That will mean blockages don't get removed. People and other resources get taken away when needed by other projects. The team repeatedly fail to deliver on their commitments and they lose the trust of their product owner.

Need Lean Project Portfolio Management
The previous three pillars of agile adoption are covered by the popular agile methodologies, but this issue of governing the work stream at the organizational level takes us over to Lean territory. Unless a lean discipline is used to decide what work an organization undertakes, it runs the risk of spreading its energy too thinly. Weakly supported projects will thrash and waste resources. A company that regularly completes 40 to 50 projects a year should not have 500 active projects in their portfolio!

Projects that have a direct business need are easiest to do as agile because there is a strong pull by a customer. Necessary infrastructure projects are harder to gain sponsorship for. There is less will to allocate a dedicated team, and pay for the tools they'll need. There is no easy answer here, but if the project is truly needed then it is the responsibility of the business to understand what it will accomplish and be a sponsor for it.

In the example of the Comet team, they were one of several agile teams. There isn't enough context to tell for sure whether theirs was a weakly supported project. Probably not, as their software was for use by the insurance underwriters to determine risks. This illustrates that it's not enough to just look at individual agile teams–you need to understand how groups of agile teams function within an organization.

Agile Habitat
One agile pilot project can be sustained by almost any company. It will place more or less demands on various other departments and infrastructure, but can be coped with. As the number of agile teams increases, pressure on certain resources (testing environments, product owner attention, team rooms, etc.) reaches a point where something has to give. Either the agile teams will be reined in and forced to make more and more compromises in their roles and practices, or else managers will recognize that they have to make the organization into a better habitat for