Some time ago I was in an organisation that was very keen to adopt agile ways of working. They had some basic training, but didn’t know how to fully embrace it. So when I arrived I was happy to be greeted warmly, and many people were curious about my experiences, and what they could learn from those.
A few days in two colleagues pulled me aside and asked about “agile meetings”. Their jobs involved a fair amount of organising meetings, preparing agendas, and writing up and circulating minutes. They thought there must be a better way, and asked for my thoughts.
I must admit I was somewhat stumped, because agile working is more about doing than talking about doing. But of course there are times when teams meet, and finding agreement and exchanging information is essential, so I tried to draw out some lessons from those things. I don’t honestly remember what I said at the time, but here some ideas now:
- Short and frequent. Stand-ups should be brief, and are daily. The generalisation is that short, frequent meetings are preferred over longer, less frequent ones. It keeps things pacey, and there is a stronger call to make small steps of progress before the next meeting.
- Regular. A team’s stand-up, retro and planning meetings are typically on a regular cadence. This means that everyone knows far in advance when the meetings will be and they can make sure the time is set aside in their calendar. On the occasions when I’ve had, say, show and tells on an ad hoc basis, or had to move them from their regular slots, it’s been near-impossible to get all the stakeholders to attend. So regularity helps everyone.
- Rough outputs. Partly because of the “short and frequent” rule, and partly because there is an emphasis on action over documentation, agile prefers rough outputs, generated faster, rather than beautifully-formatted outputs. Most memorable to me are architectures which are hand-drawn on flipchart paper, then photographed for the team wiki—no time spent drawing up diagrams in Visio or the like. But more usually, retrospective outputs are simply photos, too. The idea is that we shouldn’t get too attached to decisions; we’re moving things forward at pace, and we expect both context and our thinking to evolve.
Perhaps you have other ideas, too. What’s interesting to me is that while agile working has some very specific common practices, there are philosophies that can also benefit a much wider selection of activities.