Scrum doesn't work here!

Scrum is neither panacea nor silver bullet - there are situations where I honestly and openly advise against Scrum. Let me share with you a story that might just have happened like this. While it is hyperbolic, the core snippets are taken from real conversations I have engaged in.

Prologue

IT Manager: "We tried Scrum already. It doesn't work here".

Me: "Well, I want to know a bit more about that. Please tell me."

IT Manager: "We had a Scrum team a few years ago, but developers said it caused too many problems, so we reverted to our old ways of working."

Me: "It's interesting you mention developers complaining. What exactly were they complaining about?"

IT Manager: "I think it may be best if you go and ask them directly. I can't speak for them, but I fully support their every decision about their ways of working in the best interests of the company."

Me: "So, let me go explore."

IT Manager: "While you're at it, you can also have a chat with the other business divisions to learn what they think."

The Developer office

There are no visual indicators of work anywhere. Each developer arranged their three screens to form a type of cubicle, and they maximized the amount of space between each other. I approach one of them.

Me: "Kindly, would you ..."

Developer: "Can't you see I'm busy? Talk to Clara, our team lead!"

Me: "Who is the team lead?"

Developer (points silently to the person at the next desk)

Me: "Clara, would you ..."

Clara: "We're all busy. Deadlines, pressure, no time. You can set an appointment."

Me: "Ok, can we meet on Tuesday for lunch?"

Clara: "Check in Outlook. My calendar is up to date. See ya."

I silently walk back to my office. I open Outlook, a tool I haven't used in years. I check Clara's calendar. It is littered with appointments, most of which seem to be recurrent. I schedule an appointment for lunch on Tuesday.

Within less than ten seconds, I get a reply: "Tuesday is bad. I'm going with the team. Try Wednesday." I re-schedule for Wednesday. Too bad: Lunchtime is already blocked. Maybe one hour earlier? I set the appointment to 11. Another prompt reply: "We have management status meeting at 12. I need to prepare." At least Clara prepares her meetings. Well, I try 1:00. Without delay, the meeting is accepted. My first "success". So - what do I do now?

I look at the org chart. There are still analysts, testers and IT Ops, as well as 12 different business units on the list. I decide to go for the analyst team.

The Analysts

Will I experience deja vu? I enter another room. I look around. A single Letter format printout of the enterprise data model is pinned to a seemingly oversized, empty, 3-foot whiteboard. Again, no other visual indicators of work.

I start the conversation with a witty "Greetings, earthlings. Take me to your leader."

The analysts are more open to conversation, and we quickly engage in mutual dialog, during which I learn who the team lead is - and that he doesn't do appointments when there is time for a chat. Vijeh is kind, calm and outspoken. We go for a cup of coffee.

Me: "So tell me a little about the work your team does."

Vijeh: "Well, it's rather straightforward actually. We get high-level requirements prioritized by our manager, then work them off 'best effort'".

Me: "Tell me more about this prioriziation?"

Vijeh: "As far as I gather, the process looks somewhat like this: Business stakeholders who want something go to them, then every month, there's a Change Advisory Board meeting where the topics for the next month are prioritized."

Me: "And then you get a prioritized list?"

Vijeh: "We get a list. Everything on that list is Priority 1. We don't even get around to doing Priority 2 any more."

Me: "So, then how do you know which one to start with?"

Vijeh: "We just distribute the list, everyone takes one topic and off we go."

Me: "And then ...?"

Vijeh: "We create spec documents and then the developers work with them to produce the code, and testers to create test cases."

Me: "Tell me a bit more, how do you interact with developers?"

Vijeh: "We check our documents into git, they check it out. That's about it."

Me: "Are there ever any questions?"

Vijeh: "Not really. Most of it is straightforward, same old copy+paste with small variations. We learned already which questions they would have and know how to write accordingly. But if there are questions, they'll just pop by and ask."

Me: "How do you make sure developers or testers understand you properly?"

Vijeh: "If they don't, we get incident notifications. That doesn't happen all that often, so it's not a big issue."

Me: "Not often? How often?"

Vijeh: "Maybe three or four times per week. That's not bad. But it's no biggie, defects usually get fixed within a couple days, same-day if they're prio1."

