Top 9 Challenges of Adopting Scrum: Product Owners, By the Book, and Organizational Issues

Part 2 of 3

preparing the organization around a Scrum project
When introducing Scrum into an organization you cannot look at one department or one team and discard the rest of the organization. It doesn't matter the team at hand is enthusiastic; you will need to cooperate with other parts of the organization to really make a difference. You will need to cooperate with sales and marketing to handle product ownership, test, design and maintenance departments to involve their people in the team and management to help them in this new way of tracking and managing projects.

Lack of understanding of how Scrum provides benefits can get you in lots of trouble. New insights in requirements may be interpreted as lack of upfront requirement engineering. Re-architecting may be interpreted as improper architecture or incapable architect and so on. In case the surroundings of the project do not understand Scrum and how it can benefit them and the project you'll encounter lots of resistance.

Overall you will have to make sure people get this Scrum thing and how it concentrates more on working software than on proving how far the project is along by showing lots of plans and other documentation. They will need to get used to the fact that if the date and the budget is fixed, the functionality must be variable.

When introducing Scrum you quickly should start working on some success enablers. You need to have an Agile foundation setup. Scrum does not give you a capable product owner, customer engagement, teams practicing suitable engineering practices or good requirements management. These should already be there.

It would be best to get active support and commitment not only from company level management but also from various department managers and team leaders you're project or department needs to interact with. The best way to get this support is by showing them the advantages of introducing Scrum will bring not only for your team or department, but also for theirs. In most cases you have to tell them several times, or better yet; show them. Showing people some quick improvements should gain enough trust to be able to do the next steps.

 In time, failing to prepare the organization around the project will result in local optimization at the most. Even worse, it will probably result in another project that fails and Scrum will take the blame for it.

In this second part we discussed some big challenges that have to do with various aspects of adopting Scrum. A capable product owner team is fundamental to achieving success but not enough on its own. If you want to achieve global improvement you'll need to align with other departments. In doing so you'll have to learn and really understand the principles behind agile and Scrum so you can inspect and adapt to what best suites your specific situation.

Click here for part 3.

About the Authors

Eelco Gravendeel is an consultant for Xebia with the unit Xebia Agile Consulting. Eelco has started out his career as a software developer. Later moved on to become a team leader and then became the manager of a Software Development department. During this period he implemented Scrum the first time. Having tasted the Agile fruits he then moved on to become a Consultant and Project Manager. In this position he coaches departments and organizations to implement Scrum and Agile practices or manages Agile projects.

Cesário Ramos is a Senior Consultant in Agile methodologies and Enterprise Java at Xebia. Since the late nineties he has worked in various roles ranging from developer to agile coach. He

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.