PS A discount code for my December workshop

Learning Connexions and I are running my “Requirements Backlogs and User Stories” workshop next Monday – 3 December in London. They have set up a Black Friday discount code which is only good today and reduces the price by 20% – so just under £500 for a day (including lunch!)

The code is: BLUEFRIDAY2K18
And actually it works with all their courses not just mine.

As for the day itself, the title pretty much says it all. We do some exercises, we review some actual user stories, we value some stories and we talk a lot. I deliberately keep the classes small so that we have plenty of time to discuss the things attendees want to talk about.

Most of the attendees are Product Owners, Product Managers or Business Analysts. We also get a few developers and project managers along too. But whatever your role I’m sure you will learn something,

And sorry, if I’d known this a few days earlier I’d have included this in my last post.

Money talks: A tale of two change programs

iStock_000005509580Small-2018-11-21-13-12.jpg

Like many in the agile community – or what sometimes gets called the agile industrial complex – I am all for piecemeal adoption, small scale before large scale, get good at doing stuff then expand it out… – what else would you expect from Mr Diseconomies of Scale?

The “start small” and grow might even be regarded as the canonical approach to agile implementation. But from time to time I run across something that makes me wonder…

Four or five years back I got involved with an agile transformation programme at a large financial institution, not a bank, more of a mass market asset manager. I was attached to a small team trying to make the whole company agile.

The coaches viewed themselves as a guerrilla movement, changing the organization from within. They had some success, there was a bunch of stuff the agile teams and the coaches were doing wrong but that is another story. This was a licensed insurrection.

As is often the case, this team found it lacked the ability to ask the big questions and get people outside the team (often the higher ups) to engage or change themselves. The organization wanted agile down in the engine room – at the code face – but they didn’t want to rethink how they set requirements and approached projects. The whole organization was chronically project driven, obsessed with long term planning and offshore development. Economies of scale thinking ran riot.

Because the agile change was at the team level the product owners lacked authority to make real decisions – like not delivering functionality. Yes the organization wanted to “be agile” but the management cadre didn’t see any need to change their own behaviour.

One day I met two men who ran the company’s “Software Process Group.” They were guardians of the formal process and “working practices”. My immediate reaction was that they wanted to kill agile and stick with ISO-9000, PRINCE2, CMMI and certified approaches. They scared me. But actually they were very clued up. They got agile. They saw it was better than the current process.

These two had no role in the agile transformation, their role was to ensure the company kept its CMMI level two certification. This was really important to the company because this allowed the company to do business. They told me a story…

During the previous 20 years the company had grown large, very large, by buying up competitors and companies in related markets. These companies had been thrown together and costs stripped out. One day the financial regulator came to the company and said:

“We have been examining your IT functions. They are not fit for purpose. If you don’t fix it within 12 months we are going to withdraw your license to do business.”

Shit hitting the fan doesn’t come much bigger than this.

The company went to IBM and said “Help! – Fix it – we’ll will pay anything.”

IBM flooded the company with people. IBM imposed a process – a traditional CMMI compliant process. IBM changed the company, not just the programmers but everything. The company did as IBM told them.

And don’t imagine it was cheap. I bet that the change and IBM fees were on the agenda at every board meeting during that period. The men I had met were the remnants of that programme, they worked for the company not IBM, their job was to ensure the company maintained accreditation and the financial regulator wouldn’t have cause to come back.

Now contrast this with the piecemeal, small scale, bottom-up change that us agile folk are so fond of. Time and time again we get stuck: “the business won’t change”, “we can’t get access to the senior people”, “existing processes and expectations are unassailable”, “projects are killing us” and so on.

I’m sure IBM faced many of those same problems but they had one big advantage: They were expensive.

OK, they had a second: the loss of license would destroy the client company. But when threatened people often respond by sticking with that they know so maybe it was a double edged sword.

