Get certified - Transform your world of work today

Close

Scrum Is Simple but Not Easy

6 October 2014

Scott Ocamb
Creative Business Solutions


At the Global Scrum Gathering® New Orleans 2014 conference, a T-shirt was available with the phrase, "Scrum Is Simple but Not Easy." I often encounter teams who follow the rituals and processes of Scrum to some degree but do not really understand why they are doing it, nor grasp the power Scrum affords in the development of a product.

The purpose of this article is to review why we use Scrum and why it is important to stick to its tenets. We will start with an overview of Scrum.

Scrum in a nutshell

Scrum is a process best suited to the delivery of a software product. The person who knows this product best is the product owner. The product owner is responsible for the features that comprise the product. These features are known as user stories. The user stories are maintained by the product owner in a prioritized list called the product backlog.

There are two additional roles within Scrum. The ScrumMaster facilitates meetings and guides the team in the proper execution of Agile principles. The team builds the product. The team is comprised of highly skilled and motivated professionals who are cross-functional and have T-shaped skills. The team is eager to deliver high-quality software.

User stories are estimated by the team in a unit that identifies the size of the story, not the duration of time it will take to deliver it.

The user stories are delivered in short iterations called sprints. These sprints last between two and four weeks. Once the sprint duration is established, it does not change for the life of the project. Once a sprint starts, no changes are allowed. At the end of the sprint, user stories are delivered that are potentially shippable and that meet the established Definition of Done.

There are four meetings that revolve around the sprint. They are:
  • Sprint planning: This meeting occurs at the beginning of each sprint. The team, with the help of the product owner, moves down the prioritized backlog and decides what will fit into the next sprint. Some teams enter tasks for each story, identifying what is necessary to deliver the story. The ScrumMaster is present to facilitate the meeting and help the team with Agile process. At the end of this meeting, the team commits to the stories that will comprise the sprint.
  • Daily stand-up: This meeting occurs at the same time each day and is short, typically no longer than 15 minutes. The team reports the stories they are working and any impediments that are halting successful completion of the sprint. Any impediments that the team cannot take care of are handled by the ScrumMaster.
  • Sprint review: This meeting occurs at the end of the sprint. The team demonstrates the completed stories to the product owner. If the requirements identified in the user story are met and the story meets the Definition of Done, the story is marked as done. If the story is not done, it is moved back to the backlog. When new things are identified, they are also placed in the backlog. The product owner is responsible for keeping the backlog prioritized.
  • Sprint retrospective: This meeting also occurs at the end of the sprint. The team and the ScrumMaster attend. At this meeting, the team reflects on the past sprint and identifies what went well and what needs improvement.
Once the sprint duration has been established, all of these meetings may be scheduled well into the future. This approach helps the team develop a cadence of delivery.

It is common for the backlog to get cluttered over time. The product owner schedules backlog grooming meetings when necessary. In addition to the product owner, the team and ScrumMaster attend this meeting.

This process continues until the project is over or enough value has been added to the product to stop.
Each of the points in Scrum are present for a reason. It is common in the heat and pressure of project delivery to back away from them. Scrum is flexible and this is good. However, teams should be advised that changing too much will dilute the benefits Scrum provides.

The rest of this article goes into more detail about the benefits of the Scrum process. This will help teams understand what they may lose as they are tempted to deviate from Scrum.

The challenge of people working together

It is challenging for people to work together. It is easy for people to get distracted and work on things that are not the most critical for the product.

There are too many meetings. This causes hours of lost time when people sit and listen to things that are not important to them and the work they do. A solution sometimes is for people to bring their laptops and multitask. This is very inefficient and also frustrating for the meeting organizer, who needs input from people who are now distracted.

People receive too many emails. This makes it impossible for all emails to get the attention they deserve. Days and even weeks sometimes go by when a person is waiting for an important response to an email that was sent.

Developers are asked to make "one quick change." It is common for a stakeholder to see a developer in the hallway and ask for a simple change to what was previously requested. This derails the developer from what she was working on and causes things to take longer to deliver.

The essence of any Agile and Lean approach is to work in small batches and complete only what was defined for the given batch before starting anything else. This allows things to get completed and provides short feedback loops, where teams may inspect and adapt so they can make improvements.

Small batch sizes also give the team the confidence to try new things. When a mistake is made, the team's mistake only affects the work done in the single batch. This "fail fast" approach makes for a better product.

Since Scrum is an Agile process, it addresses all of these issues.

The product owner and the backlog

The product owner is the single person responsible for a full understanding of the product. She understands the marketplace and is responsible for designing a product that meets the needs of the organization.

She also maintains the product backlog. This is a prioritized list of the user stories that comprise the product. This backlog is 100 percent transparent and available to everyone on the project.

A prioritized backlog is powerful because it eliminates ambiguity. The team, during sprint planning, does not have to think about what is most important or what to work on next. Team members simply move down the backlog and accept stories into the sprint until there is no more capacity.

