InfoQ

News

Challenges in Adopting Scrum

Posted by Vikas Hazrati on Dec 12, 2008

Community
Agile
Topics
Adopting Agile
Tags
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.

  • This article is part of a featured topic series on Scrum

No comments

Watch Thread Reply

Educational Content

Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development

Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).

Are You a Software Architect?

The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?

Agile – A Way of Life and Pragmatic Use of Authority

The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.

Getting Started with Grails, Second Edition

"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?

Using ITIL V3 as a Foundation for SOA Governance

Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.

Adrian Colyer on AspectJ, tc Server and dm Server

SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.

Adam Wiggins on Heroku

Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.

SOA as an Architectural Pattern: Best Practices in Software Architecture

For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.