The Silent Killer in Your Agile Implementation

Gil Broza specializes in increasing organizational agility and team performance with minimal risk and thrashing. Dozens of companies seeking transformations, makeovers or improvements have relied on his pragmatic, modern and respectful support for customizing agile in their contexts. His book "The Agile Mind-Set" helps practitioners go beyond process and adopt a true agile approach to work. His book "The Human Side of Agile" is a practical book on leading agile teams to greatness. These days, several of the world's largest organizations are having him train hundreds of their managers in technology and business (up to VP level) on practical agile leadership. Get Gil's popular 20-session mini-program "Something Happened on the Way to Agile" free at OnTheWayToAgile.com.

  Agile   Estimating   Testing/Test Management  

Suppose you have agile teams and things look good. Folks work on important initiatives, do high-value work, get feedback regularly and deliver finished products/services to their intended consumers frequently.

Question: How long before things start to break down?

Wait…what? Isn’t this the picture of agile nirvana? Why should anything break down?

Yet the answer for many such teams is “one to two years.” And those breakdowns? The longer it takes to do anything, the longer the variance of task duration. When that happens, motivation and engagement decrease, and collaboration becomes harder to maintain. These effects build on each other in a vicious cycle.

The above happens despite short sprints, limiting WIP, controlling the size of work items, visualizing the work, doing demos and having team consensus—the bread and butter of popular agile methods. These methods describe how teams move work along, but they are silent on technical agility: how those teams execute the work in a way that supports business agility.

A common scenario of low technical agility
The product owner drafts a story. Two weeks later in iteration planning, the delivery team looks at it, thinks it's clear enough, asks a couple of questions, estimates it and commits to it.

During the iteration, a back-end developer and a front-end …

Please log in or sign up below to read the rest of the article.