Five reasons why you might not really doing scrum after all

Scrum is the best known and most widely adopted agile approach. When a manager in a large organisation says to me that their team(s) are doing scrum, my suspicion is that they don’t really know what scrum is because, well, it’s really hard for most large organisations to do scrum.

The formal definition for what scrum is is the scrum guide. The key sticking point in the guide are:

End-2-end cycle time of less than 1 month “The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.” This means that if marketing decides that the product is good enough at the end of the sprint, it can go out to customers without negligable further technical work. Useabledoesn’t mean a prototype or a product that needs further testing in some way (regression, security, …) since this would mean that the output of the sprint wasn’t useable in itself. Scrum is in stark contrast to SAFe which suggests that one can have hardening sprints (HIP sprints) to sort these kind of things out before every release. Scrum effectively says; be ready to do a release at the end of every sprint. So, can your scrum team(s) really go from prioritising a feature to a potential product release in a month or less?

No dependencies outside of team“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” To deliver the product, there are no dependencies outside the team. Everybody needed is in the team; infrastructure, architecture, documentation, … Note that the scrum guide also says: “Having more than nine members requires too much coordination.” so you can’t make the team very big to solve this problem. Large organisations with lots of departments responsible for different parts of the product development process struggle with this.

Fully empowered product owner “The Product Owner is one person, not a committee.” Scrum is very clear – the one person who is the product owner has full authority on product prioritisation decisions. Most companies have competing departments who all want their say in how the product should be and struggle to devolve responsibility to one person who is so low in the hierarchy that he/she has time to fulfil the product owner role.

Team members all have the title “developer” “[Development team is] self-organizing. Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;” A key barrier to effective self-organisation is typically entrenched job roles. “I’m a tester,” or “I’m a business analyst.” Human Resources(HR) departments in large companies love this as somebody can be a Junior Tester and somebody else cane a Senior Tester which maps to HR’s job and pay scales. Some people like this (typically those with “senior” in their title) because it highlights their skills, makes them feel special and makes it easier to justify why they should be paid more than the other guys. It can also affect reporting lines (e.g. all the “testers” need to report into the testing manager). It’s hard to find people who will actively support the notion that we are all “developers.”

Scrum Master as facilitator“The Scrum Master is a servant-leader for the Scrum Team” Most companies struggle with both the notion of servant-leadership and the facilitating/coaching nature of the Scrum Master role. Sometimes, Scrum Masters are seen as project managers and accountable for team success which is really not what is intended. Other times they are simply ignored. Scrum defines them as being responsible for ensuring scrum is understood and enacted – they are process coaches – making sure the scrum process framework is being adopted. They are not part of the product development process itself but a facilitator of how that process runs and adapts itself in the light of new learnings or changing demand.