Because IBM were expensive they had access to anyone they wanted access too. Because they were expensive they had authority. And if someone didn’t want to make the changes IBM suggested then IBM could simply ask the next person up.

Once again money is information: by spending lots of money with IBM the company was signalling it really wanted these changes to happen.

Agile changers may not like big change, they may point to the inherent risks, they may point that use of authority conflicts with self-organization, they may understand that diseconomies of scale rule and they may point to a bunch of other risks.

But they should also note one clear advantage: a big expensive change programme brings authority all of its own.

Agile won the war but lost the peace

iStock-856693018Medium-2018-11-8-16-53.jpg

“I’ve spoken of the shining city all my political life, … in my mind it was a tall, proud city built on rocks stronger than oceans, wind-swept, God-blessed, and teeming with people of all kinds living in harmony and peace; a city with free ports that hummed with commerce and creativity. And if there had to be city walls, the walls had doors and the doors were open to anyone with the will and the heart to get here. That’s how I saw it, and see it still” President Ronald Reagan, Farewell to the Nation, January 11, 1989

Back in 2001 when the word agile appeared it was a manifesto – a set of ideas, the term “agile” also served to group a bunch of tools and techniques which could make software development “better.” More importantly to my mind, it painted a picture of a shining city on a hill we all wanted to live in.

Agile was a place you wanted to go, it was a journey you wanted to make, it offered hope. More important as the tools – sprints, stand-ups, etc. – and approaches – just in time, last responsible moment, test first – were the stories agile people – including myself – told. These were stories of a better world, of that shining city on the hill.

And not unimportantly, in a world of search engines “agile” gave you something to search for. Before agile you could search “make my software development team better” or “software development process improvement” but what you got was a very mixed offering. AltaVista (and the young Google) would suggest links for CMMI, or ISO-9000, or vendor tools to “fix it”, or proper design, or… there was no coherent message. Most of these ideas resolved around senior people making big decisions and then imposing them.

Then along came agile: it offered to involve everyone, everyone made decisions, everyone was happy and we could all go to that shining city on a hill – more than that, we all had an important part to play in building that city.

Today everyone is agile. Nobody is promoting traditional (“waterfall”) working, CMMI, PMI and everyone else has incorporated agile (to some degree). Not being agile is about as popular as leprosy.

But very few of us have reached the shining city on the hill.

Along the way agile has been watered down, in becoming compatible with everything else it is less different, it is less attractive, fewer workers are motivated to take the journey. And as “the powers that be” have found ways to bring control-and-command back to teams (maybe in the name of scaling) fewer people are invited to help build the city.

Ironically, as we (the agile community) has made agile management friendly we have made it less worker friendly. Today senior managers “get agile” and want their organisations to be agile. But those at the code face seem to have less and less motivation. And those in the middle… sometimes they seem to want to change just enough to declare success but no so much that things really change.

For some people agile has become completely discredited – I wrote Why do Dev’s hate agile? last year and I’m presenting it in London next week. Agile isn’t a shining city on a hill, agile is trench warfare.

And Googling “agile” presents a long long list of links with less and less coherence.

Agile won the war. Agile is respectable and everyone is agile now. Big business rush to be agile, Governments want to be agile, blue-chip consultancies will sell you agile.

But agile lost the peace.

While many say they are agile, few software developers live in a shiny city. The place they live in might be better than the place they came from but it doesn’t live up to the dream many of us shared 15 years ago. Agile has become an excuse for failure and a thing to be imposed.

The thing that passes for “agile” today is too often a watered down version of the original dream. Worse still, we don’t have a word to describe that shining city we all want to get to. Russians have an expression for this:

“We wanted the best, it turned out like always.” Viktor Stepanovich Chernomyrdin, Prime Minister Russia, 1998-1999

Me? – I still dream of that shining city on the hill, I still believe agile is the right way to get there, I still wave the flag for agile but more and more I feel the need to explain myself and tell people that the agile I dream of is not the agile they may experience.


Receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”