Tag: Scrum tactics

Posted on by — 1 Comment

Can you say ‘yes’? (10 questions about your Scrum)

I call myself a  Scrum Caretaker. I aspire inspiring people using Scrum. I prefer showing that I care by sharing positive experiences and cases that demonstrate how amazing working with Scrum can be, what problems can be tackled and how to, the level of excellence we can build into our products, how Scrum can engage people. Ultimately I hope to help people employ Scrum to re-humanize their workplace.

But then it regularly dawns on us — the many, many misconceptions that exist over Scrum. We feel provoked to try to correct the recurring and worrying interpretations of Scrum that are out there. Sometimes that is fun. Often it is not. It can be energizing. In general it drains us. A few lifetimes can be spent fighting that battle. We limit the energy spent fighting to make room for constructing. 

A good place to start is reminding people of what ought to be in place according to Scrum. It provides clarity over what is mandatory in Scrum (and therefore, what is not).

Unlocking the benefits of Scrum requires however a lot more than just knowing what Scrum consists of. Scrum is the foundation to a complex adaptive system (‘CAS’) producing results that cannot be attributed to its individual components separately. Unlocking the benefits of Scrum depends more on the way the whole of Scrum is being used, through the rules that bind its constituent parts together. Unlocking the benefits of Scrum depends even more on what the people practicing Scrum do, more than what they know or say in the name of theory. It depends on how people interact within the framework, the conversations they have.

Here are 10 questions to help you assess what you do with the 11 elements of Scrum. Can you say ‘yes’?

  1. The accountabilities of Product Owner, Development Team(s) and Scrum Master are identified and enacted?
  2. Work is organized in consecutive Sprints of 4 weeks or less?
  3. There is an ordered Product Backlog?
  4. There is a Sprint Backlog with a visualization of remaining work for the Sprint?
  5. At Sprint Planning a forecast, Sprint Backlog and a Sprint Goal are created?
  6. The result of the Daily Scrum is work being re-planned for the next day?
  7. No later than by the end of the Sprint a Done Increment is created?
  8. Stakeholders offer feedback as a result from inspecting the Increment at the Sprint Review?
  9. Product Backlog is updated as a result of Sprint Review?
  10. Product Owner, Development Team(s) and Scrum Master align on the work process for their next Sprint at the Sprint Retrospective?

Minimally, make sure that you remain aligned (6) and that you regularly check what else might be needed (10). Upon that foundation, grow towards saying ‘yes’ to all questions, meanwhile collaboratively exploring different  If you don’t overthink your way of working along that road of evolution, you might find Scrum to be of a bare essence actually.

Minimally, make sure that you remain aligned (6) and that you regularly check what else might be needed (10). Upon that foundation, grow towards saying ‘yes’ to all questions.

If you don’t overthink your way of working along that road of expansion and evolution, you might find Scrum to be of a bare essence actually. Do know that understanding that Scrum requires 11 elements to be in place is only the beginning. My 10 questions might help you better understand how they relate to each other. Find yourself at the beginning still. Understand how all of them serve empiricism, the act of regular inspection and adaptation, and how inspection without adaptation makes no sense in a world of Scrum. Separate rules from tactics to play the game. Use empiricism also to explore different tactics

My Scrum Gameboard not only represents the 11 mandatory elements, but also 3 principles underlying Scrum. Understand how the Scrum Values drive behavior.

Keep learning.
Keep improving.
Keep… Scrumming.

Warm regards
Gunther
independent Scrum Caretaker

Posted on by — 4 Comments

Scrum: Tactics for a Purpose

Scrum is a framework designed to help teams create and sustain complex software products in complex circumstances through the scientific method of empiricism. Scrum has replaced the industrial, plan-driven paradigm with well-considered experimentation to better deal with the complexity and unpredictability of modern software development. And although the use of Scrum is free, its roles, artifacts, events, and rules are immutable. Implementing only parts of Scrum is possible, the result however is not Scrum. By breaking its base design it is likely that problems are covered up, instead of being revealed.

The purpose of Scrum is to help people inspect & adapt, to provide transparency to the work being undertaken, to know reality to base decisions on, to adjust, to adapt, to change, to gain flexibility. The rules, principles and roles of the framework, as described in the Scrum Guide, serve this purpose. These are the rules of the game of Scrum, the base setup to have in place.

Soccer - Rules of the game

But we distinguish principles from techniques, the what from the how, the rules of the game from tactics to play the game. It’s like in all games and sports, all players and teams play upon the same rules, yet some teams seem more successful at playing than other teams. It depends on many factors, and not all are equally controllable by the teams themselves. One factor are the tactics used by the team to play.

