With what I do in my life, I visit quite many software development companies. From multinational corporations, via overgrown start-ups, to small ones, with just a dozen of employees. They’re all different, no story is ever the same. They aim at various markets, work using plethora of technologies, display all possible buzzwords of the last decade or so. There’s a common denominator though, which is Agile. Whoever works in software, for whatever reason, wherever in the world – they’re all the same at this one. It seems almost disgraceful to admit to work in some other way – that would be so 20th century! And whenever I ask them to show me their Agile, it’s always the same. Kanban boards. Magnets with photos. Burndown charts. Burnup charts. Software to streamline all these. And, inevitably, heaps and heaps of post-it notes, in every possible color of the RGB universe.
It’s so easy to fake Agile.
There is the Agile Manifesto. It organised and formalized what was already spreading in the software development world. The approach, if implemented properly, say using the notorious Scrum framework, may work wonders. Especially when compared to the dreadful reality of the old ways, where project management had laser focus on just that, delivering the project. Within the three constraints of time, scope, and quality (right – pick two) and forgetting the minute details like actual value for the customers.
Now, I do have my thoughts about the Manifesto, which is why I modified it slightly – you can look at it here. Send me a comment if you agree with it – or, even better, if you don’t. Essential point is, I believe it’s better to focus on managing value, not the product.
Which is where we’re coming to the actual problem. Whenever some organisation is ‘going Agile’, they look up the term and, inevitably, see the Manifesto. Which is not bad, however – it is so focused on the development process, it neglects nearly everything around it. In this spirit, regardless of whether you’re smart and start with the culture bubble, or insane and go full ahead, that’s where transformations always begin. We send packs of coaches to work with the development teams, introduce funny job titles, and spend small fortunes on certifications.
And there we have it! We have implemented the methodology X, which is known to be Agile, therefore, our organisation is Agile! Our development teams are now working, say, twice as fast, we’ve made it!
Oh, really? Let’s see one example. There was a small development team once, working within large corporation. On average, they could deliver their typical web-based project in about four months. Then, they went Agile. The results were nowhere close to the promise land of software in 30 days, though they did improve. One year along the way, they could deliver similar project in about two months. That’s a great success, isn’t it?
Well, yes and no.
Let’s zoom out the view, shall we? The team delivered typical project in four months. Before they got there, there was resourcing (one month), initial scoping (one month), decision making (two months – it was surprisingly short, given the size of the organisation and the fact it included budgeting), and inception (think of a R&D activity, two months). In total, that’s six months. On the other end, following development, there was a regulatory assessment (one month), followed by deployment and staff training (one month). All things accounted for – twelve months.
Once the typical Agile transformation was finalized, as said, the development time was halved. And with that great success, the time to deliver a project was reduced to mere ten months. Ouch.
I’m not, at any point, saying that when going Agile, we should not introduce Scrum or whatever other approach, methodology, framework to development. We should as it works and proved itself countless times already. I’m saying we should always take the following into consideration.
Think of the Agile transformation as the optimization exercise. It can be quite costly, so calculate the return of investment. Forget the development for a while. Instead, look at the whole value delivery stream – from marketing, pre-sales, sales, decision making, all the boring legal stuff – all the way down to post-delivery support. Odds are, your low hanging fruits will not be the development itself. Don’t worry, you will get there eventually. Just fix the most broken part first. If your car’s engine is dead, you don’t start with improving aerodynamics. That is, unless you want to drop it off the cliff in the most efficient manner possible.
Now, given the hype and specialization of too many agilists out there, it’s possible your organisation is already Agile, with your development working in sustainable, yet rapid, pace. Congratulations! I’m not sarcastic here. It’s not an easy feat, so some acknowledgement is in order. What I’d like you to do now, is to zoom out. Look at the value stream. Look at the tools you already have and know – Kanban, transparency, backlogs, retrospectives, limiting Work-In-Progress, cross-functional teams, whatever else there is. Start applying and verifying them elsewhere, experiment beyond development. The very same mindset, used to optimize development teams makes sense in sales, support, HR, management – wherever, as long as you have real people working there.
So, is your organisation Agile or do you just develop software the Agile way?
Opinions are my own and not the views of my employers, customers, or clients.