Scrumptious

With Scrum being by far the most influential and pervasive framework for delivering Agile projects, I thought it might be interesting to find out why Scrum has been so successful, any challenges it may face when scaling, and how it might evolve in the future.

To investigate these topics further, who better to ask than the co-founder of Scrum itself. Ken Schwaber, who also founded and chairs Scrum.org, graciously accepted my request to answer the following questions.

1. When you first created the Scrum framework, did you believe it could become as widespread as it has?

No, I didn’t. I knew it worked for me at the organizations and on the projects where I used it. I knew waterfall was draining the life out of software development and angering our customers, so I thought I would share it with others. But, as life is very complex, who can ever predict outcomes (empiricism of Scrum).

2. Why do you believe Scrum is the most popular framework for delivering Agile projects?

It is very simple. Every person adds their interpretations, so they can use it in their context and it becomes pretty universally applicable. It is just really, really hard to use; Scrum makes transparent facts that are contrary to human nature’s desire for good things to happen. Scrum sometimes makes really unpleasant things visible. The choice is to figure out what to do to solve the problems, or to “modify” Scrum so the unpleasantness is again hidden.

3. What do you see as the major challenges to scaling Scrum at the enterprise level?

Enterprise cultures are very different from Scrum’s culture. The Scrum Master has to make Scrum work as well as possible, regardless. For instance, a customer demands that something be done by a certain time. Scrum may disclose that is impossible and trade-offs have to be made. The power structure in a hierarchical organization (only tell me good news) often finds that unacceptable. So the customer is caught between desires and possibility.

4. Should the name Scrum Master be changed to Scrum Coach to adhere more to a servant-leader relationship?

I think that is a bad idea.

5. How can non-development projects benefit from Scrum?

Whenever something changes, that is development. When water acidifies, that is the water developing from one state to another. To understand the greatly needed applicability of Scrum, read Tomas Friedman’s book, “Thank You For Being Late.”  Our world is getting more complex, not less. Scrum is needed more, not less. Scrum is a way of dealing with the significant cultural upheaval that we are going through.

6. Where do you see Scrum 5 years from now?

To deal with greater complexity, we may develop infrastructures that describe how to manage risks and better tolerate R&D. Scrum will be right in the middle as meaningful possibilities emerge.

                                                               * * *

I wish to thank Ken Schwaber for his great insights, and Lindsay Velecina at Scrum.org for her assistance during the Q&A process. The world is a little wiser about Scrum as a result.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!


 

We are all familiar with scope creep and how if left unchecked it can consume a project pretty rapidly. Depending at what stage of the project we are in when the scope starts to get out of hand, our risk contingencies and planned responses may be too little too late.

In the Scrum world, a major source of scope creep are the items that find their way into the Sprint Backlog and sometimes bypass the Product Backlog refinement process altogether.

Here are three ways the dreaded creepy scope can make their way into the Sprint Backlog and threaten the stability of the Scrum adoption within an organization:

1. Sprint Hijacker
In most organizations there are some very influential stakeholders or customers that don't mind bypassing protocol to get what they want. In fact, it is partly why they are so successful. These individuals want their feature included in the current Sprint and jumping the queue in order to do that is just collateral damage.

Some team members may even develop a rapport with the Sprint hijacker and let some features in, making it more a case of Stokholm Sydnrome than positive feelings toward the hijacker. In these circumstances, both the Product Owner and the Scrum Master need to step in.

The Product Owner needs to consult with the stakeholder to ensure that any requests for "urgent" features find their way into the Product Backlog, and then refined and prioritized along with all the other items. The Scrum Master must shield the development team from any external distractions which reduce their performance or jeopardize the Sprint Goal. The Sprint Hijacker is one of these external distractions.

2. The Boy who cried Wolf
If the Product Owner is not on his/her game, or they are less than honest, they may create an oversupply of Must Have's that should be Should Have's, Should Have's that should be Could Have's, and Could Have's that should be Won't Have's to enter the Product Backlog.

Incorrect prioritization gives a false impression that some features are more important than they really are. When the Product Owner allows this to happen, the Development Team soon gets wind of the boy who cried wolf and this can cause them to lose trust in the prioritization process and the Product Owner. The Development Team may then compensate by adjusting their estimates, or worse still, treat a feature as anything less than a Must Have.

