Posts Tagged ‘DoD’

Scrum Starter Pack

Posted: August 26, 2014 in Scrum
Tags: , ,

I had a lovely brunch with a friend the other day. She’s a PM at a small firm and has toyed with the idea of starting Scrum and doesn’t really know where to start. Just my kind of person to talk to! After ninety minutes of trying not to overwhelm her with enthusiasm and information, I left hoping she at least had a starting point. I also sent her the links below as her first ‘starter’ pack (there’s so much more I wanted to add!) with the advice to do the CSM course to at least get some idea of the games, principles and lingo.

What would you share if you only had sixty minutes to influence without overwhelming?

This morning I ran an initiation session with one of my (merged) teams. As the team will be splitting into two smaller teams in the near future, I had to shift the activities a level higher than usual and didn’t cover things like team norms, but I thought I would share what we did do anyway as the team seemed to find the session valuable and hopefully you will too.

My agenda consisted of three parts:

  1. A discussion of the learning styles of the team members.
  2. A Definition of Done exercise.
  3. Identification of tasks we need to do to ensure everyone has access to what they need (I won’t discuss this in this post).

I booked the session for 90 minutes and, as it ran over lunch time, I organised some snacks which were available from when the team arrived. The room had a ‘loose’ structure with tables pushed to the side for the first part of the session to encourage engagement. I time-boxed each piece and allowed everyone to get up and get more snacks/drinks when I felt that the energy was starting to ebb.

Learning Styles

The team completed the learning styles questionnaire in advance and I put up the summary for all team members on flip chart paper. I circled any preferences that were very low or very strong and basically invited open dialogue and questions. Before starting, I emphasised that:

  • Learning styles are situational: you may have a different profile depending on the context in which you answered
  • Learning styles are PREFERENCES. Just because you have a low preference, it does not mean you cannot learn in the other styles.
  • Learning styles can change over time. For this reason, it is recommended one shouldn’t use data that is more than a year old.

For more on Learning Styles, you can refer to the following links:

Definition of Done exercise

I based this section on this guide.

As I had a big group of people (about 13), I decided split the group into smaller teams for some of the exercise. I noticed that the teams tended to be the same ‘usual suspects’, so I did a team shuffle between steps 1 and 2.

  1. In small teams (of about four people), the group listed the activities needed to get a piece of work from the beginning of development to production.
  2. Still in teams (after shuffling), they grouped the activities based on at what level they are done (ours deviated from the guide slightly as we don’t have iterations/sprints and have two ways of getting into production depending on the story).
  3. Each team took a turn to present back. The first team presented their solution as-is with the other two teams adding or discussing levels based on what they had.
  4. We created our Story Definition of Done checklist – as well as a Story Definition of Ready as it turned out we’d specified some of those as well.

Note that we didn’t move onto identifying impediments causing us to have tasks at the release level as there wasn’t time. I do feel this is a great way to identify impediments and ways for the team to improve their delivery process.

The above conversations led to a better understanding of new team members and a common understanding and agreement of what done meant. Engagement levels were greatest when the group was able to work in smaller teams and I felt the shuffling mid way helped to bring some ‘cross pollination’ into the process. One aspect we didn’t touch on, which I will definitely include when the teams split, is a discussion of team norms and preferred ways of working.

What kick-off or initiation activities have you found have worked well with your teams?

One of my three teams works mainly on a communications engine and provides a lot of operational support for new reports and static information, particularly around this time of the year. They’ve run Scrum without a Scrum Master for almost a year and have managed to keep things ticking over. After observing for one sprint (three weeks), I facilitated the following minor tweaks based on my observations:

  1. Sprints now have an overarching sprint goal that the team can swarm around where necessary. I find a sprint goal is a simple and useful tool for helping teams maintain focus and make good decisions. We agree on the goal with the Product Owner during Sprint Planning I. I know some advocate that the goal be agreed before planning and possibly even as early as at the Sprint Review for the previous sprint, however in our world where we don’t really have a product, it’s easier to do it together with the sprint commitment. The goal conversation has also already helped us during Planning I where the Product Owner had to re-prioritise based on the fact that we couldn’t achieve all the goals with the team capacity available, so he had to make a call on which goal was the most important goal. Having a goal also led to some of our developers volunteering to support some testing work by creating tools to ease data comparisons. This reduced the manual effort required significantly, leading to us achieving far more in a sprint than we otherwise would have.
  2. Defined our Definition of Done (DoD) which is now posted up on the board. For me the most useful part of doing this DoD was the exercise itself (see below) as it helped me better understand the release and testing cycles. For this team, most of the tasks are done at a story level and there was no work required at sprint boundaries to complete their DoD. The challenge across all teams within our IT department is that the first fully integrated testing environment is UAT, and this environment is only updated/available prior to major releases (which happen approx. every 9 weeks). This impediment is one which will need addressing over time and is on the Scrum Master forum’s radar.
  3. Revived the practice of acceptance criteria for stories. The team opted to have these written on the back of their story cards. In this team, the most valuable aspect of having acceptance criteria is the conversation required to identify them.

Useful tools / links: