5 Most Powerful Acronyms for Agile Coaches

AcronymsPhoto by tuchodi is licensed under CC BY-SA 2.0

Personally I love acronyms, because they serve me as mnemonic for some of the important stuff that I shouldn’t forget as an agile coach. Further they are simple to teach and made to stick. Here are my top 5 acronyms for agile coaches:

FROCC

The Scrum values can be easily remembered with the acronym “FROCC”, the misspelled frog:

Focus – we focus on a few things at a time
Respect – we respect our colleagues like we want to be respected
Openness – we express our thoughts about how we are doing
Courage – the team gives us the courage to take greater challenges
Commitment – we are committed to success

Source: https://www.scrumalliance.org/why-scrum/core-scrum-values-roles

DEEP

A well refined product backlog is “DEEP”:

Detailed appropriately – the details are added over time
Estimated – backlog items are estimated
Emergent – a product backlog changes over time
Prioritized – the most valuable items are on top

Source: https://www.mountaingoatsoftware.com/blog/make-the-product-backlog-deep

MoSCoW

When it comes to prioritizing your backlog “MoSCoW” can serve you well. Distinguish your features by:

Must have – the requirement is core and must be satisfied for success
o
Should have – the requirement is should be satisfied for success
Could have – the requirement is desirable but not necessary for success
o
Won’t have – the requirement will not be implemented

Source: http://en.wikipedia.org/wiki/MoSCoW_method

INVEST

“INVEST” in well-defined user stories. A user story must be:

Independent – the user story has no dependency to other stories
Negotiable – user stories can always be changed and rewritten
Valuable – a user story must deliver value to the end user
Estimable – you must be able to estimate the size of a user story
Small – a user story must fit into a sprint, but should be smaller
Testable – a user story must be testable

Source: User Stories Applied (Mike Cohn)

SMART

Make (iteration) goals always “SMART”:

Specific – target a specific goal
Measurable – quantify or at least suggest and indicator of progress
Achievable – be realistic
Relevant – check relevancy of the goal
Time-bound – assign a target-date

Source: http://en.wikipedia.org/wiki/SMART_criteria

Any other suggestions?

Advertisements

The Scrum Master Maturity Model

This blog post is dedicated to Angel Medinilla‘s awesome “Scrum Master Maturity Model”, which describes three levels of maturity a scrum master can reach (before Agile nirvana is reached 🙂 ):

  • The Scrum Dude: Scrum Dudes have rudimentary scrum master skills and little experience with scrum, which results into low-performing and mostly disoriented teams. Scrum Dudes are more like secretaries for their teams.
  • The Scrum Mom: Scrum Moms are solicitous and protective to their teams like a mother for her children. Teams with a Scrum Mum can be well functional, but Scrum Moms miss to challenge their teams, which often leads to stagnation.
  • The True Scrum Master: The true scrum master coaches, leads and develops high-performance teams that are able to self-reflect, learn and continuously improve. She addresses conflicts, keeps the team challenged, encouraged and motivated.

Scrum master maturity model

 

Angel’s model is of high practical value, because it gives us a visual representation of the actual scrum master role we find in the industry. In fact I have met many so-called “scrum masters” who later turned out to be Scrum Dudes or Scrum Moms, but very little who were actually true Scrum Masters. Let’s improve this! We need true Scrum Master to improve our organizations!

Source: http://www.infoq.com/presentations/hire-scrum-master

Yet Another Sprint Retrospective With “Moving Motivators”

In this blog post I want to share my experience with another great tool from the Management 3.0 workshop, called the “Moving Motivators” game. But first, let’s have a quick look into the science behind intrinsic and extrinsic motivation:

 

Daniel Pink tells us in this video that science has proven that extrinsic motivators don’t work for knowledge workers, which is a fact that has been ignored by most organizations for the last decades. The “Moving Motivators” game is a great tool to reveal what really motivates us to do our jobs.

