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? It takes longer to do anything, the variance of task duration increases, 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, demos, and 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.
Here is 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 developer write code for the story (dredging its details from memory because the ticket is thin on detail). The PO is busy, so they choose to ask her their two most critical questions, and they do so over Slack. The PO, sitting in some boring meeting, types back brief answers that the developers interpret differently than she intended.
Two days later, the team’s tester checks the deliverable, but is not sure what the anticipated results are. He’s nervous about asking the developers or the PO, fearing he’d look incompetent. He does automate UI-based tests for a couple of basic scenarios.
During the demo, the three of them are silent because they don’t want to expose their doubts. Fortunately, the PO doesn’t challenge them; she only asks for a few changes.
Three weeks later a bug is found in the code. One of the original developers, after two hours of hunting for the problem, makes a one-line change. He decides not to show the tester because it’s such a small fix and the tester would want to retest the whole story. The fix breaks something else which isn’t discovered for another month.
9 out of 10 Agile teams experience scenarios like this all the time, and don’t know how to address them.
Technical Agility, which is critical for Business Agility, means doing the work in a way that minimizes the variability associated with changes to the work product. In fewer words, the idea is to keep the cost of change low. That’s the cost of changes made while working on the product as well as after it’s “done”:
- Taking it in a different direction due to a change of mind or circumstance
- Modifying its implementation due to a change of understanding
- Adding or changing features and behaviours
- Fixing mistakes or previous bad decisions
The usual treatment of such changes — writing them as user stories, estimating them, dealing with them a few at a time, etc. — is not the issue. What matters is that these changes are going to cost you. They can kill your agility. How are you working, from day one, to ensure that you can afford them? Are you acting with Technical Agility?
Technical Agility is a relatively new concept. For many years, Agilists limited their concerns to software development and in that field, the common term was “Agile technical practices.” This term referred to specific practices such as automated testing, refactoring, and continuous integration. But without principled behaviour, these practices are not enough. And if the team’s work isn’t software development, they need their own form of Technical Agility!
No matter what Technical Agility looks like (depending on the work and the environment), it follows these seven principles:
- Evolutionary design: Produce the deliverable iteratively and incrementally
- Rapid feedback: Check your work quickly and frequently
- Small, safe steps: Proceed in tiny steps that are easy to test and undo
- Simplicity: Achieve the outcome in the simplest way that will do and that you’re not likely to regret quickly
- Clean work: Ensure the deliverable has internal integrity that makes it easy for others (and you) to keep working with it
- Reliability: Finish what you start, and don’t start what you can’t or probably won’t finish
- Shared responsibility: Be jointly responsible (with the entire team) for everything about the work, treating it as if you own it
For greater Technical Agility in the example scenario above, the team should of course write unit tests, refactor their code, and continuously integrate it. But that addresses only two of the principles, and likely not enough. Early on, they should split the story into small pieces. They should capture discussions and decisions about each piece, and make sure everyone understands them. When communicating (verbally or over Slack) they should verbalize their thought process and double-check their understanding. The developers and the tester should collaboratively produce several kinds of valuable automated tests. They should check their work with each other on several occasions before the demo, look relentlessly for simplifications, and tie loose ends.
If you’re using an Agile approach, Technical Agility is not optional. Agile means you explicitly anticipate change, and intend to respond to it gracefully, economically, and sustainably. You will not be able to do any of that without Technical Agility. Evidence of this is everywhere, in products that workers struggle to maintain and improve, ever-longer delivery cycles, compromised customer experience, and major rewrites.
Technical Agility matters to everyone doing the work, and creates a state of mutual expectations. In order to have long-term development reliability, product owners and managers should expect their delivery teams to have high Technical Agility, and the teams should expect their product owners and managers to make room for it. It’s a cost of doing business.
In my experience, most Agile teams fail on this front for the same reasons. Product owners always want more new features done; the need to show “velocity” emphasizes short-term outputs over long-term outcomes; and delivery teams don’t make an effective case for Technical Agility. Throw in the short tenure most people have in their roles these days, and one’s low Technical Agility today becomes somebody else’s problem tomorrow.
You’ve made the choice to use Scrum, Kanban, or some other Agile framework. Ideally you’re also approaching its elements with a true Agile mind-set. This is not enough, although in the short term, it will seem to be enough. Your choices, while actually doing the work, matter. Be Agile there as well.
Copyright © 2018, 3P Vantage, Inc. All rights reserved.