DON'T MESS WITH SCRUM

 DON’T MESS WITH SCRUM

Scrum is simple, but that simplicity means that each of its elements is essential.  The values, accountabilities, artifacts and events are all part of the framework for a reason.  Teams that mess with the framework are messing with Scrum.  Teams that make changes to the elements limit Scrum's effectiveness and aren't really using Scrum.

Below are some of the things in the Scrum framework teams shouldn't mess with but often do. 

Timeboxes 

Each of the Scrum events has a timebox, and that timebox is important.  For example, the Daily Scrum has a 15-minute timebox, which means this event should never exceed that time.  The Scrum Master’s responsibility is to ensure that team members understand the importance of honouring the timebox. 


TIMEBOXES FOR THE 5 SCRUM EVENTS

EVENT

TIMEBOX

SPRINT

1 Month or less

SPRINT PLANNING

8 Hours. 4 Hours for a 2-week Sprint

DAILY SCRUM

15 minutes

SPRINT REVIEW

4 hours

SPRINT RETROSPECTIVE

3 hours

 

The table above provides an overview of the timebox for each of the 5 Scrum events.  I confess that when I was a new Scrum Master for a small, co-located team, I frequently allowed the Daily Scrum to run into an hour-long debate.  It didn’t take long for people to find reasons to be out of the room for this debacle or to tune out the discussion.  As a result, we lost our focus and rarely adapted the Sprint Backlog based on the latest information.  The team struggled to deliver a Done Increment each Sprint.  

Don’t mess with the timeboxes.  The purpose of the Daily Scrum is to quickly inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary by adjusting the upcoming planned work.  Those who need further clarification and discussion - for example, to problem solve any blockers identified - should do so AFTER the Daily Scrum.  Those discussions might be important, but it’s likely not necessary for the entire team to participate.  By limiting the Daily Scrum to 15 minutes, the team increases efficiency and limits waste. 

Remember that Daily Scrum is not the team’s only opportunity to collaborate. The team should continually collaborate as needed throughout the Sprint.

 

Accountabilities 

The three accountabilities in Scrum are the Scrum Master, Product Owner and Developers.  Clarity around each of these accountabilities is critical for a high-performing team.  It’s very easy for the Product Owner to start encroaching upon the Developers’ responsibilities or for the Developers to begin to overstep into the Product Owner’s responsibilities. 

For example, Developers on a Scrum Team are accountable for the Sprint Backlog.  This means that Developers decide which Product Backlog items (PBIs) to pull into each Sprint.  Sometimes, however, the Product Owner may demand that the team pull more PBIs than the team is comfortable with into the Sprint.  Imagine a situation where the Product Owner has created and communicated a forecast that calls for completing certain PBIs by a specific date.  If the team underperforms in one Sprint, the Product Owner may demand that the team pull MORE work into a subsequent Sprint to make up the time.  

While a certain amount of push and pull is healthy (meaning that the Product Owner can and should ask for more), ultimately, the Developers own the Sprint Backlog and are accountable for determining which work to pull into the Sprint.  If the Developers were to pull more work into the Sprint than they could reasonably expect to complete, it might impact their ability to deliver a Done increment that meets the Sprint Goal.  Remember that a forecast is just an estimate - not a promise.  Rather than risk the team’s ability to deliver a Done, valuable increment, the Product Owner might do better to update the forecast based on the latest information.

 


Scrum Values

 

 

 

 

 

 

 

 

 

The five Scrum values are commitment, focus, openness, respect, and courage.  These values are not just window dressing but an essential part of the Scrum framework.  As the 2020 Scrum guide puts it, “When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.”  

Scrum Teams that do not practice these values limit their ability to inspect and adapt.  For example, all Scrum Team members need to be open to feedback at the Sprint Retrospective.  The Developers might share input with the Product Owner about the clarity of the PBIs.  The Product Owner should be open to that feedback and listen carefully to the Developers for how to improve PBI clarity and simplicity.  

If your team struggles to live the values, discuss it at your next Sprint Retrospective.  One way to do this is to place the five Scrum values on a shared whiteboard.  Then, ask the Scrum Team to brainstorm how to better embody these values in their work or interactions with the parent organization or customer.  Next, vote on one or two actionable improvements to implement as soon as possible.  


Purpose of each Event