Recently I decided to play the “Moving Motivators” game with one of my agile teams in our sprint retrospective.  Even if we shared an open team culture and we knew each other quite well we never talked about our intrinsic motivators inside the team. So I expected to get some new insights into that blind spot.

Preparing the game for our retrospective took me about 2 hours of time. This is what you need to do:

  1. Print the Moving Motivator cards: I used a bit heavier paper (e.g. 100g) than usual office paper and a color laser printer that produces good quality prints, because I think it is essential that the cards look nice and professional.
  2. Laminate the cards: The printed cards look great but laminating them makes them awesome 🙂 It also protects the cards, makes them reusable, gives them a professional look and a nice touch. Your team will love them!
  3. Cut the cards and prepare the card decks for handing them out to your team

Champfrogs

 

During the retrospective we followed the 3 steps through the exercise, which took us about 45 minutes. And, yes, the team loved the nicely crafted cards 🙂

In conclusion the “Moving Motivators” game was a welcome variation to our usual retrospectives that helped us to talk about our motivations for our jobs. Personally it revealed that I have had badly misjudged some of the team member’s in respect to their intrinsic motivators. The “Moving Motivators” game helped me to correct the view on my colleagues and made me start respond more accurately to their actions and behaviour.

If you would like to play the game with your team I can leave you some tips here. The exercise requires a high level of trust and an open culture. It is also crucial to talk to your team before you do the exercise with them – everyone must agree. Take your time to prepare the cards nicely. It will be much more fun! If your team fulfills the prerequisites the exercise is a great opportunity to get to know each other better and bring you one step further as a team.

Why You Should Define Reference User Stories

If your organization is new to Agile one of the things you might struggle is the shift from traditional to agile estimation. I have seen a lot of inexperienced agile teams struggling with the nature of story points and relative sizing. Often a lack of trust in their own estimates, which led to poor planning, was the consequence. A simple tool, called reference user stories, helped each of these teams to overcome these difficulties.

If you haven’t defined reference stories with your team yet, consider well-defined, well-sized, not too domain specific user story from your past sprint(s) as candidates. Ideally you want to have reference stories of different size (e.g. 1, 2, 3, 5, 8 and 13 story points). Alternatively you can define artificial user stories that will serve as your references. Create a table of your reference stories, like the one below, and use it in your backlog refinement meetings. Feel free to add or exchange reference stories later if you feel the need later.

Size User Story
1 Story A: As a user I want to see my user name on the page so that I know that I am logged in with the right user.
2 Story B: As a user I want to write a comment to a topic so that I can express my opinion to the author.
3 Story C: As an administrator I want to block users for the forum so that I can prevent them from spamming.
5 Story D: As a user I want to register for the website so that I can use their premium services.
8 Story E: As a system administrator I want to migrate data from database A to database B via an automated script so that I can handle the amount of data.
13 Story F: As a user I want to purchase a product via the online shop so that the article is delivered to my home.

According to my experience reference user stories have the following main benefits for agile teams:

  • Supporting relative estimation: A user story (e.g. Story X) is relatively sized to the defined reference stories (e.g. Story A, B, C, D, E, F), which helps to focus on relative estimates (e.g. story X is bigger than story B, but smaller than story D) instead of absolute figures (e.g. story B will take 40 hours of work).
  • Increase accuracy of estimates: Relative estimates are more accurate, because our brain is naturally better at relative sizing then in absolute estimation. Defined reference stories also keep a stable reference and therefore reduce variability in the estimates.
  • Normalization of story points: Defining, sharing and using reference stories among multiple teams, normalizes their view on story points. With normalized story points we can calculate velocities for multi-team projects by just summing up the team velocities. (WARNING: Never abuse normalized velocities for team performance measures!)

Why You Should Use a Definition of Ready in Your Projects

In my former blog post I introduced the concept of the “ready-ready backlog” for Agile teams. In this blog post I want to share some metrics about the effect of introducing a “Definition of Ready” (DoR) to industry projects.