If this is done enough times, the product becomes a very different beast. The key here is to ensure honesty, integrity and transparency in the Product Backlog refinement and prioritization process.

3. GPDoD
I had to fit an acronym in somewhere. GPDoD is my acronym for Gold Plating the Definition of Done. Oh yes it happens. The Definition of Done (DoD) within a Scrum Team is a "shared understanding of what it means for work to be complete, to ensure transparency". As the project progresses, the DoD can change, become more detailed, and require more steps. It is basically a checklist to ensure that everything the team said would be done, is done, and the feature/increment is potentially shippable.

But that's when everything goes right. It can also go terribly wrong. Most of us know what gold plating is. While this is a term we normally associate with waterfall projects, they can still infect Scrum projects even with a rock-solid DoD.

Gold plating can happen through a number of ways: a relationship with a customer or stakeholder that includes some bells and whistles that are not required, an enthusiastic developer who just wants to increase customer satisfaction, misunderstanding of the customer's requirements, miscommunication with the Product Owner, and the list goes on.

This phenomenon is not only limited to the features we and the customer see. Gold plating can also manifest itself down at the code level where da Vinci developers want to tweak the code beyond what is required to meet the DoD, simply because it is aesthetically pleasing to their idea of good code writing.

                                                                * * *

If you are concerned that the creepy scope may visit your Scrum neighborhood, my advice is to grab a large poster and pin it on the wall with large block letters quoting:

"Done means Done. Not Done and then Some!"


References
Schwaber, K. and Sutherland, J. (2017) The Scrum Guide. Available from: www.scrumguides.org

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!


 

At the heart of every great Agile project that uses Scrum, is the Scrum Team. These are small but competent groups of individuals packed with all the skills and experience necessary to produce valuable products and services.

The Development Team is the nucleus of the Scrum Team; anywhere from 3 to 9 people who are collectively responsible for each feature and increment they produce. Unlike almost any other kind of team we are familiar with, the individuals that make up the Development Team have no title, no rank, and no specialization exclusivity.

Revolving around the Development Team is the Product Owner and Scrum Master. These three entities form the Scrum Team as a whole. It is the expectation of most projects that the Scrum Team will work productively, consistently and harmoniously. However, this is not always the case.

Let's take a look at 3 warning signs that the Scrum Team needs a tune-up, and some questions that may be asked to help identify the cause.

1. Reduced Velocity / Increased Lead Time
   Velocity is the amount of work capacity the team can produce every iteration or Sprint. Lead time is the amount of time it takes for an entire process between two defined points, say from Backlog entry to acceptance by the Product Owner. Both velocity and lead time are separate measurements, but closely related. For example, a reduced velocity is likely to accompany increased lead time. When measuring the team's past performance, a sudden reduction in velocity or increase in lead time should be a cause for concern.
   
   Are there any blockers preventing the team from working at their previous work rate? Does the team have all the tools and knowledge to convert user stories into features? Is the Product Owner giving clear information regarding the items in the Backlog, and prioritizing them in such a way as to optimize the Development Team's work? Is the Scrum Master ensuring that the team is not distracted by external factors, including stakeholder requests?
    
2. Bad Apple
   Sometimes a member of the team doesn't fall into line with Scrum's 5 values, especially regarding commitment, focus and respect. In order for any team to function effectively, all members need to commit to their shared goals, focus on the work at hand, and respect each other throughout the project. When one team member becomes the black sheep of the family, it's time to start examining some possible reasons for the behavior.
   
   Does the team member fully support Scrum? Can the Scrum Master provide any assistance to the team member if the latter does not fully support or understand the Scrum framework with its rules, roles, values, principles, artifacts and events? Did the team member have more authority in their previous role and now finding it difficult to be an equal team member? Is there some kind of conflict between the team member and others within the team? Do they feel appreciated and included at the same level as other team members? Are there any private issues that require attention? Remember stress, fear and depression can be serious conditions that should not be taken lightly. These and many other possible causes need to be investigated before the bad apple infects the rest of the apple tree.
    
