Transitioning an Organization

> If they convince me that they are serious about shifting to proper Scrum...

Do you have a clear idea of the evidence you will be looking for?

Ian, thanks for asking. I don't have a checklist of what I'd be looking for, but I want to be convinced that management is ready to give up the traditional control to the teams for the planning and content, and prepared to defend "pain" (transitional loss of productivity, staff impact in the forming/storming/norming process, etc) as they move to real Scrum. And to understand their expectations in terms of time it will take, see if they have a reasonable idea of the opposition they will meet, and hear what authority I would be empowered with in my role to make it happen.

After this, I would spend a good bit of the interview process telling them the issues I see in the job description, what it tells me about the situation, and what my 90-day plan would likely look like. Their reaction to the critique should reveal a lot.

Now, if they are truly knowledgeable of Scrum, they could snow me into a false sense that they are sincere about this.

Any insights you can offer (or criticism of the above) is appreciated!

Hi Craig,

This sounds more like AgilePM, from APMG and it's a mix of DSDM and PRINCE2.

Proper SCRUM does not have a Project Manager. It's one of the fundamental differences to AgilePM.

My experience is that organizations that try to implement AgilePM will never move to proper SCRUM. The idea of having one person (the PM) responsible and accountable for everything that can go wrong with a project is still the preferred way to go for most larger organizations. I dare to say that some people in the organization actually look forward to it!

If your project is a success then there's no reason for them to move to full SCRUM.
If your project is not successful, they have a reason to stick to Waterfall in the future.

Organizations that are serious about the transition will employ a SCRUM Coach (not an Agile Coach who prob sticks to AgilePM) to guide the team (PO,SM and Team). Not a Project Manager/Scrum Master.

> ...and hear what authority I would be empowered with in my role to make it happen

That is a potential trap, because it is easy for them to say "we give you all authority". Then you find that you are not in a position to make anything happen. What they've done is to shift their organization's transformational risk onto you. It's an old trick, very often used by middle managers who want to walk away from the problem.

What you need to figure out is how the organization intends to provide sponsorship for adopting Scrum:

- What is their vision for agile change? Does that align to Scrum and/or Scaled Scrum?
- What barriers do they believe currently exist, to creating fully integrated release-quality increments, every Sprint?
- How are they going to work with Scrum Masters to overcome these barriers? (Hint: expect quality time from them, not a meaningless and misplaced "authorization")
- How do they intend to work with SM's to scope and order a shift to Scrum, and control transformational risk while the company is in flight?
- Who will own the organization's Scrum transformation initiative, and be responsible for its success? (Hint: it shouldn't be you, unless they're inviting you onto the board)
- Who will coach the change? (Could well be you and/or other SM's. If they intend to have a separate coach, find out what your relationship will be)

Ian,

Thank you very much for the added insights -- you've given me some focus for the discussion!

As not every project is suitable for Scrum, full transition is not needed. Running a Scrum project should be an option in the organization, not the new and only way. The introduction of a new methodology without taking away the old one might give less resistance.

Compare it to a family that has only played Checkers and one day Chess is introduced. How can the family transition to chess? Play checkers with chess pieces, or Chess with Checker pieces etc. You get the idea. Both games can only be played by their rules, their pieces and players need to know the rules and play according to these rules. Instead of forcing the family to transition to Chess, why not introduce it as an alternative game to play?

Run the new project according to the Scrum rules. Train the people in Scrum and don't try to create hybrids just because the organization is used to a certain way of working. Accept the alternative and don't take away the old ways.

Nobody is helped with a game of CheckChess or ChessCheck...

Nicko,
Thanks for the interesting analogy! The company I am talking to is a very significant one in terms of size and international presence. When I refer to transitioning the organization, I'm only referring to the part that is around this particular product delivery channel -- ie, the immediate family, not the cousins :)

My concern is that the family knows and is comfortable with checkers, but they've heard that chess is "all the rage" and players develop deeper reasoning skills. They look into it just enough to learn that it uses the same board, and they even both have "Kings". But, they aren't ready to go full chess, so they decide they should just rename the (non-King) draughts as "pawns", add a play clock, and otherwise continue to play the same way. After doing this for a few months, their kids still haven't qualified for Mensa, no scholarships forthcoming, and no one is any happier. Worse yet, when their checker-playing family friends visit, there is confusion, though not nearly as much as when their chess-playing family friends visit and want to play :)

I certainly take your point that not all efforts will be a good fit for Scrum, and introducing it as a new approach for a new project (without threatening or disrupting the traditional projects) has advantages. My concern is that this group already has a hybrid, using the Scrum terms (role names, events), but misapplying them. If they are really just swizzling labels around, but expecting a "Scrum Master / PM" to deliver the benefits of Scrum within that paradigm, the SM/PM will fail. I have many, many years of traditional IT Project Management -- if they want that, I can do it (not sure I want to). But if they really want to see the benefits of Scrum, they need to recognize the changes required and be ready to pay the transitional cost.

I appreciate the discussion!

Thanks Craig :)

