The Agility Series — 1 — Agile: Adjective Not Noun.
Team: “We are so Agile!”
Business: “How Agile are you?”
Team: “We do 30 points a sprint!”
Business: “What does that mean for the customer?”
Team: “Umm……….”
It might just be in the subconscious. But it is there. Another potentially silent but disturbing question: “Why did our Agile project turn into a Big Ball of Mud after a couple years?”
It is a mental dialog I encounter when I read about Agile as a methodology and when thinking about the typical IT Department struggling to find a way to make the business happy — frequently. Eventually they cannot respond as fast and would like the issues to just disappear. They just want peaceful success and Agile was a promise that could make development of software great again.
There are people who love Agile and there are people who hate it and there are many who are indifferent. Those who buy into it tend to see agility as a great way to get new stuff estimated, developed and deployed in a predictable cycle. It is all mechanical to them. DevOps gives them hope for that reason. Those who hate it tend to see it fail the business at a deeper level more than a few times a year in such a way that it is now no longer a valued concept.
Agile proponents are typically focused on team structure, process and throughput.
Agile opponents are typically concerned with team morale, business value, and depth of quality.
The best things in life have tension. The healthy management of the Speed — Quality tension is one of those that make-or-break companies.
To address this, teams turn to the tension between output (speed) and outcome (quality). The buzz phrase of “Outcomes rather than output” is more common now. I sense that some are just labeling their output as outcomes though. Let’s avoid that and work to systematically create agility in our software development ecosystems with balance in this tension. This series will dive into this.
Before we look at software, let’s aim our sights at the domain itself, the need for agility specifically.
Step One: Define Real Domain Agility
If you want true agility, then define it. If you could have ultimate agility where you need it most, what does that mean to your Domain? What does success in this look like? Is it that Business Intelligence is synthesized, analyzed and incorporated into new features in less than a year? A month? A week? How Agile do you need to be in your market to start to beat the competition, or even remain in front? Maybe you have other flexibilities in mind. Whatever you choose to do with Agile, define what success in agility means first. Pay attention to this often, because as you will see, what you needed to be agile on today, might be replaced by something else at some point in the future.
Step Two: Keep Politics Out
Don’t accept false positives as successful attainment of agility. This is a hard one. Many proponents in your organization will tout success to boost morale internally and to drive respect externally for the efforts. But at the end of the day, if we are not meeting the agility needs of the Domain, we are failing. Set the bar to the level it needs to be and don’t let anyone tell you it is working when the bar is not met.
The best way to do this is by metrics. Many sources of literature will teach you how to go faster, but not many will teach you how to achieve your goal. These are two different things. Goals are harder to achieve. Speed only works for the short term until the systems cannot handle the speed of change. It is a blessing when both happen at the same time. Balance of tension.
Step Three: Strategic Upgrades
There are few things that prevent businesses from meeting their needs more than a nice big ball of muddy software. Whatever is blocking your ability to pivot, fix it. If people, move them. If software, improve the strategy. If vision, update it. Whatever it is that is out of alignment, you will do yourself a huge favor if you stop and question those tough spots. Ask “why” many times, and then make the repairs you need to get the responsiveness from the organization you need. My father often told me, the sooner you face the music, the better it will sound, sooner.
Software Upgrade Needed?
There are many symptoms of a failing software project. Not just the simple and easy to detect symptoms of arbitrary missed deadlines and overspending. There are other headaches like the inability to reasonably respond to a market shift or ability to comply with a change in the laws of the land. Software is no longer just something we build in our basements, and everyone stands in awe at the neatness of the thing. It is now just a foregone conclusion that there are smart developers in the world. That raises expectations that systems should be friendly to change — True Agile.
Looking Forward
Every team or company is different, but there are some common principles that we can review to make it to that agile destination. This has not much to do with estimating a user story, grooming a backlog, managing a ticketing system or the administration of a large agile process framework.
I look forward to working on these thoughts with you in this new Agile Series…
… until next time.