Me: "Okay, another question, how do you know that you understand the demand properly?"

Vijeh: "That's not our responsibility. We usually don't talk to business. We just specify technical solutions for requirements."

I get an omen... "So, who talks to business?"

Vijeh: "The Requirement Engineers. They are from the Business Side. They are responsible for bringing properly defined Requirements into the CAB meeting."

I thank Vijeh and go on my way. Before digging further into IT, I meet with some people from the business.

Business Leader

Tami: "Thank God you're here! Someone needs to clean up that mess over there in IT!"

Me: "I wouldn't know about a mess, tell me more..."

Tami: "My team needs to work with 25 different applications, half of what we request never gets delivered ... and when something gets delivered ... let me show you this ..."

Me: "What's this? All I see is wallpaper charts*?" (* wallpaper = colorful bars and pies without meaning)

Tami: "Exactly. I ordered this ten months ago, and just got it last week. It's completely useless. Tell me: How am I supposed to run a division with this crap? I don't see what I need to see, I don't know what's going on and I am in blind flight mode!"

Me: "Have you tried talking with them?"

Tami: "We can't talk with IT. We talk with Requirement Engineers, hoping they get it right - and then hope the Requirement gets past the CAB. From then on, it's hope and pray."

Me: "I see. Any other problems?"

Tami: "Talk to my team, please. Small hint: Don't tell them you're representing IT, if you want to get out of there alive."

I thank Tami for her open words and take my leave.

Business Team

Tami's team is under a lot of stress and rather reluctant to talk. When I inform them that Tami is looking to me to make a change that might benefit them, their eyes light up.

Annie: "What brings you here, what are you trying to accomplish?"

Me: "Before we get into that, let me know how you work and what you struggle with?"

Annie shows me her desk. There are three monitors and two sheets of papers with various login information on the desk. She waves her hand around: "This is what I need, just to do my **** job. Every couple months, IT adds another system into which I must login. Most of my day is wasted copy+pasting data between different windows. The real art is finding out which information is hidden where."

Annie: "Now, just look at this ..." (she shows me a search form)

Annie: "Try to get it to work." Annie menacingly smiles at me.

I type in some data. Or, I try to. It's a dropdown menu - but without options.

Annie: "It's broken. For years already. And it just won't get fixed. Not important enough."

Annie: "And this is how we manage our work ..." - she opens an Excel sheet with shortcodes and explanations.

Annie: "We have to create mapping tables to find out what those cryptic identifiers mean. Good thing, over the years, we memorized most of them."

Nothing I haven't seen before. I thank Annie for her time and move on.

Epilogue

Not much to my surprise, 5 minutes before meeting Clara on Wednesday, she cancels: "Urgent appointment". In the afternoon, I head back to the manager's office.

IT manager: "So, what do you say?"

Me: "I've snooped around a bit. I just have one question: What has been changed since Scrum was abolished?"

IT manager: "We're all at least 120% busy, trend rising."

Me: "Have you tried making the work visible, so that everyone knows what is being worked on and where the load is?"

IT manager: "If we'd do that, people would feel even more depressed and overwhelmed."

Me: "Have you tried rank-ordering the work?"

IT manager: "Everything is already MUST-DO. The order doesn't matter, everything is better due today than tomorrow."

Me: "Have you tried bringing developers and analysts together?"

IT manager: "Then none of them could get their work done."

Me: "Have you tried bringing business and IT together?"

IT manager: "That would just end in accusations and blaming."

Me: "You know what - you were absolutely right. Scrum wouldn't work here. And let me tell you... there's something else that doesn't work here."

IT manager: "Now what would that be?"

Me: "Everything."

Conclusion

Scrum doesn't universally work. There are a lot of contexts in which Scrum will either not work, or even be counterproductive. In this rather facetious article, I have hinted at some of the situations which make Scrum difficult to downright impossible.

The three biggest impediments towards taking advantage of Scrum are:

1. Lack of communication
2. Unwillingness to change
3. Unwillingness to learn

As a coach and consultant, I will honestly advise my clients that unless they first resolve such organizational impediments, implementing Scrum is a waste both of their and my time.