Archives: March 11, 2016

The Sprint Review

I once asked a friend of mine ‘What would be the one thing you would change about Scrum?’ He pondered with that question for a short time and then responded. ‘I would change the name of the Sprint Review’.

This intrigued me and followed a conversation that reminded me of a few core principles that I had pushed to one side in my mind.

Quite often I hear teams refer to these sessions as a ‘Show and tell’ or a ‘Demo’. I had never felt passionately about a name before until I had spoken to my friend. I thought back to the sessions that I had been seeing recently and wondered, were they just a demo or were we truly collecting feedback?

The Sprint Review is actually a form of retrospective.

It is about:

  • The Product Owner telling the stakeholders what it is we have achieved against the Sprint Goal
  • The Product Owner advising of any key decisions that have been made in the Sprint
  • The team facilitating what changes have been made to the product
  • The stakeholders asking questions and providing feedback. With the team and Product Owner filtering changes back through the Product Backlog
  • Confirmation of when the Stories will be shipped
  • Any discussion on the future strategy of the Product
  • The Product Owner closing down the session and advising the candidate stories for the next sprint

In preparation of the review the team would have completed the Sprint to the Definition of Done and spent no more than an hour or two preparing for the Sprint Review (depending on length of sprint). These are informal sessions and there is no expectation to create flashy power points.

Work that is NOT DONE is NOT SHOWN…..

As with all ceremonies, they should be a regular heartbeat and the customers know when to expect them. The same time and the same place every 2 weeks is the dream, but sometimes tough to achieve.

As a ScrumMaster I would expect the team to self-organise over the Sprint Review. I might add a task to the Sprint Backlog during planning as a reminder to the team that this needs to be prepared for.

I have once let my team fail here. In one company I got fed up of reminding them to prepare for the Sprint Reviews and so one day, I just didn’t. Let’s just say that didn’t happen again Smile

When running large reviews, it is critical to be prepared. Often I book the meeting room 15 minutes before the allotted time so the team can go in, set up the machines and open any tabs that they might need. I am always conscious that we have lots of people and so avoiding time spent on waiting is something we can always do with removing.

If you find that you are not getting people attending the Sprint Review , then think about your advertising. As a ScrumMaster I have put up posters, gone to visit stakeholders 121, sent mails around the office, floor walked inviting people that might have an interest or dependency.

In larger organisations where multiple teams rely on the same people, then you need to collaborate and find out what would work best for your attendees. You might need to experiment with this.

Ultimately, I do what it takes to get people to the Sprint Review.

Once the team have shown the fruits of their labour, we then need to do the most important part. The part that is always forgotten……collecting the feedback.

In an organisation recently I experimented with giving them post it notes and the format

  • What did we like about these features?
  • What didn’t we like about these Features?
  • Great ideas to improve?

They did look at me a little crazy as this was something radical to them, but it ultimately got them to think about what we had just shown and enabled the Product Owner to get valuable feedback on where to head next.

How do you collect feedback in your Sprint Reviews?

At the end of the meeting the Product Owner should then give the attendees a view of the candidate stories for the next Sprint. I impress the word ‘Candidate’ on you because they are not confirmed until you have completed Sprint Planning.

Remember, the Sprint Review should not be the first time your Product Owner has seen the work. They should be looking at this regularly during the sprint, as with bringing in stakeholders to get early sight. Nothing in a Sprint Review should be a surprise!

I am often asked ‘What do we show, if there is nothing to show?’

This is an interesting question and a great one to exercise the 5 whys on:

  • Why do you have nothing to show?
       – Because the testing was not completed
  • Why was the testing not completed?
       – Because the developers did not get the work to us until the last day (hopefully you spotted the dysfunction there!)
  • Why did the developer not complete the work until the last day?
      – Because we did not get everything we need from the PO (Dysfunction)
      – Because the story was too big (Dysfunction)
      – Because the PO changed their mind mid Sprint (Dysfunction)

You get the picture. Remember what I about the ScrumMaster remorsefully looking to establish and remove dysfunctions of the team? There are visual and verbal clues over everything you do.

Other things to watch out for is where teams are not vertically slicing and so just delivering component parts. I also had this at an organisation recently. The question I ask them is ‘If I pulled the plug on your feature right now, what value have I got for my money?’ Because if I was truly being iterative and incremental, I would have still got something I could sell…right??

If I pulled your Sprint right now, do you have something that could still be used?

On the odd occasion there is a small config or non-client facing change, then assume your attendees don’t want to see physical code. Remember they are likely to be from the business. In this instance it is perfectly acceptable to just explain in plain English the change you have made and move on.

Another beautiful technique I saw a team do was story cards. One of the developers created it and used it to explain to clients complicated technical code changes that sat deep in a system. It was his way of articulating what they had done.

clip_image002

See the blog here for more details: http://tlaalt.blogspot.co.uk/2015/07/describing-value-using-situation-cards.html

Other tips

  • Consider if your stakeholders are distributed having two way video so you can see what they are doing and reactions to the product.
  • Consider actually getting some interaction from your stakeholders. Invite them to play with the product in real time.
  • You do not need to tell your stakeholders how many story points you completed.
  • You don’t have to justify why stuff was not done.
  • As ScrumMasters we can help this practice to be clear, transparent and engaging to the attendees. Use the walls and visualisation to help the session.
  • If the Product Owner cannot facilitate the Sprint Review as they are out of the office. Ask for a volunteer to do this the same as any other the session.
  • NEVER CANCEL! I have only ever cancelled 3 in eight years and 1 of those was because it was Christmas.  If you are cancelling these, its probably because you are hiding something.

If you take one thing from this blog, then that should be.

