The Silent Killer in Your Agile Implementation
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.