My issues with the Agile Industry pt. 2
Agile started out as a set of principles, defined by a very smart bunch of software thought leaders, in 2001. They based their principles on the issues they had seen within the software industry, and strove to do better by building the right thing for the right people, sustainably and with principle.
Fast forward 15 years, and we have an agile industry. We have frameworks, methodologies, businesses, conferences, books, certifications and endless amounts of people all getting involved in one way or another. It’s so big now, that government and industry is mandating that software projects use agile methodologies. Sounds great; 15 years from principle to “business as usual”. Or is it?
Snake oil salesmen
The conference circuit is massive. Yet, if you go to enough, you’ll see that there’s an awful lot of the same people pitching and pedalling their wares. We’re back to the snake oil salesmen, selling us the magic potions that can cure all that ails ye. This is particularly rooted in the Agile Games that appear at every conference without fail. Whether it’s using Lego to build a way out of an hour-long slot, improvisation techniques to make yourself feel utterly self-conscious, or just a rubbish version of monopoly because it’s a game that nobody knows how to finish ever, they’re ubiquitous, yet to me, utterly mystifying. They are all run by the same types with their incredulous job titles (see previous), and embracing their inner child, dressing as pirates and pixies. And you have to wonder:
- how does one get a job pedalling such utter crap?
- why do people pay good money for this bullshit?
For a start, games aren’t going to help you build a team. They may help break down a few barriers; “hey, if Steve’s willing to make a fool of himself, well why shouldn’t I”, but ultimately, games are about winning. And if you don’t win, you lose. So there has to be a better way of helping teams.
I have to caveat this by stating that I’m a huge sceptic. I go with my wife to church regularly, and have done so for the last 10 years, and am still resolutely atheist. So if I can’t be convinced by deity, you’re not going to convince me that a game or drama technique will solve my team/project/customer/user’s problems. Like the church, I’ve been willing to give them all a go, and like the church, I’ve left more puzzled than I was when I went in.
It all points back to my aversion of the non-credible. How could I comfortably participate in or deliver this if I don’t believe in its value? I couldn’t. And to be honest, neither should you. So beware the snake oil salesmen.
Users? Who?
Agile came about as a way of solving business problems through better software. At the time of the signing of the Manifesto, Waterfall was prevalent, with its gated phases, aversion to change, and glacial delivery. Agile shook it up, allowed for rapid change, rapid delivery and frequent feedback, and perpetuates this through its various delivery methodologies. However, one key thing is missing, and is not mentioned in either the Agile manifesto or the Scrum values, and that is the end user; it’s purely business focused. If you’re working in delivering Digital Services, that’s a massive thing to get wrong. And I’ve been unfortunate enough to witness some Scrum disciples in action, who collectively show utter disdain for good service design, user research and analysis, and laugh at the crazy talk of impact maps and multi-channel solutions. The Scrum disciple will see good software delivered often as a means in itself, and not part of a bigger plan. The Scrum disciple sees the team as the main component in delivery, and protects them, often from themselves. And they don’t see any of this as a failing. The most damning example I saw was a scrum master maliciously discrediting a user researcher within a project because they fundamentally disagreed with the researchers’ principles. Probably says more about that persons character, but still, a truly awful example of how a methodology disciple can get things so wrong.
The issue mainly boils down to Scrum laying product decisions at the feet of a Product Owner. These are representatives from the business, and have the business’ interests at heart, not the user. Its a process that’s at odds with the reality of service design, yet we keep making these mistakes over and over by allowing a business representative make broadbrush decisions for the end user without the research and analysis to back it up. And until we change the decision point from a single person with a business perspective to build a backlog, to using qualatitive research based on the results of bringing prototypes out to actual users, we’ll never build the right thing.
To wrap up, even though I may strike down Agile with great vengeance (and furious anger), I still believe it is a Good Thing™. Well, it’s the best thing at getting things done, until the next thing comes along that’s better. And that’s the circle of life…