Soccer tactics on a blackboard

There are many tactics to use within Scrum. Good tactics serve the purpose of Scrum. Good tactics re-enforce the Scrum values, not undercut them.

I’ve previously described how practices from eXtreme Programming provide great tactics, ways to play Scrum, even when not mandatory from the Scrum perspective.

Here are some more illustrations on the distinction between the purpose of Scrum and tactics for that purpose:

The Daily Scrum questions

The Scrum Guide suggests that in the Daily Scrum meeting every player of the Team answers 3 questions (Done? Planned? Impediments?).

But the players might just formally answer the questions, limit it to a personal status update, and talk to the walls or to the Scrum Board. They just make sure that they -well- answer the 3 questions. Because the Scrum Guide tells them to, or some smart coach or Scrum Master or manager.

But is the team seeing Scrum as a methodology? Or use Scrum as a framework for discovery? It doesn’t help much if they don’t talk to each other. It doesn’t help much if they don’t surface the information to optimize their collaborative work plan for the next 24 hours against the Sprint Goal. Maybe they use the meeting only as a reporting obligation in which they make sure all their microtasks are logged, to cover against possible blame. They miss the opportunity to gain insight in the real situation, to inspect it and to adapt upon it.

Maybe Scrum should describe only ‘what’ is expected from the Daily Scrum in the time-box of 15 minutes. Although, actually, the Guide already does so by saying: “The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.” We could eliminate or rephrase how this is exactly to be achieved, in turning the 3 questions into a good, yet non-mandatory, tactic.

The Definition of Done

The Definition of Done was rightfully given a lot more attention in the latest version of the Scrum Guide. However, some people wonder why it isn’t an official artefact. I did so too, even launching the suggestion to make it one. However, I got to see that the Definition of Done is an aid to transparency, and I overcame my urge to turn it into an artefact.

Here’s how the Definition of Done helps playing Scrum:

  • Scrum assumes an inspection of a working product Increment at the end of every Sprint, at the Sprint Review. The Definition of Done gives transparency to that inspection by unveiling what’s the work that has been done upon the Increment, what criteria were met.
  • The Definition of Done guides the team at the Sprint Planning to pull work into the Sprint, as the work needed to get to “Done” is likely to influence the amount of Product Backlog that can be pulled into a Sprint, as well as the estimates for that work -if the team uses any-.
  • The Definition of Done helps the team create and manage their work plan for the Sprint in getting things done, and not end up with a pile of nearly-done work at the end of a Sprint.

So, what Scrum requires is transparency. The Definition of Done is a way to provide that transparency at several levels and several occasions. It’s a great tactic that stresses the importance of seizing the opportunity to ship.

Product Backlog Grooming

Product Backlog grooming is an activity in which the Development Team and the Product Owner look at Product Backlog currently sorted for one of the next Sprints. Certainty that the included items actually are going to be implemented is growing. So teams might want to unveil dependencies or help a Product Owner understand what is useful to know from a development perspective. Grooming increases the chances to pull the work in more easily when it is presented at the next Sprint Planning.

Product Backlog grooming is not a mandatory (time-boxed) Scrum event. The ambition of Scrum is to remain simple, yet sufficient. The ambition of Scrum is to help people and teams discover additional practices that may or may not be appropriate in their specific context. Product Backlog grooming is an activity that seems to help many teams to smoothen their Sprints, and certainly limit turbulence in the first days of a Sprint. Other teams however cope without it, and perceive it as optional or even overhead if it was mandatory from the Scrum framework.

Product Backlog grooming is a great activity within a Sprint, a good tactic to collaboratively manage Product Backlog. Some can do without however.

Sprint Planning Part 1+2

Sprint Planning meeting is an opportunity to inspect the actual state of Product Backlog and identify what work is most useful and feasible at the actual point in time, with the option of pouring the work into a work plan for the Sprint.

The empiricism of Scrum assumes following for the Sprint Planning:

  • IN: Product Backlog
  • OUT: Sprint Goal & Sprint Backlog

Currently the Scrum Guide prescribes the flow of the Sprint Planning meeting:

  • Part 1: Product Owner explains highest sorted Product Backlog items. The Team discusses, evaluates and pulls in items. A Sprint Goal is crafted.
  • Part 2: the Team decomposes, discusses and designs the work.

It is however possible to respect the IN and OUT of the Sprint Planning meeting upon a different flow of the meeting. Maybe Scrum can suffice by describing only ‘what’ is expected from the Sprint Planning in its time-box without prescribing ‘how’ the Scrum Team should achieve this. Organizing it in a part 1 + part 2 might be a great tactic, but it’s probably not the only one.