The Agile Elephant

I remember, way back now at almost the start of my career as a Business Analyst, a company I was at deciding that wow, UML, Unified Modelling Language, that was the way to go with all our documentation. It would make IT development so much easier. As BAs we had to start, immediately, doing everything via use case - those little stick men drawings augmented with process step descriptions with happy paths and alternative paths. And I was happy enough with that, I quite like use cases. In the right context, for the right piece of work, they can be incredibly useful. (At other times, they’re useless, but that’s probably for another article). The problem I had with this decision at the time was that I thought it was fine to make the IT department work in a particular way, but what about the wider business? Would my stakeholders understand a stick man diagram? They were the ones who had to sign them off, had they been on UML training too then? The answer, of course, was no.

Eighteen or so years later and I’m seeing precisely this same problem with Agile.

I’ve said before, I like Agile. I like the discipline of writing requirements as user stories with acceptance criteria that will determine whether the product owner can sign the work off as completed. I prefer doing this in tickets on a virtual wall with links to context and further detail if needed written in a Wiki. That’s much better and leaner for me than the old days of maintaining eighty page functional specifications and requirements catalogues in Excel with a requirements traceability matrix to tie the two things together. Every time something changed, going through and making sure you didn’t forget to update one of the myriad of dependent records that linked to it. I like the fact that a ticket can be blocked and everyone can see it, I don’t have to be the one banging on to project management about getting something sorted. And as for standups - I’m guaranteed that for fifteen minutes each day I will have access to someone who is otherwise too busy to speak to me and I can bombard them with the questions I have, in earshot of the rest of the team.

But whilst the IT teams I’m working on are Agile, the wider business, often, is not. This is a problem. This is a much bigger problem than the business not really getting those stick men diagrams. I’ll explain why.

Methodology

Every other methodology I’ve ever used is precisely that: a methodology. A technique for doing something within an otherwise fairly established project delivery structure. Remember RAD? Rapid Application Development? That was fine because we did a bit of prototyping, we factored that into the plan. Then we refined requirements through the prototype, that was in the plan. Then we productionised it, and tested it, and released it, all moving in a straight line to that date someone had set for us (usually plucked out of thin air, but a date nonetheless). The date was key. If we were in danger of missing it you could compromise on cost, scope or quality. You couldn’t compromise on time (although every project always did slip, in the end, but we always pretended it couldn’t). No difference really between this approach and waterfall in the end analysis.

Agile is different. Very different. It’s the first method to challenge that compromise constant. In Agile, cost is theoretically not a factor. Neither is scope - you’ll get there in the end, or not if you decide you don’t need to. You can compromise on quality, but the theory being you just build up technical debt that you will get to at some point (or not, again, if you decide you don’t need to). And time, that date, that constant that was so fixed in every other approach, is meaningless. Something takes as long as it takes. You can predict how long, roughly, by looking at your velocity once you’re already doing the work. And you can take remedial action to adjust that velocity. But, fundamentally, Agile is not time constrained.

Duh, everyone knows that right? Well, you’d think so. But they don’t. Not really. They know that’s the party line, they have no problem with it in theory, but when it comes to meeting critical business ask, those asks tend to still be deadline driven. “We need this in before x date because that’s the time of year that we have a big promotion and make most of our money”. “We need this in by y date because that’s when the law changes and we will otherwise be non-compliant”. I guess it’s kind of a shame the financial ombudsman doesn’t come to standup and go away happy that the burn up chart is showing him we’ll be free from the threat of prosecution soon enough…

Most of the Agile team tend to be a bit shielded from this problem, most of the time at least - admittedly sometimes reality does bite. But in the meantime, Business Analysts (if there are any), Project Managers (if there are any) and Product Owners are getting constantly battered by the same type of question my daughter used to ask on a car journey: “are we there yet?”

What’s the Solution?

Well, running your project in Sprints rather than Kanban is always a start. Seems obvious, but Kanban is usually the go to method for some reason, despite being the least compatible with time driven demands. Even then though, there seems little room for manoeuvre between the two worlds. “Let’s get that velocity up by throwing more resource at it”. Fine, except recruitment has a lead time too, and the other projects you want to pull from have the same business people screaming about a deadline.

Ironically, it really has to come back to timing. In order to give an Agile project it’s free floating bubble outside of the space/time continuum, you realistically need to plan massively in advance. But isn’t that antithetical to the benefits of Agile? Yes, yes it is. Well, kind of. You can still harness its flexibility and react to changes in priority, it just means you need to be much more on the ball in getting started. It’s no good waiting until the last minute before kicking something off to try and get it done in a mad frantic dash (as most projects, let’s be honest, are managed). You need to be further ahead of the curve, kick them off well in advance of any looming completion dates. Business strategists need to get better, need to be thinking and working twelve months in advance, not two months in advance. Roadmaps need massive amounts of contingency in them.

Oh-my-goodness. “I thought Agile was going to mean we get everything quicker?” Well, it really depends on your definition of quicker doesn’t it? That’s kind of the great myth of Agile. In reality, you’ll probably get something quicker. But it won’t be the sum total of what you want. That will still take as long as it takes, which will be roughly the same as it was under waterfall. If you can live with that something, if you design that MVP, or the next release on from that, to be sufficient for the big promotion or the ombudsman, then that’s probably going to be ok. But too often it isn’t. You still need the thing to be the full thing, in which case, Agile can’t really help you any more than any other methodology.

I sound like I’m Agile-bashing and I’m not, I promise. I’m just trying to be realistic about it. If it would be nice to have a new shiny piece of functionality at some point, but there’s no pressure, let’s work through it in a nice trendy collaborative way, then great. The business understand that though right? They’re not still working to absolute deadlines in that old Jurassic way of yesteryear? Hmmm.