🍃 Leaf

Scrum

Scrum is an Agile framework aimed to incrementally deliver value through collaborative work by defining rules, boundaries, roles, and structure for each one and each stage for projects with challenging, complex problems and rapidly changing requirements.

Scrum Origins

The word “scrum” (and “rugby approach”) was brought to product development by Hirotaka Takeuchi and Ikujiro Nonaka on their paper “The New New Product Development Game” in the 1986, where they analyzed new approaches that lead them to better understand how can we enhance development speed and flexibility, well-known weak points of old, sequential methods. Ken Schwaber and Jeff Sutherland co-created Scrum based on it (1995) inheriting the Agile philosophy. Later, Mike Beedle wrapped Scrum around XP practices and artifacts (2001).

This paper presents six key characteristics that leading companies had in common:

  1. Built-in instability. Teams were given great freedom of action and hard, challenging goals. They had more opportunities from which to benefit from. Nevertheless, more options mean more complexity. Also, pressure on individuals increases as they are now (freely) responsible for their decisions. However, such a context is long known for being fruitful for innovation as it pushes human creativity beyond the limits.
  2. Self-organizing project teams which are identified by three must-have traits: autonomy—from top managers and directors, self-transcendence—making them and top managers forget about status quo and recognize that they can always be auto-sufficient, and cross-fertilization—due to the fact that cross-functional, multi-disciplinary team members are always sharing knowledge and initiatives when truly working together.
  3. Overlapping development phases, which “enhance shared responsibility and cooperation, stimulates involvement and commitment, sharpens a problem-solving focus, encourages initiative taking, [and] develops diversified skills.” On the other hand, management becomes more complex and good communication skills become a must-have for everyone.
  4. ”Multilearning,” it happens in two dimensions. One is multilevel learning: the pressure imposed by the challenges and teammates lead everyone to learn more and grow because it is a necessity. The other is multifunctional learning: members from a cross-functional team have the privilege but also the requirement to learn about multiple tools and disciplines. Interactive experimentation also rises initiative and organizational flexibility.
  5. Subtle control, while top managers give teams great freedom, they provide the “big picture” point of view preventing ambiguity and tension from turning into total chaos. Traditional management is avoided as it impairs or even extinguishes creativity and innovation. Subtle control includes self-discipline control, peer pressure—instead of “boss” pressure, and passion/love for what you do. Healthy management control exercises:
    1. Build balanced teams by selecting the right people.
    2. Creating an open work environment.
    3. Make team members to research costumer requirements by themselves.
    4. Establishing a group performance evaluation & reward system.
    5. Helping regulate team members working rhythm—specially at the start.
    6. Tolerating & anticipating mistakes.
    7. Make (external) suppliers self-organizing and knowledgeable about our needs.
  6. (Organizational) transfer of learning to other teams facing new projects or even different divisions. It is appropriate to assigning key members to new projects, so we leverage the accumulation of knowledge, something called transfer of learning through “osmosis” or to prevent “silos of knowledge.” It is also key to standardize practices through the whole organization for later projects. To institutionalize lessons learned from success. Yet, excessive institutionalization can be bad. Unlearning lessons when required by environment changes is crucial to keep a realistic, up-to-date organization culture.

Observed limitations and undesired effects:

More at The new new product development game (paper, damiantgordon.com).

Scrum Philosophy

Scrum is supported by three pillars:

With no trust, scrum’s efficiency is not low, it is zero. (Me)

These pillars stand on a single foundation:

Scrum values, traits a team needs to have success:

How to Scrum

Scrum is not a silver-bullet. It does not bring success … The effort is great and those that succeed will be in the minority. (Ken Schwaber, co-creator of Scrum)

What the Scrum’s “guide” looks like:

Not every company is ready to give up command-and-control [practices]. (Learning Agile)

However, as any other method, Scrum does not fix chaotic circumstances; a guide is not enough; in order to succeed we need self-organization, collective commitment, and a lot of effort.

