It’s time for another rallying cry
The Agile Manifesto was written in 2001, and as one of the authors, Martin Fowler, puts it, the Manifesto was a ‘rallying cry to the industry’. And it certainly worked. The Agile movement grew and grew until it became impossible for the industry to ignore. Today, more software development teams work with Agile methodologies than without. Companies proudly boast of their use of Agile on their careers pages, conferences and blogging sites are filled with new and interesting ways of applying the practices and companies are increasingly hiring Agile coaches to spread the word internally.
But still today we see an overwhelmingly high failure rate for our projects. Despite being Agile, these failed initiatives cause companies to crumble, unable to change direction to ward off threats or capitalise on new opportunities in the market. Long work queues build up, our estimation efforts continue to be overly-optimistic and above it all we still haven’t figured out how to diagnose exactly where we’re going wrong. For many companies then, Agile has proven to be nothing more than a new way to make the same old mistakes.
Like many new initiatives, Agile is adopted with best intentions. Whether it’s a single employee who champions Agile practices, or a department who sponsors it, three key mistakes are made which cause severe damage.
The first is that Agile is sold to the business as a low-impact change. We inform the existing business stakeholders that nothing for them needs to change; they should continue their day-to-day as normal. Even existing roles are mapped almost one-to-one to roles within an Agile team. Take for example Scrum, which defines new roles. Project Managers are told that they will now be Scrum Masters. Product Development Managers are told that they are now Product Owners. And again, they are told that these are fairly low-impact changes. The Project Manager who ran project kickoff and status meetings now runs Sprint Planning and Reviews. A Product Development Manager needs to prioritise their requests into a backlog rather than whatever documentation they were using beforehand. Even worse than that, we tell developers, user experience designers and testers that there is no change for them at all. Their responsibilities remain largely the same, with the additional expectation of having to attend more team ceremonies.
There are often good reasons for selling Agile like this. Going to the department lead or CEO and proposing a change which would be so pervasive that every member of staff would need to be retrained is a hard-sell. It’s understandable then that many opt for the far easier route, bringing Agile into the company by badging it as a low-impact change that only concerns the development team.
But Agile is anything but a low-impact endeavour and failure to acknowledge this upfront leads to the second mistake: we then place the responsibility of embedding Agile on just a few people. Often this would be the Scrum Master, but eventually would also become the burden of an Agile Coach. The result is that the majority of the company is working the way it always did, with the expectation that all “Agile stuff” is handled by a few people. Within the development teams, this “Agile stuff” ends up comprising of calling stand-ups, updating burndown charts and scheduling planning, reviews and retrospectives.
Soon, this becomes the norm in the business. Business leaders continue to build long roadmaps, estimates are still made in the same way they always were and in the meantime Agile is seen as a project management methodology. The third mistake we make then, is that we accept this as the status quo, and in doing so accept that this is as good as Agile gets.
With this as our backdrop, the upcoming series of posts intends to serve as yet another rallying cry, with the aim of establishing a simple truth long forgotten: every member of an Agile team — from developers to Product Owners to business stakeholders — is an Agile practitioner.
With this simple truth realised, this blog is designed to educate individuals and teams on a range of Agile topics. The aim is not for teams to leave with a standard Agile setup, but rather to know which questions they should ask of themselves, the business and their customers so that they set themselves up to use Agile in a way which is most beneficial for them. If two teams went through the blog in parallel, I would expect them to both end up with a different take on how Agile will work for them.
On completion, teams will understand the trade-offs inherent with each decision they make, how the composition of their team affects the way they work and how to strive for continual improvement. Together, we’ll look into some well known Agile practices and terms such as Scrum, MVP, ‘fail fast’ (and more) and unpick what they actually mean. There will be practical guides too: teams will learn how to prioritise their work, how to measure their own performance and break big epic projects down into smaller bite-sized work. This mix of theoretical and practical lessons will equip individuals and teams to take charge of the way they work and then define the flavour of Agile which works best for them. Agile may seem novel to begin with; the aim is for it to become habitual.
But first we start with the most essential building block of Agile — and that is, knowing why Agile is worth adopting. I’ll see you there!
About Agile Bites
Agile Bites is intended to be a series of “bite-sized” posts — that is, each one is fairly short and can be read in the time it takes to have a cup of coffee.
These posts are written by Mohammed Rizwan, who is a self-confessed Agile nerd. With more than 10 years experience of working with engineering teams, I’ve had my fair share of memorable successes and also some spectacular failures. Despite it all, my love for building teams which are happy, motivated and proud of their work has endured, and led me to put what I’ve learned into this series of posts.
I sincerely hope you find Agile Bites to be insightful, useful and above all, enjoyable.
