What’s it all about?
Software Development. It’s all about software development.
Let me begin by calling our attention to the Agile Manifesto. At the top of the page, it says: “Manifesto for Agile Software Development”. Software Development. Make a note of that.
Looking at the Manifesto’s values and principles, we’ll see the word “software” no fewer than seven times. We’ll also find reference to technical excellence, good designs, architecture, development, and delivery.
Looking at Scrum, the most popular Agile framework, we see that to be doing Scrum, we need to be shipping working software every Sprint. Jeff Sutherland, Scrum’s co-creator, said just this month:
“Any Scrum without working product at the end of a sprint is a failed Scrum.”
What does it take?
It takes many skills. Paramount among them: Software Development.
Doing good work, in an Agile fashion or otherwise, requires blending together many skills. We need teamwork, the ability to communicate well, skill in retrospectives. We need to be able to identify what’s valuable and what’s not. We need to focus our work on business needs. We need to limit work in progress.
Yes, we need all those things. And if it’s software we’re building, we need to know how to build software.
To be fit for purpose, the software we build has to be robust enough to support the business need. It needs to be sufficiently free of defects to be usable and desirable. It needs to be well structured enough to allow us to sustain its development as long as required.
Robust, reliable, well designed. These are not things that we just automatically get by having a Product Owner and a ScrumMaster. Much less are these things we get by having really good Portfolio Vision and an Agile Release Train.
Down there at the bottom of our Agile Software Development, whether we’re doing it with a team or two, or with a large “Scaled Agile” process, there are teams of developers building software.
What if we can’t?
If we can’t build software well, all our “Agile” is for nothing. Nothing.
If we can build the software well, we have a shot at success with it. If we do not build it well, all our teamwork, communication, retrospectives, business focus and WIP limitation are for nothing.
Our teams don’t just need to be placed into a Scrum pot, or a bigger blacker SAFe pot, and boiled up. They need to know how to develop software in a fashion that permits them to deliver working software every couple of weeks. They were not born knowing that. They will not learn that just because we put them under pressure or give them a really great Product Owner, ScrumMaster, or Team Room.
They need to know the basics, and they need to apply the basics.
Your teams need to know how to do Agile Software Development. See that you take care of that.