When did it happen?
When did agile stop being about software development?
That may seem a little dramatic, but if you look at the signatories of the agile manifesto at last half of them were, and in some cases still are, practicing software developers (aka coders). People such as Martin Fowler, Kent Beck, Bob Martin and the Pragmatic Programmers (Dave Thomas and Andy Hunt) have become synonymous with really good software development practices, techniques and patterns that have helped to educate several generations of software developers since that meeting in February 2001 at Snowbird, Utah.
Indeed, the full name of the manifesto is the Manifesto for Agile Software Development and it talks about “uncovering better ways of developing software by doing it” and delivering “working software” so the actual software is pretty front-and-centre in the manifesto. Probably the most high-profile poster child for agile software development around the time of the manifesto was eXtreme Programming (XP) which has a whole bunch of software development practices at the heart of it.
However, in the past 20-ish years, it seems that agile has come to be more associated with the process (Scrum, Kanban, story points, retrospectives, backlog management, Lean Startup, etc.), the people (servant leadership, team dynamics, ethics, psychological safety, etc.) and the enterprise (SAFe, LESS, governance, etc.) than it has with the practices that should underpin the creation of the “working software” we’re supposed to be delivering. Indeed, one of the other signatories to the manifesto, Ron Jeffries, described XP as “The Scrum That Actually Works”.
The discussion of development practices seems to have moved into the Software Craft and devops spaces leaving what look like two separate communities. There are conferences on agile and conferences on software practices and not a huge overlap between the two. To borrow from Monty Python’s Life of Brian, one crowd followed the shoe and the other followed the gourd.
Now don’t get the wrong idea. To mangle the agile manifesto itself, it’s not that we value the “things on the left” more than the “things on the right”. To deliver working software in a way that doesn’t burn people out and cause an enormous amount of emotional and psychological damage, we need to be really good at the people and process elements of it as well.
However, if we lose the practices we risk not actually delivering the promised working software, or at least not for long before we sink under a sea of technical debt. Our agile might look good on the surface but it becomes flaccid Scrum or cargo-cult agile with emptiness and disillusion at its heart. That’s obviously not good but, just as importantly, if these two sides of agile evolve independently we lose the dialogue between the different members of the cross-functional teams we champion. If the people side and the software side become siloed, we lose something really important. We lack mutual understanding and empathy which can undo a lot of the positive people things we’re trying to do.
The organising team for Agile Manchester 2020 would like to do some bridging between the two communities and encourage people to come and communicate across the divide. Do you have examples of how you fostered mutual understanding in your differing communities? Would you like to conduct a (cough) polite discussion on the uses and abuses of estimates with delivery managers, developers, QAs, platform engineers, UX specialists and product managers? Do you have a session inside you on “mob programming for traditional management types”? If so, please submit a proposal and help us build some bridges.
The other thing we would like to encourage is for you to turn your questions into topics for interactive and exploratory sessions in the form of workshops, fishbowls or other liberating structures. While it’s very useful to hear experience reports of how people have solved problems in their organisational context and sometimes these can give you a brilliant insight to take back to work on Monday morning, sometimes there don’t seem to be ready answers to the particular puzzles you are facing. Surely you can’t be the only person in the world with this burning question that nobody else seems to be talking about.
If that’s the way it seems, why not pose the question as a session for Agile Manchester 2020 and see if other practitioners can help you to figure it out, or at least come up with some suggestions. You may find that lots of others are struggling with the same issue and you can pool your thinking, or you may pique the interest of someone who hasn’t even thought about it but can bring a new perspective to your quest for knowledge. Collectively our community has gained a lot from these sort of sessions over the last 20 years both as session leaders and participants.