I introduced the following DoR for an Agile team that has worked for 3 months together:

  • The business value of the user story is understood by the development team
  • The acceptance criteria are clearly defined and understood by the development team
  • Requirements on documentation, specification, configuration, test, regression tests and architecture are clarified
  • The development team has a concrete idea of demonstrating and testing the user story
  • The user story has been estimated by the team with a high confidence level

After introducing the DoR I gathered the following metrics from the following 7 sprints:

  • # of user stories committed for the sprint
  • # of user stories in the sprint backlog that did not fulfill the DoR
  • Velocity
  • Team happiness (1-10)
  • Fulfillment of sprint commitment (green = fulfilled, red = failed)

The results can be seen in the figure below:

DoR

 

By using the DoR in the backlog refinement meetings the behavior of the team changed perceptibly. Without the DoR it was sufficient for the team, if backlog items were shortly discussed and estimated. With the DoR the team focused much more on each backlog item and the discussions went deeper. More pitfalls were discovered upfront. Anyway it was hard to get each user story “ready” before sprint planning because of the high project pressure. After bumpy 4 sprints the ability of the team to analyze and refine backlog items improved significantly. For the following 3 sprints all committed user stories were “ready” according to the DoR and during the sprints less incidents happened due to overseen or miss-interpreted requirements. The DoR had a rather small impact on the ability to fulfill sprint commitments and velocity but by shifting the focus on getting backlog items “ready” it perceptibly improved the ability of the team to analyze and refine backlog items.

5 Tips on Getting Your Backlog Ready-Ready

Last year I worked with several teams on improving their development process by introducing a Definitions of Ready (DoR). Jeff Sutherland points out the importance of a DoR to achieve a “ready-ready” backlog in the following video:

 

Here are my six practical advices on getting a “ready-ready” backlog for  your projects:

Define your Definition of Ready:

Define your own Definition of Ready together with your team and product owner. The idealistic vision of a “ready-ready” user story is that the team can implement it without interruptions. Define your DoR according to this vision and your specific project needs. You can use the following list of questions as a guideline for your own DoR:

  • Does the user story meet the INVEST criteria?
  • Is the business value clear and understood by the team?
  • Are the acceptance criteria well-formulated and understood by the team?
  • Could everyone on the team test the user story?

Warning: I saw teams going way too far with their DoR, trying to lash requirements like in traditional design documents. Overcome the temptation to fall back in old habits.

Use your DoR for each user story:

Only the development team is allowed to call a user story “ready-ready”. Therefore the development team checks each user story, if it fulfills the criteria of your DoR or not. This can be done while backlog grooming or any time you prefer before sprint planning, but the product owner should be present.

Make “ready-ready” user stories visible:

It helps a lot if everyone can have a quick overview on how many user stories are “ready-ready” in the backlog. Use labels, coloring, traffic lights, prefixing or whatever you prefer to emphasize “ready-ready” user stories in your backlog. It doesn’t matter how you flag them as long as they are visible at one glance when looking at your backlog.

Make the sum of estimates of “ready-ready” user stories visible on your task board. Show the teams velocity next to it to signalize if you have enough user stories “ready-ready” for the next sprint planning. Having the figures prominent on the board makes everyone aware of the current backlog health and triggers action for backlog grooming.

Visualization of ready-ready backlog and velocity
Visualizing ready-ready backlog and team velocity on the task board

I also experimented visualizing “ready-ready” user stories on cards in a separate column on the task board but it was much more effort to maintain and update the column than just putting the sum of estimates on the board and the effect was the same.

Track open issues:

Make open issues (that prevent user stories from being “ready-ready”) transparent to everyone. It is crucial that open questions, unclear requirements, missing research or analysis, etc is visible to everyone, so that everyone knows what prevents a user story from being “ready-ready” and therefore needs to be resolved first. I my teams we keep track of open issues in a table that is attached to the user story like the one below:

Status Issue Responsible Solution
RESOLVED Is the address field mandatory for the user? PO Yes.
OPEN Check if email validation is already in place and working. Team

Live your DoR:

