Adopt Scrum By Avoiding The Scrum / Agile Misadoption Syndrome
Do any of these statements sound familiar? a) “Sure, we’re using agile methods. I mean, we aren’t entirely sure, but we think we’re agile.” b) “Well, the team conducts daily Scrums, so they must be agile.” c) “I have been tense since this guy introduced Scrum. Every morning I have to give a status report. It’s really taxing.” d) “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.” e) “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 could be suffering from the 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 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.
- Analysis of the existing methodology
- Decision to move to Agile.
- Buy-in from the Sr. Management.
- Training session for Sr. and Middle Management.
- Choosing a pilot project.
- Choosing a team.
- Training sessions for the team.
- 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.
- Mental preparation and understanding of the approach
- 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.
*Republished from The Scrum Alliance
Related:
- IndicThreads Conference On Mobile Application Development (August 2011)
- Quick Introduction To Agile Software Development