Scrum Roles

Development Team

(1) Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishment toward organizational objectives. It is the fuel that allows common people to attain uncommon results. (2) Teamwork appears most effective if each individual helps others to succeed, increasing the synergy of that team; ideally, every person will contribute different skills to increase the efficiency of the team and develop its unity. (Andrew Carnegie, 1835-1919)

A unit of cross-functional, self-organized people that produces value as software. Once it’s defined—by the Product Owner—what will be delivered within the next Increment after each Sprint Planning, the Development Team is fully committed to meeting the goals, one at at time, without losing its focus. In Scrum no one has the authority to interrupt or interfere their job—unless the Product Owner decides to abort the Sprint.

The Development Team is responsible for having all of the skills it takes to decide what will they work on; how will they do it; and finally get it done by themselves. In case they lack tools or knowledge, they are also accountable for acquiring what’s needed to: break down requirements into technical tasks; and turn these tasks into the working product both users and customers expect. All of this while adhering to the acceptance criteria defined by the Product Owner.

A team should have a size of 5 to 10 people. Experts say 7 is a perfect number. Small teams may have a hard time trying to cover all of the roles and requirements in a coherent period of time, while on the other side, large teams hurt their productivity due to the raised level of complexity they deal with when it comes to work coordination and synchronization.

Product Owner

The Product Owner is accountable for the content and priorities of the Product Backlog by being who exclusively owns it. Any change made to the Backlog by someone else must first be accepted by the Product Owner as she is the only one given with such authority to do so; moreover, she is on of the only persons who can take the decision of cancelling a Sprint.

This role is covered by only one person intended have the best understanding of the project goals by keeping key user concerns in mind in addition to her main job as a business stakeholders’ representative. Her commitment is to give the project a purpose by defining its value.

The Product Owner establishes what is to be done next by choosing which Stories are to be moved into the Sprint Backlog during its Planning. She does research to align business requirements with user needs and gives clarity to the Team communicating the details on a daily basis for keeping the requirements up to date and validating their implementation if done right—or bouncing it back giving immediate feedback in case it’s not acceptable.

See also:

Scrum Master

Practices in the absence of principles are often inappropriately used. (Agile Project Management, Jim Highsmith, 2009)

The Scrum Master is a servant leader who coaches the Team and helps it remove any roadblock through the entire process. This person is well versed about Agile and Scrum and facilitates every Scrum event. The Scrum Master helps the rest of the team solve their problems—with as little help as possible so they remain auto-sufficient—as well as to keep focused with the big picture in mind. This person is also facilitates the job of the Product Owner helping him or her define targets and create clear yet concise Backlog items.

To have an average knowledge about Agile or Scrum is fine except for this role; he or she is proficient and advocated to the Scrum approach; mentors and educates about it when needed. The last person expected to do “mechanical Scrum”—just following the guide while ignoring its foundations and mindset—is the Scrum Master. He or she must be a good example. Some people may not feel confortable with this role, it demands constant determination and initiative while being under a considerable load of exposure and responsibility on a daily basis.

Scrum Events

Sprint

Scrum is a nicely balanced, counterintuitive mix of both “no pain, no gain” and “work smarter, not harder.”

Scrum projects run among the chaos, uncertainty, and complexity of unpredictable contexts, which seems to be productive, the more difficult the job, the more we learn—and that is quite a filter for the ones who like to face challenges from the ones who doesn’t. Moreover, we know that there is no remedy for such circumstances. It’s not possible to eliminate that complexity, however, it is possible to break it down into simpler parts, Sprints are that kind of parts.

(1) “Sprint is the term used in Scrum. I dislike the term because it implies running as fast as possible. A software project is a marathon, and you don’t want to sprint in a marathon.” (Robert C. Martin, Clean Agile, page 23, 2020) (2) “‘Sprint’ is a misleading name. Software development is more like a marathon than a series of sprints. You need to work at a pace that you can keep up indefinitely.” (James Shore, The Art of Agile Development, page 187, 2022)

