Why do devs hate Agile?

Someone asked me this the other day: “Why do devs hate agile?” and as I worked through my answer I thought it worth writing down. There are three reasons I can think of but before we get to them…

First off, I don’t think all “devs do hate Agile”. Or rather, I don’t think the vast majority of them hate it - and hate is a very strong word. Sure some do, no doubt but all? A blanket “all devs hate” ? No.

I do think its is fashionable to slag agile off, and few do this better than the agile community themselves. And unfortunately like a lot of fashions once it gets started it catches on. Once dev A says “I hate Agile” then dev B thinks its cool to say it too, and dev C sees A and B doing it so joins in.

The ironic thing about all this is that Agile is the product of developers. In the beginning it was developers - like me - who saw that the classical way of doing things (write down what the customer wants, design it, plan it, code, it, etc.) didn’t work very well but noticed that the way most work actually happens (quick, code foo… O foo is not quite right change it, quick) was actually better.

I was inspired by Jim McCathy’s book Dynamics of Software Development. Jim was a developer, albeit a developer who had started managing other developers. It was that book that made me think “alternative ways are valid.”

Similar insights were occurring with developers all over the world - as they raced to fix Y2K using heavy weight processes. Some of these coders went on to become mildly famous: Kent Beck, Ward Cunningham and Martin Fowler for example.

And here in lies number #1 why “devs hate agile.”

Theft and imposition.

Agile was all about dev in the early days - especially XP. Just 10 years ago coders would say “I’d love to work Agile by my (project) manager won’t let me.” So we set about making Agile manager friendly, we expanded the business arguments for why Agile was good, and managers got it. Now you hear developers saying things like “My manager wants me to work agile but he doesn’t understand” or “My manager wants me to work agile but does’t help.”

In the beginning Agile was a bottom up movement. Now it is a top-down movement, change is imposed on people rather than people wanting to change.

That is wrong.

Making it worse is the fact that many of those imposing the change frequently fail to understand the change they are imposing or do not question their own thinking. Management thinking needs to change too - start with Software Development is Upside Down.

Reason #1: Agile is now an imposed change.

In my experience developers want to work Agile because true Agile allows them - no, demands - they do a quality job. Agile doesn’t deliver half the benefits it promises if organizations don’t pay attention to quality, that means their technical practices, thats what we used to call technical excellence. That means developers doing work that are proud of.

Namely “technical practices from XP”, specifically: simple design, relentless refactoring, test driven development (plus behaviour driven development), pair programming and things like face-to-face conversations and “story is a placeholder for a conversation.”

I’ll point the finger specifically at Scrum, and later Kanban, for not mandating these practices - something I did with Xanpan. Part of making agile acceptable to management was removing the words extreme and programming, and down playing the difference high quality can make.

Without these practices teams are driven harder to deliver something sooner and quality drops. As quality drops it gets more difficult to deliver anything in a short amount of time. Consequently more is demanded of coders, stress and tension rise and it is not fun.

Reason #2: Agile without technical quality makes developers lives worse.

I remember meeting some coders in Cambridge, almost the first thing they told me was “We hate Agile, our managers went on a Scrum course and have insisted we do it for months.” I quickly discovered that they were not doing any technical practices, as a result they were racking up more and more technical liabilities and making their own lives harder. Once I explained that they were missing the technical practices their attitude changed.

Now to the final reason, perhaps the big reason…

The Agile toolset is intended to help teams organize themselves, it is intended to make problems visible so they can be addressed and fixed. In the hands of people with the right attitude this is brilliant.

Teams don’t need a manager (although one may still be useful).

Teams can see problems.

And teams can fix problems.

But… the very same tools used by someone with the wrong attitude are a micro-managers dream.

Which micro-managers wouldn’t want everyone to give a status report at 9.00am every day?

Who wouldn’t want to see all work broken down to pieces for which NAMED individuals could be held accountable?

And why wouldn’t they want to make a shocked face and send a very clear “that is not acceptable” message every time an estimate was high?

Visibility becomes a tool of blame.

I once helped a team at an airline set up a Kanban board, instead of using it to see bottlenecks, problems and find opportunities to improve the managers concerned used it to assign blame, point fingers and demonstrate that nothing was happening because someone else wasn’t doing their job.

Reason #3: In the wrong hands the same Agile tools are very effective micromanagement tools.

Clinic: Product Owner/Manager question

An old product manager friend writes….

“Just started a new gig as senior product manager at blah blah blah

Discovering that scrum teams aren't organized around products but rather engineering components. For instance a product manager has to work with three different scrum teams:

- front end

- back end

- data science

This makes it hard for Product Managers to manage but I assume easier for engineering. I've not encountered this before. Thoughts?

At any given scrum meeting there may be two or more product managers, as opposed to a single product manager per scrum team.”

OK lets see…

The organization is horizontally organised, not good - we’re back to Conway’s Law. Getting anything of business value delivered is probably going to entail getting the front end team to do something, the back-end team to do something else, and then the data science team to do something…

Now it is possible that that is the way the work falls. Its just possible that a lot of the work falls inside one component, e.g. data science, and that alone delivers business benefit. If the majority of the work is like that then horizontal organization makes sense.

But, in my experience that is rarely the case, and your comments suggest this is true here too.

Think of it in user story terms: stories rarely relate to one function, you are far more likely to need a little bit from each functional team. No one team can complete a whole story, they need the other teams to do something.

This makes work for project manager types to do - has team A done their bit so team B can start and why aren’t team C talking to team A?

The approach normally advocated by agile folks is Vertical teams.

Each team should be staffed to delivered business value itself: if it needs a representative from each function then so be it, if team members need more training, or need permission to go into a different part of the code then make it so.

Horizontal organization is’t that uncommon, it is usually adopted on the grounds that you need specialists and specialists need to focus on one thing. While you may still need specialists you want people to cross boundaries and do be business priority driven.

Then there is the question of product managers and product owners, o not again…

In this context the product managers ARE the product owners. Pick up the Scrum book, replace every instance of “product owner” with “product manager” and things are clearer.

And it is OK to have multiple product people in the scrum meeting - by the way, when you say “Scrum Meeting” do you mean “Stand up” or “Planning” meeting? Either way it doesn’t matter, you can have two Product people in each.

The important thing, especially if you mean the planning meeting, is: the product people speak with one voice.

Perhaps they have a common backlog.

Perhaps they have a pre-planning meeting of their own to decide priorities.

Perhaps they divide the work up as Strategic Product Owner/Manager and Tactical Product Owner/Manager.

Perhaps they agree one looks at segment X and the other looks at segment Y and they compare notes.

However they do it they need to speak with one voice. They need to agree.

A more interesting question is: why do you even have two?

Do each focus on different markets? Different aspects of the product? Or different time-frames?

It is entirely possible that if you had two vertical teams instead of three horizontal teams that one PM feeds one team and the other PM feeds the other team. In between times they both get out and see customers and decide between themselves what the longer term strategy, tactics and plans are.

Heavy lifting is the easy bit

If you want to annoy me say something like “Building software should be like building a house…”. To say I’m not a fan of physical building metaphors is something of an understatement, but… I think I may have notice something.

Take that picture above, no they are not space rockets, they are swords.

The Sunday morning, for the first time in something over 35 years I engaged in making something out of wood, calling it carpentry is an extravagance, but my sons wants to do some sawing - and all boys should get to saw shouldn’t they?

Specifically they wanted some swords to play with, so out came the bench, out came the saw and… Not bad, I’m a real man! - I can make children’s toys!

Look closely at the swords and you will notice that down towards the handle they have a pair of “wings” - actually they are meant to be hand guards. This was a requirement I only discovered during construction when the older boy decided his should be different to the younger boy’s.

So yes, requirements change and expand when you build real things too. Especially when innovation and differentiation are in play.

When he asked for this I had no idea how I was going to do this. Rather than stop and work it out I thought “umm… maybe he’ll forget, maybe I’ll think of something” - and carried on working.

I did think of something, I realised that if I used the offcuts from the top I could create the desired effect. Now here is the lesson.

Constructing the first sword took about 20 minutes - without the “wings”. The second sword took less time, maybe 10 minutes - again without the “wings” - because I knew what I was doing.

The process went surprisingly smoothly and I discovered I remembered a lot of both my school woodwork and time in the garage with my own Dad.

But, then I started on the “wings”.

These small additions took the same amount of time again, perhaps even longer. I also got into a mess with nails, screws and ended up using wood glue. The beautiful smooth finish is now broken by a protruding nail.

Put this in software terms: it took less than half the total time to constructing the two basic products, building the infrastructure went smoothly. It was the additions and “nice to haves” - or rather the innovations - that took up most of the time and caused the greatest problems.

Last autumn I had builders in change my house. In the first three weeks the basic product was created: a physical wall was taken out, an external door bricked up, a window moved and the floor, electrics and plumbing ripped out. All the heavy lifting was done quite quickly.

Things slowed down, it took another three weeks to construct a new internal closet and lay a new floor.

It then took another six weeks to finish the plumbing, electrics, finish off the construction, fit a kitchen and decorate it.

See? The heavy lifting, the bit most visible, the bit which actually requires physical work is done quite quickly. It is the detailed work which goes slowly, probably because it requires attention to detail.

It was damn frustrating: the hard bit was done, the wall was gone, a steel beam installed, why wasn’t everything else just done? Maybe I should speak to the main guy and say “can we get more people in?” or “can’t we work in parallel now?”

Isn’t this like software?

I got Mimas up and running in a week or two but it took me another couple of months to get all the ins-and-outs working the way I wanted them too.

You can install a WordPress site, even with Magento, in half a day. But getting it styled right takes weeks.

You can build a rough bare bones app in a few days. But doing all the detail takes months.

And many efforts are so scared of heavy lifting the try to project manage it away and the project management becomes more than the real work.

The problem is: to those who are not doing the work - my kids watching me, me watching the builders, your customers watching you - the bit they expect to take time - the heavy lifting - is actually quick. It is the detail that is slow.

Writing this now it occurs to me that this is exact what happens with ERP systems. SAP, Microsoft and Oracle come along, install the basic ERP and it is there in a matter of days - hurray, all the hard work done! Just detail, mere “configuration” left to do. Except the configuration is detail and detail takes time.

Its also true of blogs. Blogs like this I can bang in a few minutes. I take far longer editing them.

Once again the world is upside down.