When a stakeholder requests something from a developer in the hallway, the developer simply points the stakeholder to the product owner.

We can deviate from this somewhat and still gain the benefits as long as there is a single product owner responsible for the role. There can be more than one person providing input, but the product owner has the final say and is the go-to person. There also must be a single transparent and prioritized backlog. If the backlog is not prioritized or is hidden in many different spreadsheets, we are back to ambiguity.

The ScrumMaster and the team

The ScrumMaster may seem like a project manager but is actually very different. The ScrumMaster must have a thorough understanding of Scrum and guide the team when it deviates. He must remind the team of the benefits of Scrum and ask probing questions that allow the team to see why the deviation it is contemplating may not be the wisest.

Project managers assign tasks to the team and tell team members what to do. A ScrumMaster allows the team to decide among themselves how to best deliver the stories in the backlog during sprint execution. A ScrumMaster is a servant leader and works to mold team members to become better.

Scrum also assumes that team members are highly motivated professionals. In most cases this is true. However, in any group of people, we have top performers and others who, for a multitude of reasons, sit back.

In Scrum, the team members are accountable to each other, not to some project manager who is telling them what to do. It becomes apparent very quickly, especially during the daily stand-up meeting, who is not pulling their weight. It does not take many stand-ups for peer pressure to cause under performers to step up.

It is up to the ScrumMaster to stay vigilant and observe the team for "smells" that may indicate a problem. He must ask probing questions and be a flashlight pointing out problems, continually asking questions that cause the team to think and see things for themselves.

The team must also be cross-functional and have T-shaped skills. Each person on the team will have a "deep skill" that is narrow and is the specialty the individual loves and is passionate about.

TShaped-Skills.jpg

Scrum also calls for broad skills that are needed to deliver a product. For example, a database expert will have deep skills that involve database development. As a sprint progresses, this database person will be expected to help in any other area she is capable of. For example, if the database work for a sprint is complete, she could help with the testing.

This simple idea is one way that Scrum teams get much more work done as compared to project plan-derived initiatives.

There are multiple challenges here, and we need to be careful not to view this as a project plan with a different slant. Things to consider here are:
  • Do not place a person in the role of ScrumMaster unless he or she has experience or has training followed up by day-to-day coaching by a Scrum expert.
  • Discuss the importance of cross-functional, T-shaped skills with the team. This is a challenge to some individuals who wish to stay only in their deep skill, either for status reasons or because of their love of their skill. Explain that Scrum is becoming the standard way to deliver software and it is in their best interest to accept this approach. Be willing to part company with folks not willing to adapt.
  • Understand that giving new teams the freedom Scrum allows is a bit like being careful what you wish for. New teams need lots of support and servant leadership from the ScrumMaster.
We should not deviate too far from these principles, or we lose these powerful benefits. However, new teams will struggle. It is easy to give up and feel the team will not get it. They will! It is up to the ScrumMaster to ensure that they do.

Estimation and user stories

Many Scrum myths revolve around estimation and requirements. These myths profess that Scrum does not estimate and has poor requirements. In reality, we estimate often in Scrum and have requirements; however, we do them in a different way.

User stories are written to the level of detail required for a given project and no more. We do not work to develop a large requirement before the project starts and stick to that requirement. We understand that requirements will evolve and change as stories are delivered sprint by sprint. At a minimum, user stories should follow the INVEST model:
  • I -- Independent: A story should be independent of all other stories.
  • N -- Negotiable: The exact details will be defined during a sprint.
  • V -- Valuable: The story should add business value, either directly or indirectly.
  • E -- Estimable: The story must be estimable. It does not need to be exact, just good enough.
  • S -- Small: The story must be small enough to complete in a sprint.
  • T – Testable: The story must be defined enough to be testable. This is typically defined using acceptance criteria.
The level of detail is defined by the needs of the project. This may range from post-it notes stuck on a wall to detailed stories to support regulated industries.

Each story is estimated in a relative manner to indicate its size. This estimate is fine-tuned as the backlog is better understood. During sprint planning, individual tasks may be entered that define the details necessary to deliver the story.

It is important to understand the difference between typical requirements and user stories. Requirements attempt to define and gold-plate what the author believes the system should do. A user story documents an intent that will be fully defined as the sprint evolves.

However, there are times when details are needed. Sometimes we need wire frames for the user interface and state diagrams to describe complex processes. Regulated industries may also impose details that are required. Start small and get bigger, if needed.

For story estimation, try to keep the estimates relative and to have no direct correlation to duration. If the team is not comfortable with a relative measure such as story points, use ideal hours instead. (The challenge here is to keep reminding management that eight ideal hours is not one day of work.)

Sprints

Probably the biggest difference between Waterfall and Scrum is that Scrum delivers software often instead of waiting till the end of the project.

