Blow me down, its happening again…
I’m awake. I’m wet, its a cold sweat. Its the small hours of the morning and the dream is horrid….
I’ve been sent to Coventry.
I’m in a clients office waiting for a meeting to start. The development manager is telling me she has selected me to help them become Agile, she checked me out online and recognises that I am pragmatic. Thats why they chose a new tool called Kjsb, its pragmatic too.
Pragmatic.
God does she know how much I hate that word? Pragmatic to me? I recognise that Agile and Waterfall are points on a spectrum and that most organizations, for better or worse fall somewhere in-between. I recognise that every organisation exists within a context and you need to consider that. And even change the context.
But pragmatic? Pragmatic is the Satan’s way of saying “Heaven doesn’t work in the Real World(TM)”.
The CTO enters and is putting down redlines. He knows all Agile, but his people… its his people you see … you can’t trust them, they are like children, you can’t let them have too much say. They need a strong man to lead them.
They had a developer here once who practiced Agile. He did that test driven stuff. He didn’t give out dates. He gave Agile a bad name in the company. The PMO will never accept that.
Fortunately they have just bought Kjsb. This wonderful tool will fix everything. Kjsb has a feature that translates burn-downs into Gantt charts at the click-of-a-mouse. And back again.
The problem is: teams still aren’t shipping on schedule. They need predictability. Predictability is what the one thing really need.
And flexibility. Flexibility is important. Flexibility and predictability, the two things they really need.
And now variation in features. They can’t trade features for time. Fixed scope, Flexibility and Predictability are the three things they need.
But… they have unforeseen technical problems – not bugs you understand, but unforeseen technical problems. They really need to be able to deal with those things. Technical fixes, fixed scope, Flexibility and Predictability are the four things they need.
I want to explain queuing theory… a grasp of basic queuing theory is the one thing they need – stick their feet on the ground and cement them to it.
One of the teams runs Agile. It is run by the CTO himself and its good. The other teams… well they don’t really have that much experience. Though the managers are going to get their Scrum certificates real soon now.
How, he asks, can we get everyone else to buy in?
How can we get the PMO to buy?
How can they make the Product Owners buy in?
Mention of the PMO stirs the old guy in the corner, the one who’s hiding behind his laptop, the widescreen laptop with the numeric keypad. And mention of the Product Owners causes the Analyst in the other corner – the one hiding behind the ultra thin laptop – to raise an eyebrow.
Now I see they all have laptops out in front of them… and some of them phones too. In between moving their mouths each of them is staring at their screens.
I’d better say something. “Well,” I start…., “how about we get people from the team who are doing this well to talk about their experience?” Blank looks all round, are they listening?
Or doing e-mailing?
“Could you them your own case study?”
No – that won’t work because that teams are so very different from everyone else in the company nobody will believe it. They are all individuals.
Besides, the developers won’t be at the buy-in meeting. Its for managers to buy in. Once the managers buy in the developers will be told what to do.
….
I try a different approach: “Instead of talking to the PMO one day, and the Product Managers the next day, and the Development Managers the day after… why don’t we go vertical and take each development team in turn, with the appropriate project, product and development managers?”
No. Managers manage, they are the only ones who need to know. And they are the ones who will be allocating the work with Kjsb.
“Need to know” – “Allocating work” Did I really just hear those words?
Whose version of Agile have they been reading?
O my god, these guys are going on a Scrum Master course next week, there is going to be a bun fight, I don’t know who I worry about most these guys or the poor sod who is teaching the class….
“Can I just check,” I ask, “each team has a project manager assigned, a product manager, a team lead, they will soon have a Scrum Master too?” Heads nod, “and… there are several development managers spanning several teams each?”
Yes.
“So if I’m counting right…. each team contains about 4 developers and 1 tester? (Plus UAT cycle lagging several weeks later)”
Yes.
“O see…” Am I keeping a straight face? Does my face hide my horror? 3+ managers for every 5 workers? – either this business prints cash or they will soon be bust.
….
“Really,” says the development manager, “we are talking about change, I have 12 years change management experience from call centres to financial services, the CTO hand picked me to lead this change, software development is just the same as any other change”.
When did Fred Brooks come into the room, in fact what is he doing in Coventry, he lives in Carolina, why is he wearing a dog collar? And why is it 1974? He’s now standing at the lectern reading from a tatted copy of Mythical Man Month.
“In many ways” says Brooks, “managing a large computer programming project is like managing any other large undertaking – in more ways than most programmers believe. But in many other ways it is different – in more ways than most professional managers expect.”
Well this is a dream, what do I expect? Its 2014 again…
“The key is to set the framework,” she continues, “establish boundaries so people know what their responsibilities are then we can empower them”.
Fred has gone, standing at the lectern in dog collar is Henry Mintzberg – my management hero – he is reading from another tattered book entitled Managing:
“the later term empowerment did not change [manager control], because the term itself indicated that the power remained with the manager. Truly empowered workers, such as doctors in a hospital, even bees in the hive, do not await gifts from their managerial gods; they know what they are there to do and just do it.”
Empowerment is dis-empowered: using the words say one thing but the message given by using those words is the opposite.
“What we want is consistency across teams” says the CTO who now resembles Basil Fawlty.
(What happened to “all my teams are different”?)
“And a stage gate process” says the PMO man, or is it Terry Jones?
“And clear roles and responsibilities” says the Cardinal Fang.
“Nobody expects the Spanish Inquisition” says Michael Palin – where did he come from?
….
“It seems to me” starts the Product Owner “that we are making a lot more paperwork for ourselves here”.
O the voice of sanity!
“Yes” I begin…. “if you attempt to run both an Agile and a Waterfall process that is what you will have!”
Silence. I continue, “Over time, as you see Agile work, as people understand it, I would expect you will move to a more Agile approach in general and be able to reduce the documentation.”
“No.” The PMO seems quite certain of this, “I don’t think that will happen here, we need the control and certainty that the waterfall and our stage gates provide. We won’t be doing that.”
Poor Product Owner, if he is lucky he’ll be shown the door, if he’s unlucky he’ll be retained.
…
“If you want people to buy in” I suggest, “we must let people have their say.”
The PMO is ready for this: “Yes, we know that, we’ve already arranged for a survey” and she reads the questions:
Q1: “Do you agree our development process needs to change?” Yes or No.
Q2: “Our organization wishes to remain in control but we want the benefits of Agile, do you think we should:
- Embrace Marxism in its entirety,
- Mandate Waterfall throughout the organization or
- Create a Managed Agile process?”
Q3: “Have you seen the features provided by Kjsb?” Yes or No.
O my god, its a North Korean election.
I suggest the questions are a little bit leading. “Well we don’t want people being awkward” chips in the CTO.
…
We get up to leave.
“You know,” I say, “when you’ve had a chance to run this process for a while you will want to inspect it and modify it” – but while I’m saying that I’m think “No plan survives contact with the enemy, start small, see what happens.”
“O we’ve already done that. This process is the result of doing that. We won’t be changing it.”
…
Back in my kitchen, a warm milk in my hand. A bad dream.
It was a bad dream. That stuff never happened. How could it? The contradictions are so obvious even a small child could see them. Couldn’t they?
As I climb the stairs back to bed a terrible thought: what if it wasn’t a nightmare? what if it was real? and what if they call me back for help?
Could anyone help such people?
| Reference: | Nightmare on Agile Street 2: Managed Agile from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
Good article. I have seen good agile projects and bad agile projects. My first Agile Project was the first where I was technical and team lead. I wanted to do it agile to see how agile worked. So luck for me we had a project manager who really understood agile. He set out a few (and a very few) guidelines and let us discover the process and what worked best for us. We had a long term design. Did Sprint Planning meetings and Sprint Retrospectives (often in the same meeting) and included the client in on each. We started off… Read more »
Thanks Stephen,
I’m sorry to say I’ve seen Agile used in this fashion too :(
allan