Does your organization have a Project Management Office? If so, what is it's stand on SCRUM? One of the biggest hurdles is to get the buy-in/endorsement of the PMO. They can be very hostile to any changes and try to hang on to the traditional ways. eg. If you have to report weekly on Milestones then you have an issue as in Scrum you work on the backlog based on the highest priority items set by the Product Owner. This can change the day after the report. . Budget is measured against milestones, project completion is measured in %complete etc.

A few years ago I was silly enough to put my hand up for running the first Agile, half Scrum project. The CIO at the time wanted to 'stir things up' as he called it... and I got hammered by the PMO for not having a signed of business requirements doc, func spec, Gantt Chart etc I was summoned for Gate reviews according to the Waterfall Method. It was an absolute shocker. I was branded the worst PM ever..lol

If the organization is serious about Scrum, then one train of thoughts is to make the PMO responsible for Scrum training. In that way they are at least on board. Or if you're a PM with a good relationship with the PMO based on your previous experience with them, they might be more lenient in your efforts to run a full Scrum project.

If they are not on board then you'll be fighting a battle you won't be able to win and unfortunately the PM saying 'you're only as good as your last project' might do you more harm than good in the future.

There are of course plenty more hurdles to overcome, like how self-organizing are the Team members, do they sit and wait for detailed requirement docs by the BA or do they talk directly to the PO, how much authority does the PO have to make decisions or does he/she leaves that to the PM (a role that shouldn't exist in the first place). And the list goes on and on...

and when it comes to transitioning and trying to convince senior management then (in my experience) "Scrum is from Mars, Waterfall is from Venus" and both camps need to be approached differently. Acknowledging that is probably the most important step in any change process.

Another thing to consider is this particular project and it's suitability for Scrum. If it's not a good candidate then it's another reason for 'them' to oppose the change.

Can this project be divided in Breakfast, lunch and Dinner. Or Appetizer, Main and Dessert and maybe Coffee after?

In other words can we deliver real Valuable items in stages? When I go to a restaurant and I'm hungry I'm very happy to see the waiter bringing the Appetizer/Entree. That keeps me going for a while and I'm looking forward to the Main. After the main I know the dessert is coming and sometimes there is even room for coffee after. Can we deliver this scrum project similar to this/ If so then the value of Scrum becomes more obvious.

If we also have an option to skip dessert and coffee because we're full and satisfied with what we had so far, then it's again a plus for using Scrum... It saves the pocket as well as we don't have to pay for dessert and coffee. It's not a set meal with a set cost.

If I ordered a one-pot main meal, without appetizer and dessert, then the value of the waiter coming over and telling me that the cook has chopped the onions and in 20 minutes he comes again and tells me that the carrots have gone in, then that becomes less valuable to me. It doesn't reduce my hunger as a nice appetizer does. I will probably annoyed with him and only think that I only want to see that guy again with a full plate of food!

If the project is like the one-pot main meal, then (IMHO) it's not a good candidate for Scum, esp. when you're fighting for full scrum transition. Appetizer, Main, Dessert, Coffee is the way to go.

Bon Appetit :)

Nicko, thanks for the additional comments. Maybe I'll have to go for a heavy full-course meal and a game of chess all in one sitting! :)

Sounds like a plan to me :)

Good luck and keep us posted!

> ...and hear what authority I would be empowered with in my role to make it happen

That is a potential trap, because it is easy for them to say "we give you all authority". Then you find that you are not in a position to make anything happen. What they've done is to shift their organization's transformational risk onto you. It's an old trick, very often used by middle managers who want to walk away from the problem.

What you need to figure out is how the organization intends to provide sponsorship for adopting Scrum:

- How are they going to work with Scrum Masters to overcome these barriers? (Hint: expect quality time from them, not a meaningless and misplaced "authorization") 

Hi Ian,

How would you assess the performance of an Agile Coach in the transformation of a company?  How would differ between a poor coach and the organisation's reluctance to change/inability to change?

You can take a leaf from the book of auditors. They don't always look for a particular process or way of working to be followed. What they may look for is evidence that an organization has a process at all, and that controls are in place which indicate how successful that process is being implemented even if it is just in its own terms. This may sound easy enough, but in practice it is enormously difficult for many companies.

Similarly, a good agile coach ought to have a framework for guiding a client through the process of transformation. There ought to be KPIs or other such empirical controls which indicate how well things are going, such as transparency over "Done", dependencies and deficits for release, and any technical debt being accrued. Whether the organization, including its executive function, actually engages properly with that coach and the framework is a different matter. A good coach will be able to account for progress and conduct agile health checks and explain how the gaps ought to be closed.

Understood, thanks!