© 2012 William Patrick Swisher
The transformation from Waterfall to Scrum will be both challenging to individuals and disruptive to the organization as whole. There are a number of factors that will improve the chances of a successful switch in methodology:
(1) Steadfast Commitment – Once the decision has been made to transform the organization from Waterfall to Scrum, there must be steadfast commitment by senior leadership that the switch will occur and there’s no going back. This is primarily because there will be challenges, in some cases significant, and any hesitancy or lack of conviction by the leadership will invite resistance and a prolonged period in between methodologies.
(2) Professional Scrum Training – While this may be expensive, it’s well worth having a certified Scrum trainer come onsite and teach the basics of Scrum and the concepts of the various rituals (Sprint Planning meeting, Daily Standup meeting, Sprint Review meeting, Sprint Retrospective meeting, et cetera). Not only will it synchronize everyone in terms of education and terminology, it creates a sense of transition for those involved who will soon be starting to use Scrum as part of their standard development process.
(3) Experienced Scrum Master – Taking a two day class may earn someone the title of Certified Scrum Master but an experienced Scrum Master will be essential to an organization’s switch to Scrum. The basic concepts and rituals of Scrum are very simple and easily learned and yet what’s missing from the classroom experience is the ability to identify and correct disfunction and the ever present threat of sliding back to Waterfall patterns. Additionally, an experienced Scrum Master will recognize when they should mentor, facilitate, or simply fade into the background and allow the Developers to self-organize around delivering business value.
(4) Having Lightweight Processes & Artifacts Ready – As was mentioned previously, Scrum concepts and rituals are simple. For an organization making the switch to Scrum, it will involve a group of people each with their own experience, opinions, and expectations. If the group was asked to create the processes and mechanics from scratch it could be a long time before they were ready and even then, the methods might be far more complex than needed. To improve the chances of a successful switch, a set of lightweight processes with associated artifacts (Product Backlog, Sprint Backlog) should be created and given to the team to use. Then, as the people use the basic processes and learn, they can modify the processes to suite the needs of the organization.
(5) Open and Supportive Culture – Every implementation of the Scrum methodology will have variations unique to the nature of the organization and their projects. When the first Scrum Team starts operating under the new methodology, they will encounter many challenges, not only in how the team itself operates but across the organization. Senior leadership should make it clear that “bumps in the road” are expected but that teams will work through them, continually making improvements. Setting this expectation fosters a sense that experimentation where the possibility of failure is acceptable so long as causes are identified and issues resolved.
(6) Starting with a Priority Project – When deciding which product will be the first developed under Scrum, it’s natural to select one that if it failed, the damage would be minimal. When switching development methodologies, which will be disruptive to the entire organization, not just Software Engineering, a high-visibility, high-importance product should be used. This is because when there are challenges, there will be sufficient motivation across the board to address them and keep momentum going. If a irrelevant product was selected, the switch to Scrum could be blamed for any failure and unlikely to be attempted again.
(7) Good Scrum Team – The first Scrum Team should have a purposely selected mix of people. The best combination includes senior Coders/Testers who are pragmatic and open to trying new ideas and more junior people who can be mentored and are willing to adapt. The Scrum Master should partner up with those who can mentor to help guide the entire group. Avoid having people with a tendency towards extreme viewpoints in the first teams. Early success with the first team will influence public opinion and over time, even the most skeptical will get on board.
(8) Early Success – Every effort must be made to ensure the first Scrum Team and their first product under Scrum are successful. This will require much work not only from the Developers, Product Owner, and Scrum Master when figuring out how to operate under the new methodology but all their management will need to be involved to clear obstacles, make decisions, and be supportive through the challenges. Once success is achieved in terms of delivering quality business value, others will want to join the winning team.
As mentioned before, the switch from Waterfall to Scrum will be disruptive on many levels but if these factors exist in an organization, the better the chances for a speedy and successful transformation.