Dirty Details of Scrum

As a Certified Scrum Master (SCM), I frequently encounter real-world difficulties when implementing the Scrum framework. Although we all want the benefits of Scrum such as improved transparency and reduction of useless paperwork, most organizations are not ready to trust the Scrum process. Most executives still cling to the false belief that an estimate from IT is a guaranteed invoice for the cost of a project. (After decades of software development projects, we all know that an estimated cost to develop software is a best-guess, yet most people still cling to the false hope that somehow the next project will be different.)

Here are the dirty details that Scrum masters commonly encounter when implementing Scrum.

1. People who confidently talk about about Agile and Scrum, and sell executives on the benefits of Agile, without actually knowing how to implement an Agile project. These people cause harm when an executive sponsor gets the impression that Scrum is both simple and easy. The reality is that Scrum is simple, but not easy.

2. Traditional project managers who follow the "Command and Conquer" management traditions. Traditional project managers struggle to let go, and let the teams be empowered and self-organize. I find that most of these people need to be moved out of the way, becuase they just cannot adjust to the role of Scrum master, which requires a facilitative approach.

3. Financial executives want the whole picture and total cost of the project. Sometimes they want it tabulated, analyzed and broken out by an infinite number of pivot tables before they will move off "Go". This way of thinking doesn't work for Scrum. You have to help these people to understand the Scrum way of thinking and team dynamics.

4. No common agreement on the Scrum roles. In an organization, you might find many people throwing around "Agile" terms such as "Product Owner", "Backlog" and my favorite, the magical "Sprint". Don't assume that everyone has the same understanding of these terms, or has a clue on how to implement them into a cohesive working project team. You need to challenge these terms and ask for clarification and exact definitions.

5. IT professionals who expect a Scrum Master to be the dreaded, old-school "Project Manager" who carries around a clipboard and checks off boxes as tasks are driven to completion. I often encounter IT Business Analysts and Developers professionals who are so used to ineffective Project Managers that they struggle to adapt to Scrum Masters who faciliate their efforts instead of simply challenging them to work harder, smarter and faster.

There you have it. Scrum works. It is simple, not easy. However, Scrum does not work in a vacuum and needs IT, Executive Sponsors and Product Owners to make it work, for the collective benefit of delivering the most important value.