Why agile transformations can fail to deliver the promised outcome
In the last year there was a huge amount of agile transformations, with only some delivering on the promised expectations. One reason why the expected value could not be realized is that the discipline with regards to software quality was not always given. Other reasons are missing team empowerment, missing organizational alignment, no direct interaction of teams with customers and other organizational reasons, but that is something for another blog.
The agile manifesto simply states:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
So technical practices are not directly mentioned in agile manifest. But the founders of the agile manifest stress the importance of internal software quality and technical practices, which help to achieve that - like TDD, Refactoring, Clean Code and Pair Programming.
Martin Fowler writes in Flaccid Scrum:
What’s happened is that they haven’t paid enough attention to the internal quality of their software. If you make that mistake you’ll soon find your productivity dragged down because it’s much harder to add new features than you’d like. You’ve taken on a crippling Technical Debt and your scrum has gone weak at the knees. (And if you’ve been in a real scrum, you’ll know that’s a Bad Thing.)
Robert C. Martin mentions in his talk on The Land that Scrum Forgot.
You need something that keeps you clean, ‘cause you need something that keeps the code from rotting. How many developers do we have in the room? How many of you have been significantly slowed down by bad code… generated by a Scrum team going too fast? When you go fast and you are focusing on getting stories done, and stories done, and stories done, and stories done… the code can rot just as fast as you are moving. And so what happens after a year is that the rate begins to slow. Not because you’re working less hard – you’re putting in a hell of a lot of effort – it’s just that you can’t force the code to accept the next new feature.
Ward Cunningham on how technical debt can destroy agility: "Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation."
Also the other founding members of the agile manifest (Kent Beck, Alistair Cockburn, Andrew Hunt, Ken Schwaber ...) stress the importance of internal quality for staying agile.
Theoretically, it is possible to adopt agile team without writing unit tests, doing refactoring and writing maintainable code. In practice though, it is hardly possible for a team to react to changing requirements and maintain working software in an agile environment without those technical practices. Without these technical practices Scrum can act as a hamster wheel making things much worse and less agile. So, if you want to become and stay agile, you need to have a strong focus on the external and internal software quality. More on different practices, tools, organizational and cultural aspects in the coming newsletters.
Why: More on my motivation to start the newsletter can be found in Collaboration on Improving: Why I'm starting the Engineering Ecosystem.
About me: I am Klaus Haeuptle an engineer and architect at SAP, the author of the books Clean ABAP and Clean SAPUI5, a coach for agile software engineering and a community servant leader for a large SAP internal grass roots community on improving tools, technologies, practices and culture, with more than 3000 participants from all locations and departments. Views are my own - the content published on this channel reflect my opinion and engineering principles.
Subscription: If you want to get updates, you can subscribe to the free newsletter:
Mark as not spam: : When you subscribe to the newsletter please do not forget to check your spam / junk folder. Make sure to "mark as not spam" in your email client and move it to your Inbox. Add the publication's Substack email address to your contact list. All posts will be sent from this address: ecosystem4engineering@substack.com.
✉️ Subscribe to the newsletter — if you aren’t already.
❤️ Share it — The engineering ecosystem newsletter lives thanks to word of mouth. Share the article with someone to whom it might be useful! By forwarding the email or sharing it on social media.