Adopt with Care

One CSM's 8-step approach to sucessfully transitioning to Scrum

26 August 2010

Prashant Pund
AgileSoft Methodologies

Do any of these statements sound familiar?

“Sure, we're using agile methods. I mean, we aren't entirely sure, but we think we're agile.”
“Well, the team conducts daily scrums, so they must be agile.”
“I have been tense since this guy introduced Scrum. Every morning I have to give a status report. It’s really taxing.”
“This fellow read something on the Internet about Scrum and said, let’s start Scrum tomorrow. I'm not worried. It's just another fad to ride out.”
“I heard there is a change in our process. The Process Group person is here to explain the new process, something called Scrum.”

If so, your organization likely is suffering from Scrum Mis-adoption Syndrome (SMS). SMS causes disinterest, failures to deliver, and profound distrust. The best way to treat it? Prevent it from happening in the first place.

A successful Scrum adoption requires a profound transformation of the organization. This change will be felt at the team level, yes, but will ultimately affect all layers of the organization. This then begs the question, How can I, being at the level of PM/Lead, bring in such a transformation? Shouldn’t it come from the top? The answer is both Yes and No. Yes, because indeed the transformation needs to have buy-in and support from the top. No, because a top-down approach is not sufficient. As Mike Cohn puts it, “Change is not top-bottom or (emphasis added) bottom-up; it’s both." In view of this, here is the approach I suggest to those who are trying to transition to an agile methodology such as Scrum.

  1. Analysis of the existing methodology
  2. Decision to move to Agile
  3. Buy-in from the Sr. Management
  4. Training session for Sr. and Middle Management
  5. Choosing a pilot project
  6. Choosing a team
  7. Training sessions for the team
  8. Mentoring during implementation

Analysis of the Existing Methodology

It is important that the need to change is felt both at the top and at the bottom as well. To help people understand the need to change, try asking these questions:

  • What is the definition of success for the project and in the organization? Please note that even over-budget and over-schedule projects can be treated as “successful” if they have brought value to the customer.
  • Are we happy about the ROI/value being provided to our customer?
  • Are we happy about the productivity of the people?
  • Do we view changes by customer as disturbances to development process?

Many similar questions can be asked to help initiate a discussion around the need to change.

Decision to Move to Agile

Change is hard. It needs to be understood that there will be a cost for the benefit. Fortunately, here the cost is preparing minds for receptiveness to learning and adaptation. Consider telling people that we are going to try a new approach. Do not name it; just call it a new approach. An important consideration is the possible participation of the customer in the development. Return on Investment (ROI) is the key metric for convincing customers that it is worth their time to get involved.

Buy-in from Senior Management

Whether the idea has come from a developer or a PM or Senior Delivery Manager, before you can change, you'll need buy in from senior management that it's worthwhile to at least try to change. You'll have to communicate that in order to be effective, the agile teams must be able to focus, and will have to educate management into what that means for them. You'll also have to let them know teams will structure if they feel someone is constantly looking over their shoulders.

Training Sessions for Senior and Middle Management

Educating senior management is one of the best ways to help teams achieve their goals. Formal training sessions are the most efficient and effective ways to accomplish this. In addition, classroom training sessions, if conducted by experienced professionals, can act as good information radiators. The managers can understand the methodology in detail, ask questions, and get clarity on how it is to be done and how it should not be done. The training session should include exercises and experience sharing by the trainer so that attendees leave with a clear understanding of the concepts.

Choosing a Pilot Project

Select a project to be called as a pilot. Please note this is not a trial or “allowed-to-fail” project. The new approach needs to be applied with proper observation set-up. This project is at large Sprint Zero for the series of projects to come (broad analogy). The objective is to understand, apply the new approach, and learn for further adaptation.

Choosing a Team

The team members will make the process a success. For the pilot project, be choosy in selecting the team members. The members should be open-minded, extroverted, pro-active, experts and assertive. People with big ego are strict no-no.


Training the Team

The training session for the team will have 2 goals.

  1. Mental preparation and understanding of the approach
  2. Understanding what technical activities need to be done differently. The team needs to know refactoring, use of design patterns, continuous integration. In short, they need to understand agile engineering practices.

Mentoring the Team

Involvement of an external expert is always beneficial. The consultant will be involved in the sprint on daily basis. Mentoring should support all the roles. The level of mentoring support should decrease as the number of sprints increases. The role of the consultant is to guide the team, not manage the project. The consultant should pull out after the team attains a certain level of agile maturity.

The approach suggested here is at broad level and leaves many details for you to arrange. After all, one needs to be agile enough to respond to change, even those that have to do with the agile adoption itself.

Keep Scrum’s good name! Do your part to eradicate Scrum Mis-adoption Syndrome (SMS) from your organization.




Article Rating

Current rating: 0 (0 ratings)

Comments

Francesc Oliva Seluy, CSM, 9/8/2010 9:06:47 AM
Dear Phrasant,

First of all, I'm sorry if my English is not very good. I'm from Barcelona (Spain) so English is not my mother tongue. I will do my best to explain clearly what I want to say.

At the moment I am facing the challenge of implemnting Scrum in a company with a particular structure.

Managment level is very open minded and, in my opinion, understand the need of changing to achieve the goals that Scrum can bring.
The Teams are also expecting Scrum to arrive so the think it can be very useful and a benefit bringer for them.

The problem is the company structure. The Teams and the persons designed to be Scrum Masters are from an external companies working at my customer's headquarters. Because of that, the Scrum Masters can't do all they have to. Their knowledge of the company's targets, needs,ROI, etc is very limitated. To help them, there's a role named "Consultant" who is supposed to help them in order to cover this lacks.

I think I've heard or read somewhere that Scrum Master's tasks can be shared by more than one person but I'm not sure.

Is that possible? If so, the company should decide which Scrum Master's task develops each person, am I right?

Another possibility is turn that Consultants into Scrum Masters but they have many other things to do and can't be full-time Scrum Masters.

My idea is to train those Scrum Masters in order to give them all the skills they need and make them work for my customer, so they will not be external resources anymore and Consultants would finally focus on other tasks.

What do you think about it? Any other suggestion?

Thank you very much.
Prashant Pund, CSM, 9/13/2010 3:43:13 PM
Hi Francesc,
Sorry for the delayed response. Well, in your case, it seems that the development work is outsourced to a company and the Scrum Masters with the Teams belong to it. Now, as I see it, your organization is the Customer for this development company. In turn, you have your customer of which the ROI is important to you as a service provider. I feel the role of your "Consultant" can be more of a Product Owner. Of course, the Scrum Masters and the Teams need to undergo some formal training to make them understand their roles, as you have rightly said.
Francesc Oliva Seluy, CSM, 9/28/2010 10:03:13 AM
Hi Prashant,
Don't worry for your delay as my response is delayed too. About what you said, our first idea was also turn the Consultants into PO but there is one problem with that.
If a PO receives different new projects from the Customer (different Stakeholders) and the priority is set by the PO, maybe this will affect the Customer's ROI if the PO doesn't know very clearly the Customer's targets.
The question is:
Why not give to the customer the role of a PO having a unique point of communication between the Customer (stakeholders) and the SM by only one PO. Being a Customer's employee, the PO will surely give the right priority to the projects and User Stories according to the Customers targets to achieve the best ROI possible.
I think this is a good idea and we are working on it but i don't know if the Customer would like to do it.
What do you think about it?

Thank you.

You must Login or Signup to comment.