Challenges in Adopting Scrum

Introducing a new software development methodology has its own set of challenges which might range from ‘reluctance to change’ to ‘faulty adoption techniques’ thus resulting in a failure. In a series of articles on Agile Journal, Cesário Ramos and Eelco Gravendeel talk about the challenges that they experienced while working with Scrum and their observations, when they introduced Scrum at various organizations. The authors, suggested that the knowledge of these challenges and a strategy to overcome them would make the adoption process easier for organizations planning to adopt Scrum.

They mentioned the top challenges with possible solutions as,

1. No organizational learning – This happens when feedback from retrospectives is lost and not incorporated for improving the process. Ideally, all feedback should result in action items. These action items should be picked up by the team if they impact the project and by the meta-scrum master if they impact the organization.
2. Lack of environment of trust – Often, such an environment results in people hiding their mistakes, not sharing their opinion and delaying the decision making process. The solution is to build and environment which thrives on positive feedback and transparency. This can be achieved by extensive use of information radiators which initiate communication and transparency.
3. Using Scrum as a fix, without knowing the problem – A new methodology should not be adopted because of the hype surrounding it. An organization should try to define their expectations and measurement criteria. Answering questions like ‘Where does the current process hurt?’, ‘What caused the hurting?’, and ‘What would we be able to do when the hurting has stopped?’ would help define objective expectations and measurement criteria.
4. Defective product owners – These product owners either do not have the knowledge or the mandate to perform effectively. In the worst case they might not have both. Product owners with clipped wings lack the ability to make fast decisions which eventually hurts velocity of the team.
5. Doing agile strictly and ‘only’ by the book - Scrum is a simple process with a complex behavior. What works for one organization might not work for another. Going ‘only’ by the book would not help in all scenarios. Scrum needs to be customized as per the organizational needs once there is a thorough understanding of the methodology.
6. Not preparing the organization around a Scrum project – A team embracing Scrum cannot work in isolation. It needs to interact with various other teams to be successful. A close coordination with sales and marketing is required for product ownership, with testing and design teams for involving their people as a part of the team and with top management to get help with the new way of project tracking and reporting. Setting a foundation around the new methodology and involving all departments makes the adoption quick and easy.
7. Lack of a Meta-Scrum master – Not all impediments can be resolved by the Scrum master who is operating at a project level. There are impediments highlighted by Scrum which need to be addressed across projects, at an organization level. This is where senior management needs to play the role of a meta-scrum master and address the impediments in visible terms of delivery time and ROI.
8. Scrum as an excuse for cowboy behavior –  Such behavior implies throwing away existing good practices in the name of following a new methodology. Scrum would help surface the inefficiencies and problems quickly. The key is not to pre-optimize but to wait for the problems to surface and then tackle them.
9. Thinking Agile is easy – The philosophy behind Agile is simple but practicing it difficult. The best way is to have an Agile coach assist the team. Getting people trained at various levels by having an agile champion in the organization, evangelizing agile, doing workshops and coaching Scrum Masters is a key factor to Scrum adoption.

Cesario and Eelco suggested that people in an organization would have a lot of questions regarding a new methodology. These need to be addressed properly to ensure that the adoption is successful.

According to them,

People end up with lots of questions like: How are you going to handle planning and estimating? How do we forecast? How do you manage agile contracting? Can't we fix the deadline? What about architecture, does it just emerge all by itself? How can we possible do requirements, development and testing at the same time? Don't be silly!! How do I measure it and how do you prioritize requirements by value? And then there is this Plan-Do-Inspect-Adapt thing, how should we do that? Isn't doing Agile more expensive?

Failing to address such questions will result into people slipping back to their usual way of working when the pressure rises. The first thing we see is a drop in quality and testing effort. Also the command and control way of managing steps right back in. As a result moral drops, velocity drops even more, the project gets canceled and the Scrum adoption gets more complicated.

Hence, adopting a new methodology is prone to multiple challenges. The key, is to focus on the bigger picture and the benefits which need to be realized. This can be done by creating an organizational culture of constant learning and adapting.