Make sure that the product owner and the development team understand the benefits of a “ready-ready” backlog. Provide your support whenever it is needed until the DoR flows through everyone’s veins. Live your DoR!

 

Verteilte Sprint Planung

Ich habe in einem früheren Blogpost bereits über die Agile Planung geschrieben. In diesem Blogpost möchte ich auf die Besonderheiten der Sprint Planung mit meinem verteilten Team eingehen. Mit lokal arbeitenden Teams habe ich die Sprint Planung immer wie folgt abgehalten:

Standard Sprint Planung:

Ich unterteile die Sprint Planung für gewöhnlich in zwei Teile:

Sprint Planung 1 (SP1):

  • Leitfrage: Was soll gemacht werden?
  • Teilnehmer: PO, SM, Gesamtes Entwicklerteam
  • Output: Commitment des Teams

Sprint Planung 2 (SP2):

  • Leitfrage: Wie setzen wir die User Story um?
  • Teilnehmer: Gesamtes Entwicklerteam, SM (optional)
  • Output: Technische Tasks

Dieser Modus wird von Boris Gloger empfohlen und funktioniert für meine Teams meist sehr gut. Für mein verteiltes Team habe ich jedoch das SP2 kleineren Änderung unterzogen.

Motivation zur Veränderung:

Das SP2 kann mitunter über mehrere Stunden dauern und erfordert intensive Denkarbeit der Beteiligten. Vor allem bei meinem verteilten Team war es schwierig die Aufmerksamkeit der Entwickler auf Dauer hoch zu halten. Folge war, dass nur wenige (meist immer die selben) Entwickler den Großteil der Denkarbeit erledigten. Dementsprechend war auch das Verständnis der erstellten Lösung  sehr unterschiedlich, was wiederrum im Sprint zu Produktivitätseinbußen führte. Ich beobachtete folgende Faktoren, die mit dem Phänomen des “Sozialen Faulenzens” in Zusammenhang stehen:

  • Fehlende Identifikation mit der Firma / dem Produkt (Off-shoring)
  • Unterschiedlich stark ausgeprägtes Fachwissen der Entwickler
  • Geringes Fachwissen bei externen Mitarbeitern (Off-shoring)
  • Kulturelle Unterschiede im Team
  • Niedriger Bekanntheitsgrad der Teammitglieder
  • Fehlende Präsenz des Scrum Masters im SP2

Verteilte Sprint Planung:

Um dem Problem zu begegnen haben wir den Modus des SP2 etwas abgeändert. Grundidee war nicht mehr das gesamte Team alle User Stories sequentiell ausarbeiten zu lassen, sondern zuerst in kleineren Sub-Teams (2-3 Entwickler) Designvorschläge auszuarbeiten, die danach mit dem gesamten Team diskutiert wurden. Wir unterteilten das Meeting also in folgende Abschnitte:

  • Designvorschlag ausarbeiten: Die ersten Designvorschläge wurden parallel von Sub-Teams ausgearbeitet (je 2-3 Entwickler). Jedes Sub-Team arbeitete an Designs für andere User Stories. Time-box: 1 – 1,5 h
  • Präsentation & Diskussion: Die Designvorschläge wurden den anderen Sub-Teams präsentiert und diskutiert
  • Einigung: Das gesamte Team einigte sich für jede User Story auf eine Lösung
  • Tasks erstellen: Das gesamte Team schrieb die Tasks für die User Stories

Erzielte Verbesserungen:

Die folgenden Verbesserungen konnten in der Folge erzielt werden:

  • In den kleineren Sub-Teams beteiligten sich alle an der Lösung (“Soziales Faulenzen” wurde deutlich minimiert)
  • Die Designvorschläge wurden noch einmal von den anderen Sub-Teams “gechallenged”, was die Designs robust machte
  • Die Motivation der Entwickler war in den Sub-Teams als auch in den Diskussionen höher als im alten SP2 Modus
  • Die Lösungen wurden vom gesamten Team verstanden
  • Das Team fühlte sich im SP2 produktiver