h3. Becoming agile. The first baby-step
agile
There are many ways to become agile. And many ways to fail horribly while trying! Purists say that you are not really agile until you do _everything_ in a truly agile fashion. That might be true. But beware – don’t try to start everything _at the same time_. That’s a recipe for disaster. To make the transition to agile go smoothly, this blog post focuses on a simple way to get started with agile: perform daily standup-meetings.
Why start with stand-ups? Because they work perfectly in any environment, including traditional waterfall environments. So you can get started without even telling your boss about your agile intentions, and achieve good results even if you ultimately decide to remain non-agile. Daily stand-ups will still save you money and keep you focussed.
h3. How does it work?
Daily standup-meetings are as simple as they sound.
You gather the team in the same spot each day, stand in a circle, and then everyone takes turns in answering three simple questions: What did I work on yesterday, what will I work on today, and is there is anything that is blocking me? Each person gets one minute on average (sometimes more, sometimes less), and overall it shouldn’t take more than 10 minutes. That’s it. In a way this is so old-fashioned that I wouldn’t be surprised if ancient Greeks did this…
But beware! Daily standup-meetings are also a bit harder than they sound. After the “new” effect wears off, and before the long-term gains start to be fully understood, people might find it tempting to slack. So let’s have a look at the long term benefits outside of having a nice team chat…
h3. How does it help?
Introducing a quick daily standup-meeting is the cheapest most astonishing improvement I can think of for any project and one of the fundamental aspects of communication with an agile team.
* *It helps your team avoid duplication:* if Steve plans to work on a problem that was already solved two months ago by Sam, then you can bet that Sam (or someone else) will tell Steve before he even starts wasting time;
* *Clear roadblocks:* if someone is blocked by something particular, this is the perfect time to check who could help: “I have been working on bug X, with little progress. Has anyone seen X happening? Let’s chat _after_ the standup meeting”;
* *Detect roadblocks:* if John tells the same story for the fifth time in a row, everyone else will realise that he is severely stuck and needs a hand. Catch him right after the meeting and get him some help;
* *Boost team coherence and commitment:* team coherence and commitment is increased when everyone speaks to everyone else on a regular basis. Especially when you don’t all work in the same room, or when different members of the team work on different aspects of the same project;
* *Increase project manager accountability:* daily standup-meetings even make the project manager more accountable. When your manager comes to ask your status, would you dare ask him _his_? Probably not. But in a daily standup-meeting the manager is reporting his status to everyone else;
* *Increase team member accountability:* daily standup-meetings make each team member more accountable as well. A manager might not notice that Sal is over-engineering her solution just for the fun of it – but the rest of the team will;
* *Spread transparency:* if you are the project manager, then the project is probably transparent to you already. But there is immense value in team-wide transparency too. People are not machines, and love knowing what’s happening. This is the place!
h3. What are the costs and risks?
Admittedly, the daily standup-meeting does take time. And some people don’t like speaking in front of others. And at times the meeting can distract people from doing important work. These are all valid points. But you need to compare them to the costs that arise by _not_ having this meeting. How much work would be lost by double work, or by people not realising they are stuck? How important is staff retention to you – and what better ways of open communication can you get at a price tag this small? As long as you apply common sense and accept that some people _occasionally_ may miss a meeting, and that others may not be great at speaking (but _do_ attend and listen), there is little to worry about.
A bigger risk are people who like to hear themselves talking. The stand-up meeting is not for story-telling. You need to be strict about the time-limit. If someone exceeds the standard 60 seconds, usually a smile combined with the “Time-out sign” will help. A common problem is that the boss feels inclined to turn his 60 seconds of fame into a 5 minute speech, to ensure he looks more important than everyone else. Someone needs to have the guts and speak up – in a friendly way, and depending on the kind of boss it may make sense to do this after the meeting, to come across less confronting. The same applies to discussions. Stand-up meetings are _not_ for discussions. They should _encourage_ discussions, but after the standup-meeting, and with just the people who really care. If someone frequently starts discussing what someone else said, take them aside and explain that the discussion is great, but it needs to happen after the meeting.
It will help to nominate one person to become the ‘Standup-Champion’ who will make sure that the meeting remains focused and finishes quickly and on-time. This person also makes sure the meeting happens in the first place, so the person should not be too shy to shout out “It is STANDUP time now, guys and girls!”)
h3. So what’s agile about it?
You can start stand-ups without turning agile. But the impact is bigger than “just” efficiency, transparency and team building. The standup-meeting quickly turns into the catalyst meeting of the day. It regularly spawns discussions about things that were not considered in the “big plan”. It helps you address problems earlier. It helps you reshuffle your road-map because you learn about good and bad news early. It encourages people to wrap up tasks more frequently, and to tackle tasks in smaller increments, because no one likes to tell (or hear) the same report every day. Standup-meetings don’t _make_ you agile, but it would be harder to become agile if you didn’t have them. So they are a great first step on your long winding road to agility.
h3. Q&A
*When is a good time to get started?*
As with any change, you need to be careful. People are often hesitant about change, especially if they have been subjected to frequent random change before that didn’t help. So don’t introduce this when the tension is high already, or when you are new and don’t have any credibility yet. In software development terms, how about waiting until the current version of your software has been shipped, and everyone had a great time at the post-launch party. As with every change, first make the proposal, discuss it with the team and with relevant stakeholders, and take on their feedback before you actually get started. You may even want to try it out with a subset of people who are more keen on trying new things out. Just make sure to keep everyone in the informed.
*Is it necessary* *_all_* *the time? Can we just have standup-meetings in times of crisis?*
Standup-meetings are awesome during times of stress and crisis. They keep you focused and help avoid unnecessary work. But ask yourself: How can you avoid stress and crisis in the first place? How about avoiding straying, and how about avoiding unnecessary work in the first place? Standup-meetings are no silver bullets, but they can help avert crisis by catching problems early.
*How about just doing it once a week then? That should save us some time?*
The opposite will be true: People will talk for longer. People will prepare more (if they only get to talk once a week, they will want to shine!). There will be less focus on the week ahead. If someone did double work, it will be too late to save time. If someone was stuck, she will have been stuck for a while now. And so on. Weekly meetings also have their place, but they should be dealing with larger issues, like planning and discussing the work ahead, and they should only have the people involved who are actually needed for that discussion.
*Can we sit down? Standing is uncomfortable…*
You are missing the point. It _should_ be uncomfortable! You have to keep the meeting short. If everyone sits in a comfy chair and sips on great coffee, what are the chances of the meeting being short? Don’t even dare to lean on that table – HTFU mate!
*Is my team big enough to justify this?*
At my previous job, I thought stand-ups would not be necessary for a team of just five. After all, we were sitting in the same room already, had plenty of discussions, and I talked to the individual developers quite frequently already. We started only when we ramped up to 8 and then 10 developers. Only when we did so, I realised how much I had missed what the original 5 developers had been doing (and what they had not been doing..). And of course the transparency improvement for my colleagues was even bigger than for me. Stand-up meetings even with just three people make sense, after all double work needs to be avoided all the time, and with just three people on the team you should be done in 3 to 5 minutes anyway.
*Is my team too big to justify the costs?*
If 16 people spend 15 minutes a day, that adds up to 4h per day, and a whopping 20h per week. This is of course still just 3% of each person’s time, and a team will need to communicate anyway, so 3% is not too bad. But indeed, if your team is so large that people start complaining about the duration, or you see people dozing off, then you need to reconsider. On the Confluence team, we decided to split the big standup into two meetings when we reached 18 people. Our team consists of four sub-teams, and we do a rotation now. During one fortnight the sub-teams A and B meet at 9:45, and sub-teams C&D meet at 10:00. The next fortnight sub-teams A and C meet at 9:45, and subteams B and D meet at 10:00. And so on. Obviously you will have a little less knowledge-sharing because some people will only meet every two weeks. But of course there are so many other ways to share information too. Wiki-pages, wiki-blog posts, wiki-discussions and (sometimes) good old email don’t get replaced by stand-ups after all.
*When is a good meeting-time?*
It really depends on your team. If you all start working at the same time in the morning, then that time is ideal. But if people trickle in between 8:00 AM and 10:30AM, then any time is a bad time, because it will distract the people who came in early, or exclude the people who come in late. You may want to consider a time just before everyone goes to lunch (this can actually help you get everyone to go for lunch at the same time). Or you just go with 10:30. Just make sure that you let the team decide, and make sure to review your decision frequently. Maybe 8:00AM seemed like a good idea at first, but once people realise that their transport is less reliable than they thought, you may want to reschedule. Tell everyone that the time will be reviewed after, say, 4 weeks.


**Learn about other agile practices**

*That was an interesting introduction – where can I learn more?*
Try Martin Fowler for plenty of stand-up patterns and anti-patterns. I also recommend seeing how Atlassian practices agile development.