Some companies have got it right and are used all the time as “poster boy” examples of how it should be done — Spotify, Netflix, Google, Zappos, etc. I’m sure for them it works amazingly, but many normal companies are struggling.
It seems to me something has gone wrong with agile. I’ve been involved in software development for 20+ years and I remember what it was like in the old days of the analyst programmer, I was an early adopter of the concept of agile development and now living through almost a post-agile world. Lets go back to the start, the Manifesto for Agile Software Development:
- Individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
It’s simple, straightforward and almost impossible to implement, why is that? The biggest reason for failure I see is that businesses adopt agile anti-patterns as a means to implement agile and wonder why it’s not working.
Scrum and Tools (Jira or similar)
The most common approach is to adopt a process and tools, Scrum seems to be the most common approach, it gives the business a process to follow that appears to have structure, a leader called a Scrum Master corals the developers, people like Product Owners and Product Managers manage what’s getting done and delivered. If we do all this were being agile right? Except you’ve turned the first statement in the manifesto on its head. Often the Product guys are just playing at Project Managers and Business Analysts with different titles, using Product Backlogs, burn-down charts and daily scrums like project plans and project meetings. The end result is an anti-pattern I refer to as “ScrumFall”. Arrange the project into 2 week time-boxed “sprints” and the developers are held to delivery as before, projects are late, over budget, under resourced, as before…
Product Management
What is this? I’ve spoken to quite a few companies who are struggling with product management, I’m struggling with product management. I understand what people are trying to do, but it seems generally to be a new way of arranging Project Management and Business Analysis to give it more of an Agile feel. In the old days, the business took responsibility for specifying its needs, people who developed products were design experts and worked in teams with expert knowledge in their design areas, often collaboratively to create great products. During my time at Microsoft, a Product Manager was the person who headed up that line of business, knew the product inside-out and had the expert knowledge of that product, where it came from and importantly where it was going.
Often today the Product Manager is running a team of Product Owners who like Project Managers and Business analysts before them are controlling the workload, producing reports and requirements documentation. On more than one occasion I’ve heard Product Owners saying “That’s what the customer wants”, even though the developers know it’s not going to work. The second anti-pattern steps forward — Lots of documentation, little in the way of working software. The result is frustration, the developers are in this cycle of despair where it’s hard to deliver anything good, and the Product team think the developers aren’t delivering what they want. Everything slows right up.
The Customer?
The mythical customer, who is it? Is it the business? Is it the person buying the software from us? Is it the Product Manager? The Product Owner? The danger here is that the Product team become a proxy for whoever the customer is at any particular time. The customer is used in a kind of 1984esque manner to cajole developers into doing things, resulting in developers who stop asking questions and challenging the requirements in turn stopping them from producing the best possible software. The whole thing then becomes contract negotiation and the developers become so far removed from the customer they have no context why they are building what they are building.
“We want to be innovative without any change!”
I’ve heard this dozens of times in the last 15 years and I cringe every time I hear it. The word “Innovation” stems from the latin “innovatus” meaning “to renew or change” broken down further as “in”, “into” and “novus”, “the new”. If you are not changing you are not innovating.
Innovation is hard, especially with all the scrum process and various managers involved and targets and delivery dates, blah, blah. But it seems to me the ethos of the Agile Manifesto was to encourage constant innovation of the way you work to find a sweet-spot of productivity and efficiency. Change should be constant, requirements change, working practices change, change is good and should be encouraged in order to get the best out of the teams. Nothing should be staying the same, it would be like attaining perfection, the Thanos finger-snap moment knowing your work is done and going to sit out in the garden and enjoy the view.
Something has changed though, the attitude of developers over the years. When I started out most developers were looking for ways to do less with more, whether that was automating the boring stuff or finding quicker ways to a solution with less code. That in turn freed up time to do more interesting things and everyone had side projects, being a developer was a vocation not just a job. Here’s the nub, todays jobbing developer is reluctant to change, therefore not into innovation. How do you make that Agile?
Is there any hope for Agile?
Absolutely, but strip away all the gubbins and get back to basics. Agile doesn’t suit every task. If you are developing a 10 year old legacy platform it doesn’t make sense to try to undo years of structured development process into fast, loose and agile, it will probably break.
Find the right sort of project. Greenfield development on modern technology platforms are much easier to make work. With software defined infrastructure on cloud platforms with modern languages most tasks can be automated and delivery timeframes massively reduced. Get the right developers working on it, strip out process and bureaucracy and it will fly, even better if you can get developers who can ask the right questions when in direct contact with a real customer. Go one step further and put the developers working alongside the customer if possible. One of the best software developments I worked on used a method called DSDM and the entire team, business, admin, analysts and developers all sat together, lunched together, drank beer on Fridays together, we knew what needed to be done because we sat with the team doing it, there was no Product Manager or Product Owner.
The sticking point for me is requirements. I’ve got some ideas around this and I’m working on a software solution that looks to address a better way of capturing requirements for a productive agile team which i’ll cover in future posts.