I haven’t blogged in a very long time and the half finished state of my last post is annoying as I’ve lost my thread of where that was going but I might go back to it. World of Warships has destroyed that lovely routine of blog posting (SD149_maxi - feel free to add me).

Anyway, here’s a small agile rant:

Imagine going through a load of features a client wants for an hour and then your team is asked how much of this do they promise to do in the next 2 weeks?

There are 2 possible answers:

• a wild guess
• an estimate based on previous performance and/or extra analysis

So why do we call them ‘commitments’?

They’re not commitments in any shape of form (see a dictionary). The project managers call them commitments as they can hold the team to ‘account’ and at least have a reasonable option of getting the team to do overtime. The alternative of changing the plan is a scary thing at some companies.

It goes back to the usual output vs outcome argument. Having a team constantly reaching this short term commitment means they will:

1. Cut corners to do so, putting long term strain on the code and therefore the product (and the skill of your developers). This is common, and it’s a team that’s constantly ‘pretending’ it’s hitting targets when in reality it isn’t. This is dishonest and it comes back to bite the team later on.
2. Make very safe estimates, hopefully doing things properly. Exceeding expectations is always good but it does potentially slow the team down. In process-heavy environments where stories have to go through certain meetings or where the product owners aren’t always around the commitments get met but nothing more because nothing else is ‘ready’.

Point 2 might seem like the best way to proceed but there is a better way.

The developers and the project manager/product owner/whatever could start working together as a team and be honest with each other and call it an estimate. That’s all it will ever be.

You’d think such a reasonable proposal wouldn’t get much push back, but a warning: it did when I made it.

The first response is usually from a misunderstanding of scrum, a misunderstanding frequently still taught on ‘scrum master’ courses - that the team must make commitments to a set of stories. The scrum guide says something different.

The other response I had was how we make sure the team is ‘pushing themselves’. I think this may stem from too many managers reading heavily marketed books from people like Simon Sinek and then trying to bring some of that ‘stretch goals’ stuff into software. The problem is the majority of practices that have come about in software have not come from an environment of ‘urgency’.

You don’t decide “I’m going to write tests first from now on because I’m under so much pressure”.

Or, “I’m going to release 5 times a day instead of once every month, that’ll speed us up!”.

You don’t reach these conclusions by frantically hacking away as fast as possible and ‘delivering’. You get there by explicitly deciding “you know what, I really hate this API and so does everyone else - lets spend a day making it better”. You run experiments that don’t always pay off but when they do you gain from them for the rest of the project - it’s a snowball effect. Most products live a long life time, those paybacks end up being huge the further you get into a project.

An environment of urgency also sets you up for a whole load of pushback for suggestions like this. You’ll get the “we shouldn’t waste time on this” or “it doesn’t deliver any value for the customer” and sadly most people will back down at that point. If I’m honest, if I care about something enough and I’m pretty sure it’ll bring benefits I’ll do it anyway with or without permission. Perhaps ‘unprofessional’, but equally you don’t hire professionals and constantly tell them what the best way to deliver software is. I think I probably lost the ‘professionalism’ argument when I mentioned I stopped blogging because I’m constantly playing World of Warships anyway.

Every ’environment of urgency’ I’ve been in, you’re faced with developers that have miniscule amounts of practice in refactoring and testing to the extent that it takes an extremely long time to do and they largely don’t like doing it. I don’t think I liked refactoring at the beginning of my career, you just want to get the story delivered but you can’t because you’ve got to change some other persons code. You also risk breaking something and being the one to blame for it, it’s easier to just skip it and leave it for someone else to sort out. I like to compare operating in this way as being similar to sitting on the rev limiter in first or second gear - it sure sounds like you’re going fast but you’re not.