when relevant content is
added and updated.
After the new year I wrote this article, then asked for a few rounds of peer review. My reviewers, including Lisa, pointed out that I was wrong. Or, perhaps more politely, they pointed out I could benefit from a different perspective. I decided that I was wrong. Instead of changing things, I decided to present the original post, as-was, and ask for your feedback, before presenting some corrections. Assuming forewarned is forearmed, there you go. Tell me how I am wrong.
Because I am.
I was talking to Lisa Crispin earlier today about the state of devops survey. That survey identifies four levels of “performers.” For performance measures it looks at how long it takes a change to get to production after commit, how frequently new code goes to production, or the percentage at which a change “fails”, creating new problems. These measures are more concrete and “hard.” They are easier to measure, but don’t include all the concepts in Agile software. Collaboration, for example, is remarkably hard to measure. Still, we’d tend to call the companies that are high achievers on the DevOps survey “Agile.”
For some reason, it is next to impossible for established organizations to get there.
Agile transformation is a giant industry. As of today there are 270 current certified Scrum Trainers, and around seven hundred thousand certified Scrum Masters. That is just the most popular program, it does not count Scrum.org or the Scaled Agile Framework.
Yet on legacy systems, performance continues to be poor.
Don’t get me wrong. The teams have Sprints, Stories, and Standups. The teams have a product owner and a Scrum master. There may be agile coaches and tribes and communities of practice. Yet at the end of the two weeks, when you look at what the team got done, the answer seems to be “not much.” No one can quite explain why, though they are happy to explain why they can’t pair program, why they cannot add unit tests, why the code takes two days to deploy so it has to be deployed quarterly. They might even be able to explain why regression testing takes so long.
And those are just the hard technical practices. Self-directed, self-organized work teams do not emerge. It doesn’t happen. We see the ceremonies, but they do not add value. The team members end up saying “Agile is too heavy” or “We tried Agile and it didn’t work.”
This problem is more complex than it first appears.
For years, we’ve pushed back on that. Transform your way of working, we said. Be more like these Silicon Valley darlings that can do all the things easily. Bring in a vendor. If we just put the software in the cloud and add CI/CD and feature flags and move to Microservices and … then you could just be agile.
I’m starting to wonder if we should say “legacy systems should be managed differently than greenfield development. Count the cost. You may come to different conclusions.”
Let’s talk about why.
A few years ago I was invited to a debate with Bob Reselman on Code Coverage measures for legacy apps. Bob confused me; it seemed to me as if Bob was actively arguing against adding unit tests and measuring them on legacy systems.
That really confused me. After all, aren’t unit tests and measuring coverage a Real Good Thing (™), and the lack of them a Real Bad Thing (™)? Bob’s advice seemed to be to basically give up on systems that were not designed with an agile way of work in mind. Keep the lights on, and do maintenance work on them, don’t expect them to change all that much. Another term for that in Maintenance, Ongoing Operations, and Support Engineering (MOOSE). Ken Schwaber, the creator of Scrum, called this the “core system” in his talk “A Canary in a Coal Mine.” According to Schwaber, the core system is boring, low-status work. The new hot engineers simply do not want to learn it.
So now we have a new problem.
We need the old system. It is hard to impossible to work on it an agile way. Transforming the old legacy work system to “make it agile” will slow us down even more for a little bit. The big rewrite is a classic pattern for failure, while the strangler pattern, or incremental replacement, is tricky to pull off.
One of my interests right now is these “core systems”, how they come to be, what to do about them when they are here, and maybe, hopefully, how to stop creating them.
In the meantime, there is a good reason why Johnny can’t agile. Until we can crack this nut, expect companies to spend millions of dollars on coaching, “transformation”, training, and tools, adding stories, sprints and standups. Yet the best outcome they will have, on some teams, is bringing the ship speed into 2008, a 30% or so increase in performance, and the statement “At least my job doesn’t suck as much as it used to.” That 30% number isn’t my invention. It is what Jeff Sutherland claims is possible when organizations adopt iterative development without self-organizing teams.
I am looking for better answers.
For today, I’d love to hear your experiences – to see if I can describe this problem more accurately.
Tomorrow, let’s start talking about techniques to resolve it.