Sprints are where the work gets done. It is also where most teams deviate from Scrum practices and thus lose many of the benefits of Scrum.
  • Sprints are short, timeboxed periods of time that do not change once established. Sprints are short because that way they provide inspect-and-adapt feedback loops. The shorter the sprint, the more feedback loops we have.
  • Short sprints also help us manage change requests. Once a sprint starts, no changes are allowed. When a developer is asked for a quick change, she can say, "Sorry, not now, but we may be able to do in in two weeks."
  • The reason we do not allow changes once a sprint starts is we want the team laser-focused on the work in the sprint. This is another reason Scrum is marked by high performance. Team members have fewer distractions.
  • Sprint durations do not change, because we want to develop a cadence for the project. As soon as we define 15 two-week sprints, we can schedule all meetings for months. The team builds a development rhythm. The product owner and stakeholders have every demo scheduled. This cadence builds confidence and trust as software is delivered over and over.
  • The reason we require stories to be potentially shippable is because we want stuff to really be done. We do not want nagging "little changes" to exist in our stories. These "little changes" add up and cause projects to be late.
  • The ScrumMaster must protect the team from the outside world. When the team is bothered by change requests and other distractions, the ScrumMaster must step in and speak with the offending person so the team can focus on its work.
Do not deviate from these practices unless absolutely necessary. For example, a good reason to deviate from the potentially shippable guideline is that regulated industries may require detailed follow-up documentation that could not be completed in a single sprint.

A reason not to deviate is the belief that the team does not have enough time in a sprint to test the stories. It is better to follow the Scrum process and let the team improve until the stories are tested.

This is where the ScrumMaster needs to provide servant leadership and help the team grow.

Scrum meetings

There are only a handful of meetings. Most of the time people are focused on getting valuable work done. Scrum meetings should never be eliminated or modified so much that they miss their intended goals.

Let's review the purpose of these meetings:
  • Sprint planning: The purpose of this meeting is to have the team take stories from the top of the prioritized backlog and add them to the sprint until there is no more capacity for additional stories. There a number of points that are important to remember:
    • The backlog must be prioritized.
    • The stories must be estimated.
    • The team must have an understanding of its capacity and velocity.
  • Daily stand-up: The purpose of this meeting is to have the team members report to each other the progress of the sprint and mention any impediments that are halting successful completion of the sprint. Important points to remember are:
    • Be on the lookout for a small number of Impediments. Maybe the team is reluctant to speak up.
    • If you are using remaining hours for burn-downs, be sure the team members are entering their hours.
    • This is a perfect place to mention emails and other questions that have not been answered.
    • Peer pressure is powerful. The fact that team members are reporting progress to each other often causes underperformers to step up.
    • This is where the ScrumMaster needs to be vigilant for "smells."
  • Sprint review: The purpose of this meeting is to review the stories delivered in the sprint and ensure that they are done. Important points are:
    • If the implementation does not meet the requirements defined in the story, it is not done and is moved back to the backlog and prioritized by the product owner.
    • If the product owner thinks of a new feature by seeing a completed story, a new story goes on the backlog and is prioritized.
    • The reason we do this is that we do not want to have lagging things that we need to do. If we accept a story as done when it really is not, we get a false sense of security about our progress. At some point, we need to pay the piper. Why wait?
  • Sprint retrospective: The purpose of this meeting is for the team to reflect on the past sprint and look for opportunities for improvement. Important points are:
    • Understand that new teams will find this uncomfortable. The ScrumMaster must poke and prod the team to open up.
    • This is not the only place to mention improvements. That can happen any time. The daily stand-up is another a good place.
    • Be sure to document as a team what will be improved in the next sprint and stick to it.
  • Backlog grooming: The purpose of this meeting is to review the stories in the backlog and groom the backlog so it is ready for future planning meetings. Important points are:
    • Watch for large stories. Stories should be completed in a sprint and should be as small as possible.
    • Plan for releases. The group sprints together to comprise a release and deliver an incomplete but valuable product.


In conclusion

Scrum is much more than a way to deliver software in an iterative manner. Built into Scrum are a few simple rituals, roles, and processes that, when performed correctly, deal with the challenges that result when smart people from different disciplines work together.

Just because it is simple does not mean it is easy. Keep the reasons for doing Scrum in mind when you are tempted to deviate.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.7 (3 ratings)

Comments

Joseph Collins, CSP,CSM,CSPO, 10/6/2014 10:31:43 PM
Thank you for such a great summary. I think it may be a universal truth that Scrum is so simple to understand but hard to execute. Overcoming a resistant organizational culture is crucial to ensuring 'hard to execute' doesn't turn into 'impossible to execute.'
Deepak Joshi, CSP,CSM,CSPO, 10/7/2014 2:20:14 AM
Good article. I would rather say this- Scrum in a nutshell.
It is really difficult for the people who have 'Waterfall modal' deep rooted in their daily practices. A hitch to embrace agility makes it more difficult to follow agile practices. Over and above finding a blend of Waterfall with Scrum makes it something weird. :-)

You must Login or Signup to comment.

 
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


 

Newsletter Sign-Up

Subscribe