3. No Show
   The no show Product Owner or Scrum Master is someone who doesn't show up either physically in person, or via other communication methods such as email or phone call. Sometimes the Development Team need input such as Backlog item clarification from the Product Owner, or obstacles removed by the Scrum Master. These issues can manifest themselves several times a day, and a no-show member of the Scrum Team can delay incremental delivery.
   
   Is the Product Owner and Scrum Master spread too thinly between teams or other responsibilities? Are they committed to the Scrum Team? Did they sign off on the Sprint Goal? Does the Product Owner have true authority over the Product Backlog and is he/she in sync with what the stakeholders need? Is the Scrum Master following Scrum strictly or haphazardly? Is the organization truly adopting Agile/Scrum?

I have only listed 3 signs that a Scrum Team needs close attention, but there are many others. Can you think of any? I would love to hear about your experiences with a Scrum or any Agile team that started to go astray, and was in dire need of a Scrum Mechanic to step in and give the engine a tune up.

References
Schwaber, K. and Sutherland, J. (2017) The Scrum Guide. Available from: www.scrumguides.org
Griffiths, M. (2015) PMI-ACP Exam Prep. RMC Publications, Inc.

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can also be Scrumptious!


 

It is always great to see successful Agile projects come to fruition. When the project is done, team members disband and move on to the next project. Sometimes, before a project has even ended, we lose some members of the team for various reasons such as quitting their job, going on holiday, or being fired for poor performance. So how do we wrap our heads around the fact that some project team members will be pushed out of their roles, even before the project is done, simply because they are doing a fantastic job?

Welcome to the world of the Scrum Master. As an essential member of the Scrum Team, the Scrum Master acts as a servant-leader to the whole team, and coaches the organization in its Scrum adoption. According to the Scrum Guide, they are specifically tasked with:

• coaching the Dev Team to self-organize and be cross-functional
• assisting the Dev Team to create high-value products
• removing the blockers that prevent the Dev Team's progress
• facilitating Scrum events as needed
• influencing organizational change to increase Dev Team's productivity

This doesn't include the myriad of other tasks associated with assisting the Product Owner, and the wider organization. In general, The Scrum Master is there to ensure that the roles, events, artifacts and rules that make Scrum what it is, are followed as strictly as possible. This results in the optimal implementation of Scrum, and raises the likelihood of success.

So when the sprint is running smoothly, or more specifically, when the Development Team follow the rules, understand their role, produce transparent and clear artifacts, and actively participate in all events (within the prescribed time boxes), what is there left for the Scrum Master to do?

Well, not terribly much...within the Team. The very essence of Scrum is a small, high performing, self-organizing, cross functional team that consistently produces valuable products. When the team approaches this pinnacle, the Scrum Master is effectively redundant.

Regardless of whether or not an organization is new to the Agile way of doing things, or has some experience behind them, teams will vary from project to project, department to department, and company to company. One team may be the jewel in the Agile crown for an organization, consistently performing at a high level while adhering to the fundamental values and principles of Scrum. On the other hand, other teams may be lagging behind, slower to adopt Scrum, or not have the optimal dynamics in place between the Development Team, Product Owner, Scrum Master, stakeholders and the wider organization. These teams will need further coaching and facilitation. Also, new Agile projects will come along, with new teams, or new members of existing teams, and the cycle of the Scrum Master will begin all over again.

Outside the team, it is a different ball game. This is where I believe a Scrum Master or Coach is needed no matter how successful or pervasive Agile and Scrum is within the organization. Employees, middle and senior managers, and executives that are not dealing with Agile on a daily basis, sometimes forget that it is still around and they can often fall back into their old ways. The Scrum Master can refresh their memory and assist the organization to keep on track with their Agile initiatives.

In fact, metrics should be put in place to ensure that the organization's Agile maturity extends beyond the Scrum Team to the rest of the organization. Whether this is performed by a Scrum Master or Scrum Coach (sometimes they are the same person depending on the size of the project and organization), one thing is for sure: letting go of the Scrum experts could be a case of cutting one's nose off to spite one's face.

So hopefully we might hear a different response to the Scrum Master's fantastic work: "Great job. Now you're re-hired!"

References
Schwaber, K. and Sutherland, J. (2017) The Scrum Guide. Available from: www.scrumguides.org
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!