Daily stand-up with a goal

Why your daily standup should be driven by a daily goal

Let’s face it, the daily standup can be a boring affair. I’m not talking about abominations with 16 people or half-hour long status reporting meetings. I’m talking about the ones that are kind of okay and adhere to the rules but nonetheless are a bit boring and lack focus and enthusiasm.
 

Interview with a newly-minted Scrum Master

Six months ago SilverStripe, an open-source Content Management System provider and Wellington web agency approached me to help them improve the way in which they deliver client and open source projects, increase employee happiness and, in general, just do the best possible job. To achieve this, we decided to move away from the existing Agile-like (fixed scope/fixed price) approach and introduce Scrum with its focus on client-driven iterations, early feedback and continuous improvement.

Silverstripe have asked me to interview some of their staff about the transition to Agile. The original posts can be found on Silverstripe’s blog (Sam MinnéeAleksandra Brewer), below are selected highlights from the interviews. 

Exploring servant leadership

A few weeks ago I was sitting next to a log fire, sharing a glass of wine with a few like minded individuals chatting about all things Agile, one of the things we discussed was a time when one of the party was a Scrum Master and that they had a team admin who used to collect all the story data and do the typing up for each sprint. My immediate reaction was that of outrage, “how as a servant leader could you, farm off ‘menial’ tasks to someone else, that’s an integral part of the role”.
 
It got me thinking, am I the odd one out here?
 
Most of the Agile literature I have read over the years mentions servant leadership, but never really goes in to too much detail. A quick hike to the lazy man’s oracle, (Wikipedia) and as the saying goes “the more you know, the less you know you know”. To help me learn and understand servant leadership a little more, I decided to dissect the Wikipedia commentary and see what emerged for me.
 
Robert K. Greenleaf never specifically defined servant leadership but, based on the writings of Greenleaf and others, it can still be defined as a management philosophy which implies a comprehensive view of the quality of people, work and community spirit.”
 

The Wall of Pain

Software projects experience a problem called technical debt. In short, technical debt is the result of making a quick and dirty work around (often for valid reasons such as deadlines) which creates rework later.
 
I recently visited an organisation that had a wall of pain which I thought was an excellent idea as it highlighted the levels of technical debt in the project. This involved a section of the workspace dedicated to items that needed refactoring at a later stage. This made me think about pain and our tolerance to it.
 
The wall had lots of pain on it and the team did their best to address this pain whenever they could, a commendable exercise for any team.
 
That said i am not sure how much the pain was actually felt, as i said there were lots of cards and they were not easy to see when the team did their stand up in front of the visible workspace, so they did not feel like they were always on the mind of the team.
 

Even done is never done

A “done” definition in an Agile project is a statement that the team use to measure whether they’ve met all of the requirements for completing a userstory / feature (and in some cases completing an iteration or release). Done is one of the major shifts from doing Agile to being Agile.
 
So, what is “done”? Is it the quality mantra for the team? Is it the way we communicate completeness to the customer? Is it a process for eliminating waste? Is it about how we would like to work to bring about that “potentially shippable” product? It’s all of this but crucially belongs to the team, is created by the team, and is used as a measure of success. A “done” definition may look similar between teams but is never the same.

A template for the sprint review

Conducting an interesting and engaging end-of-sprint review is an often overlooked art: Not only do we want to show what we have built during the last sprint and collect feedback and good ideas for what to build next; we also want to give our audience a good experience. 

At my workplace we always invite the entire company and often have more than 30 people in the room. As they claim to be happy and to enjoy the fortnightly experience I thought it might be useful to share our template and some guidelines for what is working for us.

Why being a Scrum Master is a full time job

An adequate Scrum Master can handle two or three teams at the time; a great one can only handle one”. (Michael James – An Example Scrum Master’s checklist)

I found that organisations, teams and new Scrum Masters (even freshly certified ones) often aren’t sure what the Scrum Master role entails and what value it provides. 

Here is my attempt to summarize what a good Scrum Master does:
 

The Scrum Master role

Some teams are like symphony orchestras, so they need a leader who keeps everyone on the same sheet of music. Conductors have to be deeply familiar with each instrument and with the music, yet they don’t play in the band or tell the musicians what to do. They let the music provide detailed guidance; their job is to bring out the best in the musicians, both individually and as a group.” (Mike Cohn – Succeeding with Agile)“A Scrum Master is like a conductor coordinating the efforts of musicians, helping them to play together. Some teams are like jazz bands, so they need a leader who encourages improvisation.


 In general the Scrum Master …

 

  • makes sure the team is running (good) Agile development
  • assists team members in adopting and improving Agile Development
  • helps the team maximise throughput and to work in the best possible way