A Sprint (or Iteration in XP) is the fixed-length event in which value is defined and produced through all of the other events. It must take no longer than 30 days—often run in periods of 2 weeks—and is chained one after another. At the end of this event the product will gain a measurable enhancement, getting brand new features, improvements, bugs fixed, and more; whatever aims at the problems we need to solve first—as per business stakeholders.

The very first Sprint is often called Sprint Zero, of course it won’t produce nor add “new” value, instead, it is used to elaborate the initial and overall planning for the whole project (which can be considered an homologous of the Planning Game in XP).

A less popular kind of Sprint is the Hardening Sprint (or Sprint H). It is exclusively dedicated to fixing critical, complex bugs or making high priority, non-functional improvements. Is does not add new features but enhances the product’s stability, reliability, or performance.

See also XP, Iteration (leaf).

Sprint Planning

It is the starting event of every Sprint in which we define what will we work on and (partially) how will we do it. Its constrain is to last up to 8 hours—often 2 hours are enough. First, we (including the Product Owner) need to define what it is to be build, the Sprint goal. Then, the Team decides how will they build it. Of course, plans are not fixed nor expected to be perfect at all; changes may—and certainly will—occur as is the nature of any Scrum project.

See also XP, The Planning Game (leaf).

Daily Scrum

”[A daily] does much more for [us] than just capturing information … It makes everyone say it front of everybody else. That way everyone listens to what others are doing and they can [immediately] offer help … It makes everyone [expose] issues face to face to their management. This forces everyone to have courage and to be honest, [which puts pressure on management too]. It also makes everyone promise in front of everyone else what [they] will be working on … It puts everyone’s credibility and trust to test. Scrum is about deep social interactions that build trust among team members.” (Agile Software Development with Scrum, Understanding Scrum, 2002)

The Daily Scrum is an event run by and for the Development Team to inspect the progress toward the Sprint goal and adapt to new conditions whenever it’s necessary. In Scrum this event is timeboxed to 15 minutes. Neither the Scrum Master nor the Product Owner are required to attend, however, it is the Scrum Master who usually participares and help to facilitate it and keep the overall focus.

Read (more) notes at XP, Stand Up Meeting (leaf).

Sprint Review

finishing the sprint, an informal product review (demo) by external stakeholders, with dev team and external stakeholders, to: 1. current state 2. next targets, a bit of (pre)planning, review prioritization, upper/lower priorities, an opportunity to get lessons learned.

Sprint Retrospective

lessons learned an evaluation similar to the review, but instead of centered in the team and the work instead of the increment and the project’s backlog inspect and adapt to become more efficient all members are required to attend three targets: 1. what is right, 2. what could be done differently, 3. what to commit to changing (processes, practices, tools, and more) timeboxed to a ratio of 1 hour per 10 days of Sprint

Scrum Artifacts

Product Backlog

The Product Backlog acts as a To-Do list for the development team. As said before, it’s owned by the Product Owner but can be updated by anyone—as long as the Product Owner permits it. It works as the source of truth for what needs to be done: business/system requirements; User Stories; enhancement request; reported bugs and any other valuable idea.

The Product Owner is responsible for setting the priority and the order of its items. The more refined items are moved to the top, these tasks are highly implementable as they are already clear and well understood by everyone. Items closer to the bottom are the opposite, they cannot be implemented until they get reviewed and broken down into more detailed and simpler ones.

See also User Story (leaf).

Product Backlog Refinement

Product Backlog refinement or brooming is to… estimating, adding or removing, decomposing, to clarify the big-picture for a smoother planning and execution by the PO and dev team, it can happen as a single event or be segmented into multiple instances during the Sprint, no more than the 10% of the time available for working by the dev team (capacity),

Sprint Backlog

A Product Backlog’s subset of items to be implemented on the running Sprint.

Increment

An Increment is the actual working software produced during a given Sprint.

Reference: