5 Minute DevOps: Agile Rehab
I’ve been a developer for a while. I’ve delivered using every industry fad that management has bought into. In 2003, the organization I worked for wanted to bring some discipline to our ad hoc processes so they sent senior developers and team managers to PMI training to become certified project managers. We implemented a disciplined SDLC with process gates, learned to calculate the critical path on a Gantt chart, and spent a lot of time pretending that product development was deterministic over large timescales and feature sets. This failed, just as it almost always does.
Later, new management wanted to adopt agile development practices to improve things. Everyone went to the two-day Agile training, tried to translate these new terms to SDLC processes, and learned to create two-week project plans. Water-scrum-fall. This was more effective for finding out when we were trending late but didn’t really improve delivery. We still delivered changes every quarter, it’s just that all of the terms changed and we were “Agile”. In fact, we had Agile Maturity Scores™ to show exactly how agile we were.
Eventually, we had a real, objective goal. We needed to deliver at least bi-weekly instead of quarterly. We needed to solve all of the technical and process problems required for continuous delivery (CD). Our original goal was bi-weekly, but we decided that daily or more was a better goal. There were many good reasons for this, but the most important was that when there is an impacting incident with a direct downtime cost of thousands of dollars a minute and an indirect cost of far more than that, we need to have the ability and confidence to fix things quickly without making things worse. CD enables this if teams practice delivering very frequently. As we dug into CD, we quickly discovered we knew all the Agile terms and ceremonies, but we had no idea how to be agile. We had to fix that to deliver daily. If you are struggling with “Agile”, I hope our learnings help.
Use the Right Definition for “Agile”
There are two common definitions for “agile”:
ag-ile (adjective): Able to change directions quickly and easily. Nimble.
This “agile” is an outcome of having the ability to adjust priorities and improve outcomes based on the feedback from the end-user.
Ag-ile (proper noun): A product marketed by Agile Industrial Complex certified consultants to pay for their boats.
This “Agile” is focused on selling cookie-cutter solutions and “Agile Transformation”.
The difference between the noun and the adjective is that the adjective is focused on delivery and feedback. The noun is focused on standardized processes, typically by claiming we all need to do Scrum and get better Agile Maturity™ Scores. Nouns and cookie-cutter solutions are easier to sell and implement than results.
I’ve had so many conversations where someone says, “but the Scrum Guide says…” I had one person tell me that using a “definition of ready” before beginning work wasn’t valid because it wasn’t in the Scrum Guide. OK. So? DoR is a good thing. The Scrum Guide also says both that it’s incomplete and that if you aren’t doing everything in it then you aren’t doing Scrum. Our goal isn’t Scrum and the Scrum Guide isn’t the law of agile software development. It’s the opinion of one group of people and..
Stop Using Maturity Models
Maturity models are bunk. They are a list of things someone else developed for their context. Yes, many of these have good ideas in them. Harvest the good ideas. However, no customer cares about our “maturity score” and we aren’t ever “mature”. Instead, we measure indicators for the continuous delivery of value to the end-user.
Have an Agile Mindset
What is the real problem we are trying to solve? Development is complex. It is not merely an assembly line process where we know the end state before we begin. We are doing product development. Every release is a prototype that we hope meets the needs. The reality of software development is that one or more of the following is true:
- The requirements are wrong
- We’ve misunderstood the requirements
- The need will change before we deliver
We are always talking about the “agile mindset”, but what is that really?
“We are probably wrong. We need to optimize our processes for being minimally wrong so we can quickly adjust to become less wrong.”
What we are doing is establishing a pattern of delivery that mitigates this reality. Real agility is using the scientific method to verify or falsify our value hypothesis. We need to deliver very small batches of work very frequently to get rapid feedback from users so we can adjust. We need to reduce the cost of change and improve our quality processes to support our ability to do that.
For Agility, Think Smaller
Start with a simple question, “why can’t we deliver working changes today?” Continuous delivery is the tool for uncovering and fixing the impediments to agility. There will be technical and process challenges to solve. How do we automate CI and delivery while remaining secure, compliant, stable, available, and delivering useful features? How do we make code changes that are evolutionary so we do not need to branch and wait for features to be complete before delivering? How do we break down work so we can deliver working features in less than 2 days? How do we get better information? How do we work as a team better?
As the problems are tackled, we’ll find that many of the things taught in Agile training are useful. Others don’t add value to us. We want the minimum viable process to enable the continuous delivery of value and we want to engineer solutions to keep the process overhead low.
Don’t Keep Starting Over with the Manifesto
The Manifesto for Agile Software Development begins with “We are uncovering better ways of developing software by doing it and helping others do it.” That was written over two decades ago. There is much good there, but many things have been proven since then and do not need to be uncovered. CD is one of those things. If you are trying to become agile, don’t start with the Manifesto. Don’t start with Scrum. Don’t try to follow the rules, because there are none. Focus on the continuous delivery of value to the end-user and ask “why can’t we deliver today?” Use the principles and practices of continuous delivery to uncover waste and pain. Relentlessly improve to remove them. Your customers will be happier. So will the teams.