‘The Sprint Review is more than a demo, it’s about gathering feedback, inspecting and adapting’

My friend suggestion for renaming was ‘Sprint Product Retrospective’

My friend, is the funniest man in Agile….Nigel Baker

Finally….

I asked Paul Goddard for a tip of the week. He said ‘Listen with your eyes closed, you hear much more!’


The Daily Stand Up

Did you know that in original Scrum books by Ken Schwaber he talks about one of the roles of a ScrumMaster was to get enough chairs for the Daily stand up?  The first pilot company also used to take significantly longer than 15 minutes also. Oh how we have evolved Smile

If I said to you ‘The Daily Stand Up’ what words immediately pop up in your mind?

clip_image001

The words or phrase that pop into my mind are:

  • Synchronization
  • Swarming to release value

It is so easy to forget what the key outcomes of a Daily Stand Up meeting is and get caught up in the mechanics of it.

In a nutshell we want:

  • Team members to talk to each other and collaborate on the work that has been committed to.
  • To understand what problems are impacting us and what any potential upcoming risks are.
  • What value we need to unlock from the board.
  • Whether we can complete everything still we set out too. If not, there are expectations to be managed.

Did you know your most valuable pieces of work are actually the items that are waiting to be tested and deployed?  This is because we are only potentially a short stop away from benefits realisation or important feedback.  As teams we need to be focusing on ‘Finishing’ things, rather than starting new work. This might even mean that developers have to test!.  So a key outcome for me as an ScrumMaster is about teams swarming on getting whole items across the board and releasing the value early. 

There are a number of different ways to run them.  If you are in the early stages of Scrum you are quite possibly using the three questions:

  • What did you do yesterday?
  • What are you doing today ?
  • What stands in your way?

Over time I expect teams will alter this for their needs rather than slavishly following rules.

I vary the technique depending what traits I see the team exhibiting.

  1. I alter the three questions to just be.
    – What is everyone working on today?
    – What impediments or risks have we?
    – Can we still meet our commitment?  Handy to have your burn down on the board to aid this conversation.

    I tend to drop the ‘What did you do yesterday?’ questions as I trust that people come to work to do their best and that they are talking as a team where dependencies arise.  They do not need to justify to me what they did.  People shouldn’t feel as if they have to account for every minute of the day.

  2. Walking the board is also a great technique and useful when you have non-technical people wanting to know when their stuff is going to be done.  This technique really helps with swarming.  This is the practice that Kanban teaches. Typically we work from right to left looking at what it is going to take to complete this work. It is an opportunity for the team to pair together to get items over the line.
  3. If I have a team with lots of blockers, then I might just get the team to talk about these key items to see what we can do as a team to keep things moving.

I might vary running these meetings in different styles on a daily basis to get different information shared. You don’t have to do the same style every day. 

In whatever technique you run a key thing I see happening time and time again is ScrumMasters being reported to or ‘Running the meeting’

We need to think about how we can stop this from happening, They are not there to report to you!

Top Tips

  • Did you know that the ScrumMaster doesn’t even need to be at the Daily Stand ups?  The team should be able to facilitate this for themselves and manage their impediments.  Pop off for a cuppa and see if you team springs into action!
  • Don’t stand in front of the board.  We should be as standard facilitating from the back of the room and so the focus is not on us.  If you have not heard of facilitating from the back of the room….find out!
  • Don’t call out the name of the person who you want to speak.  Use ‘Who’s next?’
  • Use a prop such as a ball to get the teams to throw around and speak.  This helps them to decide who they want next to speak.  No one is looking at you either, because they are focusing on the person with the ball, and then not dropping it.
  • Rotate the role of facilitator around the team, let them all have a go.  I used to play ‘Spin the pen’ and if it lands on you, then you are facilitating for the day.  If some people are nervous of this, then it’s a perfect coaching opportunity for you.  Always ensure that you give the facilitator positive and improvement feedback.

The meetings should be in a regular heartbeat and so teams know the time and the place of the meeting as standard.  The time to update the board is NOT during the meeting.  People should be doing this on a regular basis throughout the day and not just saving it up.  This will help you to keep it to the recommended 15 minutes per day.

Did you know you don’t have to run these in the morning?  Teams can actually choose whatever time is best for them.  You can even have more than one a day if you are working on critical tasks. Some teams even have them last thing in the evening so that they are set up for the day to come in and get cracking. The key is whatever ever you do the team is getting value from these sessions.

A technique that I adopt to validate this, is to ask the team members to raise their hand of they feel they are not getting value, because maybe the conversation has diverged into problem solving.  This is a sure fire way to make sure that you keep things on track.

We keep the sessions to 15 minutes to promote valuable synchronization. The chances are if they are taking longer, it’s because you are problem solving or not talking about relevant items.  One team I had used to take 20 minutes to complete their stand up.  This was fine, because the value they got was worth the time they spent together.  Try and avoid extending it out much further Smile

If you do have lots of problem solving, then maybe your need to book 15 minutes after the Daily Stand up so the team can then brainstorm what they need to, but have a clean finish to the previous meeting.

The most powerful tools we have as ScrumMasters is observation and facilitation.  Observe what you are seeing and always challenge whether we can improve the way that we work.  Use your facilitation to guide the team and to help them decide and achieve for themselves what needs to be.

We are there as ScrumMasters to grease the wheels of the teams, reduce lead times, protect the values, principles and practices and to ensure that we continuously improve ways of working.  Quality is also at the heart of everything we do.

So reflecting on your daily stand up meeting today, what could  you do differently.

 

 

I want to thank: Nigel Baker, Geoff Watts, Bazil Arden and Alex Gooding.   I asked them all what their lesser known top tips or facts were in preparation of this article and they provided their input.