We hold these every morning at 10:30 am as it’s a time when everyone can get into the office. Three questions are asked of each developer:
- What did you complete since the last meeting?
- What blocked you since the last meeting?
- What do you intend to complete before the next meeting?
The answers to these three questions give a snappy status update for the entire team. In particular, the second question is a direct request for me to do something.
To keep the meetings short there is supposed to be no more discussion beyond the three questions. If needed then it should be scheduled directly after the meeting. However our meetings have recently begun to drag on as I found the “after meeting” gatherings weren’t happening and I let the discussion happen in-line for fear of it never happening (a self-fulfilling prophesy?).
The side affect of this is to subject everyone to a level of detail that may not be relevant to them, wasting time and boring them. So today I’ve asked everyone to answer their questions in 2 minutes. The benefit of a short meeting is obvious but also it gives people practice at concise communication.
Hopefully this should work, but if not then I’ll resort to a trick I used at Sony – a two-minute egg timer. Once the time runs out you have to shut up. If you have more to say then you have to e-mail everyone.
A note for self though – I must make sure the post meetings happen.
Tomorrow is “Show and Tell” day. This is our take on the Scrum Sprint Review where the idea is to show the team’s progress and direction to the Chickens. The review is open to anyone who would like to come and see what the engineers have been up to for the last month. The format is fairly loose – as all the developers have laptops they can take turns to plug into a projector and show what they’ve been up to. Individual presentations are limited to 15 minutes + question time.
The benefits are obvious: engineers get a chance to show off their work and direct feedback from the people who are dependent on their creations; Sales, marketing and management get to review progress and provide input.
There is always a little nervousness on my part because I don’t do much speaking – it’s up to the individual developers. Their view of the world revolves around code, architecture and designs whereas the chickens think about schedules, customers and revenue. With the two positions, there is some room for difference of opinion but regular reviews keep everyone on the same page.
So roll on the demos…
It’s nearly the end of the month and hence end of the current sprint. I was having a discussion with a developer this morning about the amount of work remaining on the list. The developer in question hasn’t been able to spend a lot of time on the project this month due to higher priority customer needs and therefore won’t be able to complete his agreed functionality.
According to Scrum, we have two seemingly opposing forces:
- The end of sprint review where the team shows the progress for the sprint
- The rule that “only potentially shippable code” should be shown
The problem is that his part of the system is the user interface and without it the sprint review will be mostly white-board and some of NUnit tests. Not very exciting and not liable to provoke much discussion. So he asked the question – “Should I just hack it to get something on-screen”? I had to think about this for a while because it’s very tempting to say yes. I could almost justify it by saying that its demo code and will be thrown away.
After, musing for a couple of minutes I said no for the following reasons:
- Rule (2) above
- The sprint review is designed to show project progress and demo code is not progress
- The act of hacking in demo code and pulling it out again tends to add entropy and hence bugs into the system
So a question for a future post should be “Why did I not clear the block (customer needs) for the developer?”.