Stay Connected:

TwitterLinkedin

How Prescriptive is Scrum?

    
 About
 Contributions   
 Follow
 Send Message
 This is a question asked frequently, especially by larger organizations that are struggling with scaling. On one hand, they want to keep the inherent flexibility and empowerment provided by Scrum – they have seen the great results that an engaged team can produce. At the same time, they need to keep consistency between the teams, create a common structure and scale a portfolio of projects. When team members want to make changes, how much leeway are they granted?

The short answer is ‘it depends’. And I don’t mean to punt, but it truly does depend on the nature of the proposed change. Obviously, I am biased here, but this is an excellent example of where an experienced ScrumMaster is extremely valuable. 

As the ‘owner of the process’, an experienced ScrumMaster will know where there is some give and where one has to be rather strict. (This will depend on the maturity of the team – no universal rule here).

Make no mistake: Agile will lose a lot of its power and effectiveness if terms such as ‘team empowerment’ and ‘self organizing teams’ become perceived as merely management lip service or fancy buzzwords. On the other hand, if we go to the other extreme and let teams implement whatever flavor of Agile they want, this is sure to kill scalability, generate zero visibility and essentially unusable metrics, which is crucial to be able to continually gain management support, especially in the crucial pilot phase of an enterprise implementation.

Scrum is anarchy?

So what to do? My answer would be that the team has to ‘earn’ the right to modify elements of the process. This means that at the outset, we aim to follow the process as closely as possible. However, as the team matures and the ScrumMaster is able to assess where additional gains can be made from making tactical changes to the process, this is an option that should be on the table. 

Don’t get me wrong – the core fundamentals of Scrum need to be there – there should always be a daily Scrum, a Sprint Review, a Retrospective, etc. Certain elements are essential to a proven framework that needs to be there in order for this to work on a larger scale. However, if the team truly feels that they can be more productive having a 3-week Sprint rather than a 2-week Sprint, I don’t see a reason why that should not be an option to consider.

What makes Agile so compelling is that it is steeped in common sense.

Your implementation should reflect this spirit – It does not make sense to on one hand preach ‘empowerment’ and rollout a process that does not leave any room for independent thought. Similarly, providing teams with responsibility to make decisions does not mean they don’t have a boundary framework to work within.

How is Scrum implemented in your organization? Does each team have their own variations or is there a strict standard that is followed universally across all teams?

© 2024 Agile Development