Each event in Scrum has a clearly defined purpose, and each event builds upon the success of the previous one.  It’s easy to confuse the purpose of each of the events.  For example, the purpose of the Sprint Planning meeting is to lay out the work of the Sprint.  This means that teams define a Sprint Goal, select which PBIs they aim to complete, and develop a plan for how to deliver them.  The plan for delivering the selected PBIs is discussed in the Sprint Planning event, not during Product Backlog refinement.  Many teams falsely believe that they should task out or fully plan how to deliver each Product Backlog item during Product Backlog refinement, but that is not the case.  How a team delivers a PBI might change based on which other PBIs it selected for the Sprint.  

Likewise, the purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. This is not a status meeting where the Developers update the Product Owner.  Instead, it is a working session for the Developers.

The table below provides a quick overview of the purpose of each of the five events in Scrum.

EVENT

PURPOSE

SPRINT

Deliver a Done, usable increment that meets the Sprint Goal

SPRINT PLANNING

Identify the work to be performed in the upcoming Sprint. This information is captured in the Sprint Backlog which contains the Sprint Goals, selected PBI’s and the plan to delivering them

DAILY SCRUM

Inspect progress towards the Sprint Goal and adapt the Sprint goal as necessary. This increases the likelihood of delivering a done, usable increment that meets the Sprint Goal by the end of the Sprint

SPRINT REVIEW

Inspect the outcome of the Sprint and determine future adaptations

SPRINT RETROSPECTIVE

Plan ways to increase quality and effectiveness

The Scrum Team inspects how the last Sprint went regarding individuals, interactions, processes, tools and their Definition of Done

 

Don’t mess with the events.  Each Scrum event has a specific purpose, and each builds upon the previous event.  Work with your Scrum Master to ensure that your team uses the events as designed to maximize their effectiveness.

 

Conclusion

It is Scrum’s simplicity that makes it so powerful.  Rather than containing a set of work instructions, Scrum is a framework.  That’s why it’s so well suited to complex environments, where less is known than known.  The Scrum Master is accountable for helping team members and the parent organization understand the practices that are part of the Scrum framework and those that are complementary. The simplicity of Scrum means that teams can adopt the complementary practices that work for their specific environment.  However, teams should never mess with the framework itself.  


Best wishes


 

Comments

Post a Comment

Popular

Application of Scrum Values

The essence of Scrum are the 5 values. A Scrum-Agile project will not be successful unless these values are demonstrated in every event, while preparing every artefact and while performing any role. In fact, these values can be demonstrated in any environment to reap benefits. Here are 10 practical instances for each Scrum value that any team can demonstrate: COMMITMENT Team members dedicate themselves to achieving the team's goals and doing their best work. They commit to the sprint goals and support each other in meeting those commitments. Team commits to delivering specific user stories in the sprint backlog, even when facing technical challenges or scope creep requests from stakeholders. Team members commit to rotating on-call duties to ensure continuous support for critical production systems across different time zones. When a legacy system needs modernization, team members commit to learning new frameworks or cloud technologies requ...
Read more

AGILE Mindset

Do your project teams have an AGILE Mindset? Delivering projects using AGILE as a methodology is no longer 'one' of the options. It is the 'only' option especially for Organizations engaged in IT services, Product & Mobile App development. For that matter, even Organizations in other sectors like manufacturing, Infrastructure and even Consulting are considering delivering some of their projects in an AGILE way. Many Organizations who have implemented AGILE as a methodology have fallen back to other traditional methods or are struggling to make it a standard practice. Having seen a number of AGILE projects from the inside and outside, I have a few thoughts on the common mistakes made by Organizations and project teams when delivering projects the AGILE way. If you are considering going the AGILE way or have encountered challenges while implementing the AGILE way, I have a few probing questions for you. The answers to these questions may hold the key for a successfu...
Read more

Science of Influence

One of the traits that Project Managers or any Leader needs to develop is the ability to influence. Every project ecosystem consists of Stakeholders, internal and external. These include your own team members. The ability of a Project Manager to influence these Stakeholders will ensure that the project is in control. Dr. Robert Cialdini has developed 7 principles of influence which can be used by Leaders to influence others. 1.  Reciprocity :  When you do people a favour, they tend to respond in a manner you want them to. However, there are some points to note. - I t’s not about what is given, but HOW AND WHEN IT IS GIVEN . Be the first to give the favour. - Let it be personalized and unexpected. Tell them ‘ I am doing this only for you ’. Suppose, you have done a favour to a person and he/she says ‘Thank you’. What is your response? Many of us say, ‘Its okay’, ‘It was my duty’ etc. Some rare person may say ‘Now you also owe me a favour’.  Instead use this principle Respo...
Read more