How to be effective at kick-offs

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 podcastIf 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.

Example of the kick-off agenda in the wiki

Project checklist – 7 questions you need to ask yourself first

Very often people discuss project/dev.  methodologies, type of contracts (fixed price vs. time and material), product release cycles and other aspects of project lifecycle while ignoring or forgetting to ask themselves some very important questions first.

So, let me go over my project checklist and default answers, keeping in mind that the only good answer that always applies is “it all depends

  1. Is this project done in small startup or big corporation? This might be more of a rhetorical question, just to get you prepared for different dynamics you might expect when it comes to getting budget for HW, IT support, support from stakeholders etc.. What might be “given” in one company can sound as a bridge too far in the other one. Be prepared before you start project to check all of these and if required – work on your networking.
  2. Is this project about building a product or is this one-off customer project (CDE)? Goals are not necessarily the same for both. If we talk about CDE projects, it is important to satisfy a customer who pays the bill (here we either go XP way or implement everything to the letter), while if you want to make a product that sells over years, I would argue that PO role is much more than just a customer facing person. That might as well answer the question in case you do outsourcing, whether you should be in favor of fixed price or time and material contracts.
  3. Is this project part of the bigger solution or not? You can afford to do agile project planning by selecting features from the backlog for the next iteration one iteration upfront only if you are the only customer of that project. Period. Here I am not making distinction between company that is the customer of that product, or the product that has only one customer. In case that your product is part of the bigger solution, you need to build a skeleton plan (see story maps and similar techniques) and revisit dependencies over the project lifecycle.  “Famous” Gantt charts can help you too – when it comes to drawing dependencies with other modules, products and expected milestones – which you need to communicate to outside world anyway. Be ready to add communication and planing overhead into your project. And to make it clear, I am not saying that in that case you should give up on agile development – just that you need to add real project management role to your scrum master role or ask someone else to do that part for you.
  4. Is this product going to be deployed in the cloud (server side on the web) or it is going to be installed at the customer premises? If your product is hosted on the web, maintenance cost is minimal and release cycles can be very short. If you are making B2B software that ships to customers behind firewall that expect fixes up to 3 years from the date the product is released, any release cycle shorter than 6 months is suicidal. Nevertheless, continuous integration and unit/automation testing should always take place, no excuse there.
  5. Is this product made for space program, military, medical institution, finance, large business or end consumers?Level of regulations, required documentation, tools that are used, coding languages, procedures, is something that you or your team can’t always decide on their own.
  6. Is this single or multi-site development? If this is your first multi-site project, grab books from Crag Larman or Alistair Cockburn that talk about it and read them twice. After that, be ready for some traveling.
  7. Is your team made of motivated and senior developers or not? If you have bunch of young motivated guys, you will succeed – in the next release, providing you are still around and people are still motivated after the first one. Take time to train people, be aware not to do too much micromanagement and keep the good spirit in the team. If you have bunch of non-motivated juniors – run away. If you have non-motivated seniors, you have to earn your money. And finally, if you have a great team, you should not worry, you will even have some time to read and write some boring blogs.