One of the reasons that agile folks hate to call kick-offs a meeting is because people just hate meetings. They are often done so badly that the first association that comes with that word is waste of time. One the other hand, I have often seen many kick-offs that are not any better than “so called” meetings. Whether you call it a name or not, doesn’t really matter. What matters is that people need to get organized, that work needs to be distributed and that complete team needs to get a full picture. Therefore, I am not shy to call them meetings, as long as we can make them effective. And if you want to know how to be effective at that, there is no better place than listen to this podcast. If you ever want to be an effective manager, you should listen to what Marc and Mike have to say about different management subjects, but for the moment, let’s get back to our topic.
You can think of different meetings when it comes to agile development. As you can see from the list below, there are plenty of them, and you do wonder when the job gets done – so you better be good at it. Here we go:
- stand up meetings
- meetings that require split of work for the future (some call them scrum meetings or scrum of a scrum meetings if you have multi-site). Is there a scrum of a scrum of a scrum meeting?
- meetings that require demonstration of the work (artifacts) that is done in the previous iteration
- retrospectives (both after iterations and release)
- release planning meetings (normally agile people kind of ignore this one – but yes it happens)
In this post I will tackle the third item (demonstration of the work done), since this is the one on which you will find the least in the literature – and may be by coincidence or not, this is the one with wich many teams strugle the most – especially if teams are distributed in different time zones. Preparation for the next iteration often happens on the same meeting – in case that projects are small in size, but for the sake of keeping things simple, I will skip that part. Finally, one important hint, avoid doing these meetings on Monday – since people have hard time on Monday remembering what they were doing the week before. In my opinion, the best day to start iteration is Tuesday.
What is the purpose of demonstration kick off?
- Heartbeat of the project that keeps all sites in sync
- Gives sense of direction
- People have their 5 minutes of glory
- PO can verify implemented stories
- Test team/Doc team can follow what is happening (I know people will say that the test team should come up with BDD stuff and know up front all details of a demo, but that somehow doesn’t happen to me that often)
- Have a working build after every iteration
And finally, here is how to do it:
- Make one wiki page where you keep agenda’s of all iterations for this project
- Make agenda upfront and send it one day in advance to the complete team with link to the wiki page (that points to agenda of the current iteration)
- Every single person of the team should be on this meeting – regardless whether this is a multisite development or not. All communication tools should be available: phone bridge, share meeting tools (web-ex and similar) – and preferably this meeting should be held in video conference room.
- For every item in the agenda include: Start time, Item, Owner and the Attachment (artifact) (see agenda template at the bottom of the page)
- First item of this meeting is always project update, so that complete team gets full picture – and it is done by the scrum master. It should not last more than 5-10 minutes
- Attachment is everything from ppt slides, picture, wiki page to animation or picture.
- Artifact is teams definition of the accomplished task
- Ask people to prepare demo’s and ask them to attach all their work in the wiki – prior to the demo
- Demo is on the build server that has been installed by the test team 1 day in advance.
- Build server includes only checked in code.
- Demo – presentation of the artifact should not be longer than 20 minutes, on average not more than 10.
- If presentation includes working software, person that has implemented it shows it on the live system. I have heard of the nice variant where a member of the test team gives a demo.
- In case that something goes wrong during a demo – continue with attached animation so that you can get feedback from PO and the rest of a team. Best feedback always comes after people have seen the live demo, and even if real demo needs to be repeated in the next meeting, it is always good to continue with it.
- When people start arguing too much about the demo (including PO) stop discussion and address in the meeting right after this one
- Kick off meeting should not be longer than 2 hours
For people who for various reasons couldn’t be on that meeting, attachments and the agenda helps staying in touch with current development.