Wednesday, 27 May 2015

There's a reason standups use closed questions...

Standups, done well, are an important part of a great teams' way of working. Here is a very good article on stand ups its not just standing up
Standups in a nutshell:
  • set a disciplined, defined and energetic start to the day.
  • Re focus yourself on your plan for the day
  • Re focus the team on the goal for the sprint
  • communicate with your team members. Hear what they are doing.

To help achieve these goals, typically we let standups revolve around three questions:
  1. What did I do yesterday?
  2. What will I do today?
  3. What do I need help with?
These questions have very specific answers that should relate to the story or task level your team is working on. If you keep your team to just answering these three specific questions directly, then your standups will be short and energetic. Team members should be reporting this to the whole team.

Getting your team to stay on point

There are a couple of things to try.

One experiment to try and stay on point is to get the team to prepare a (6x4) Q card with the 3 questions specifically answered. Each member then reads out their answers at standup.

Another experiment is to pair up team members. Before standup, each member reports their answers to the three questions to their partner. The partner then relays this at standup.

Warning signs and things to try in your standup

  1. People wandering into problem solving mode in the standup.
    Park the discussion. Resume after standup with just the interested parties.
  2. People reporting to the scrum master or the product owner.
    Try to report to the whole team.
  3. People not listening to their team members.
    Try agreeing a team value. If you are not listening to me, I'm not listening to you.
  4. People joining the standup late and leaving early, once they have given their update.
    Discussion with the team member and agreement of a team value to take full part in the standup should help here

Tuesday, 26 May 2015

Team Definitions

In this short article, I want to define and clarify some of the terminology surrounding software teams.

Collection Names

Let's define four collections of people
  1. Group 
  2. Team
  3. Self organising team
  4. High performing team

Group

  1. A number of people who have some common attribute or skill that allows them to be classified together. For example Java developers, scrum masters.

Team

  1. Defined boundary for the members
  2. There is a common purpose
  3. Shared experiences

Self organising team:

  1. Defined boundary for team members
  2. Recognized leader
  3. Subtle control
  4. Diverse members
  5. Transforming exchanges
Taken from Leading a Self-Organizing Team

High Performing Team Definition

  1. Delivering business value all the time
  2. Will adapt to suit the business
  3. Continually Improving
  4. Happy to work together