Category: Meetings

An Agile Story – a guide to this website

On By JPIn Agile Boards, MeetingsLeave a comment

The number of articles here on Agile Fixer is growing all the time. This article is designed to help you navigate to those that may be of particular interest.

Once upon a time, in a wonderful far-off land called “Agile”, there lived a man, who told a tale…

“So I work in a biggish company, and we have quite a few software teams. I know some of the tech guys personally, and it’s my job to know how much they collectively cost – and it is a lot. We’ve had a patchy history of building apps and websites in this organisation. Software development seems very hard to do well, with many teams struggling with their processes, and unable to give convincing answers to even the most basic questions about how much work something involves and when it will be done.

In the last few years a lot of our teams have started doing a thing called ‘Agile’, which apparently is a better way than whatever they did before. But it’s certainly no magic bullet – it seems to introduce a lot of confusing jargon; for example, some of these teams now say ‘when something will be done’ using a made-up unit called ‘Story Points’, which doesn’t seem to be any real improvement if I’m honest. Perhaps part of the problem is all the big, long meetings these expensive techie people spend their time in (many of the developers actually complain bitterly about this) – I sure hope they’re using this time wisely.

Agile heaven - it doesn't fix everything

Actually these techies have one meeting that seems a bit different from the others – it’s a quick one in the morning that is often held in an open space, with a lot of people standing up. You only see the techies doing this, nobody else in the organisation; it’s a bit odd, really.

When you watch them in these morning meets nobody seems to take notes, and they’re almost always gathered around a whiteboard, or a big TV screen. Apparently they put a visualisation of the team’s work up on that screen; some teams reckon this visualisation is really critical and think carefully about how to do it well, while others seem to be much more slapdash about it. One of the senior tech managers told me that the teams that take these visualisations more seriously seem to work much better than the rest, both internally and with the rest of the organisation. I wondered why they don’t just make all the teams follow best practice, but there seems to be an ideological reason behind these very different attitudes.

Curious, I chatted to a guy from one of these ‘better’ teams. He gave me a run-through of what’s on their big screen, which is called an ‘Agile Board’. It’s a 2-dimensional grid, basically. There’s a whole bunch of columns, which show you how work is progressing. I asked how they choose the columns, and was told it varies from team-to-team, but that one way to think about it is you first need the steps to get work ready for the developers to start, and then you need the steps for the coding itself, and the testing, until it’s all delivered to the customer. Makes sense.

I told them that in our business unit we don’t have any of that. But perhaps we should – we’re often in a bit of a mess ourselves, truth be told. Our managers try to prioritise our work, but it just seems to create more noise rather than helping. “That’s why we use these Agile Boards – to make it really clear what everyone should be working on” said my tech friend.

So I went and had a closer look at these boards. They’re not just divided into columns, they have rows (called ‘swimlanes’) as well – this seems to be a key part of how they sort out what their real priorities are. One of their key concerns is to make sure people get stuff properly finished before picking up something new (they have some some techniques to help this) – a bit of that discipline would help in my area for sure.

I’m not saying we’re bad or lazy workers, mind – often it’s our bosses’ fault, since they cancel or change work after we’ve already started on it, wasting a ton of time. We should be a lot stricter about what work gets started and what doesn’t. My tech friend said his team have an excellent way of doing exactly this, which they call a ‘triaging process’.

The more we talked about these boards, the more interesting they seemed. The tech guys reckon that work spends most of its life just sitting around, waiting, rather than being acted upon, and if you highlight and clamp down on these waiting periods, you become a more effective team overnight. This really is starting to sound like “working smarter, not harder”.

I’m gonna have to have a think about how to apply some of this thinking to my own team. Apparently recruitment are using a similar system to track the state of their hires, so it’s definitely not just for techies!”

To be continued (as more articles are added)…

Meetings – how to do the damn things properly

On By JPIn MeetingsLeave a comment

It is not for nothing that a large percentage of office humour focuses on… the meeting.

They take up a huge chunk of our time (Scrum meetings can take up to a third of a development team’s working hours, especially if sprints are short), are synchronous and therefore highly disruptive events (unlike IM or email, which are comms channels you can choose to ignore for a while and answer when it suits you), and are often appalling wastes of time and money.

All activities in a delivery pipeline are subject to a cost-benefit analysis. Calculating the cost of a meeting is the easy part – just remember that, as here, the cost is man-hours, not hours. So a one hour meeting of 10 people didn’t cost the business one single hour, it cost 10 man-hours, which is more than a full day for one person. And of course, that’s just the time in the meeting itself; depending on your office’s setup, there was travel time to and from the room as an additional cost, plus the extra time it takes to get back in the zone of whatever you were doing when you are finally back at your desk – multiplied by everyone in the meeting.

The benefit of a meeting is trickier to assess; it’s completely contextual, and must usually be evaluated qualitatively.

We all know that many (most?) of our meetings would not come out well on such a calculation. In principle, any activity with a net cost is waste and should cease. Yet few organisations will respond to such an obvious imperative by simply cancelling wasteful meetings – these events are too culturally ingrained for that, and for many people form the main justification for their salary.

The best response therefore is to outline and follow a set of rules for making meeting times maximally productive. These rules are no secret, and were widely known and taught many, many decades ago – yet it is astonishing how often they are ignored, entirely or in part, and as a result people’s time is tossed straight on the scrapheap. What follows is a quick review of How To Do Meetings Properly.

Every meeting needs an owner. This is the person responsible for making sure all of the other points listed below happen, either by doing them personally, or ensuring that someone else does them. If you’re ever in a meeting and you don’t get a 100% clear answer to the question I often ask first thing – “whose meeting is this?” – that meeting is probably a waste of time and you should consider leaving immediately.

Every meeting needs an agenda. It can be short bullet points. It could even be one bullet point. That agenda tells you what is to be discussed, in what order, and why, and should be put into the meeting invite. Thus every invitee knows right from the start the answers to the questions “what is the objective of this meeting, and why is my presence required?”. I tell my colleagues (who are often technical people who loathe all meetings on principle) that if a meeting doesn’t have an adequate agenda, they don’t have to go. Simples.

The attendee list should be the smallest group of people who can achieve the meeting’s objectives. Sometimes you have to bite the bullet and accept the enormous cost of a large meeting, but very often there are far too many people at meetings. The whole thing becomes a bloated affair, hard to arrange (there aren’t many rooms for a ton of people, or many times they’re all free), hard to run, and often with multiple attendees disengaged and resentful. Scrum makes all this maximally bad, by insisting that the majority of regular meets are whole team meetings, with no latitude or room for experiment or common sense. There is a colossal amount of waste doing things that way.

Someone needs to chair the meeting when it happens (to keep things moving, make it clear where you’ve got to in the agenda, keep time, ensure the right people are talking at the right moments etc), and someone needs to take notes. Both of these are usually done by the meeting owner. If it’s not my meeting, I usually ask right at the start who is chairing and who is taking such notes. It’s a bad day when you don’t get 100% clear answers.

The chair of the meeting needs to start wrapping up before you all get kicked out of the room, and best practice is to review the meeting notes together on a shared screen to check they are correct. This is vital as the meeting notes will become…

…the meeting minutes. This is a written record, as brief as you can make them without losing important information, of who attended, what was discussed, (more importantly) what was agreed, and (most importantly) what the next actions are, and who is responsible for each action. It is (or should be) every Project Manager’s mantra that an action is only an action when it has i) a thing to do and ii) someone to do it – an unowned action is close to worthless. Any follow-up meetings are identified as actions in themselves (since someone has to arrange them).

The minutes are emailed around as soon as possible after the meeting, to the attendees and anyone else relevant. That email should call out a deadline for a response; if no response is received within the time, the minutes are deemed to have been accepted as the true and definitive record of the meeting/decisions/actions.

And that’s it. All of this – the elementary, universal basics of running efficient meetings – should be both completely uncontroversial, and unnecessary to repeat. And yet time and time again I find that many people in organisations of all types and sizes don’t do some – or perhaps even any – of them.

It is a sadly common occurrence to be delving into the root of some problem or confusion and to find that people have entirely different accounts of what happened and what was agreed at a relevant meeting. “Someone send me the minutes of that meeting”, I challenge, all too often it is then sheepishly that there aren’t any. This lack of discipline is simply unacceptable – we are all responsible adults after all.

So now we know – once more, I’m sure we knew it already – what it takes to run a decent meeting. We should still look to reduce their length, frequency, and attendee count to the minimum; after all, the modern office offers many alternatives to the formal meeting – informal chats, email, IM etc. But if you’re going to do meetings (and let’s face it, we are all going to spend a lot of our lives in them), we should at least make an effort to do them well.

I leave the last word on the matter to the true expert, Dilbert.

 

Stand-ups: the Scrum way is the wrong way

On By JPIn Meetings, Scrum1 Comment

The Daily Stand-up, or Daily Scrum, is a short meeting that almost always takes place in the first half of the morning, usually 10-30 minutes long (the Scrum Guide dictates a quarter-hour).

I like them. They are really important. But any good idea can be messed up by poor implementation, so in this article I will talk about how Scrum says you should do Stand-ups, and some improved variants on that.

First, the name of the meeting. Scrum certainly didn’t invent the idea of a quick daily catch-up meeting, so the term “Daily Scrum” is somewhat presumptuous. The most common alternative name, “Daily Stand-up” has a different problem; it derives from the idea that attendees should be made deliberately uncomfortable by enforcing a standing posture in order to keep the meeting short.

dilbert-standups

Now of course all meetings should be kept as short as reasonably possible while still covering the necessary. But making people stand up is a terrible way to drive this; discomfort is just as likely to make it harder to concentrate or encourage people to arrive late or not at all. In general, the chairing and facilitation skills needed to run good sit-down meetings are more than sufficient for this meeting – adding discomfort doesn’t improve anything. Personally I have no objection to people standing up if they all want to, but it shouldn’t be mandatory and the meeting shouldn’t really be named thus. The optimal name for this meeting is perhaps “Daily Catch-up”, but most companies seem to call it a Stand-up, and to avoid confusion so shall I.

stand-up

Stand-ups almost always happen around the board that represents the team’s work, whether this is in software or physical (usually post-its on a whiteboard). Interestingly, such boards are not mentioned at all in the Scrum Guide, an astonishing fact which I will discuss elsewhere. So although these boards are literally not any formal part of Scrum, they are a critically important element of managing complex teamwork, and it is entirely correct that they are the focus of the Stand-up. Indeed I see the principal function of the Stand-up as being to ensure that The Team Board is correct, and that the whole team agrees it is correct, at least once per day, and tons of other Good Stuff flows from that.

Now there are two basic ways to structure a discussion about finding the optimal fit between a bunch of people (the attending team) and a bunch of work (represented on the board). These are:

  1. people-focussed
  2. work-focussed

The Scrum Stand-up format advocates the first, and this is the wrong choice. What exactly does Scrum tell you to do? You should go round the team, person by person, and each answers the Magic 3 Questions:

Q1: what did I do yesterday?
Q2: what will I do today?
Q3: do I see any impediments?

By the time everyone’s spoken, this format guarantees that you know what everyone is planning to do – there can be no slacking! But it does not of course guarantee that everyone is working on the right stuff; it is entirely possibly in principle and in practice for everyone in a team to have said what they’ll be busy on, but for nobody at all to be working on the Most Important Thing(s). What a waste of a meeting if so. Now a perfect alignment of individual work proposals to team priorities may have come out of the ensuing conversations – I sure hope it did, anyway – but the Scrum format does not focus on that desirable outcome.

The alternative is to make The Team Board the focus of the meeting, and fit people to work in priority order. A well-set up board makes priority order obvious, so you start with the single highest prio piece of work, and ask who’s working on it, to do what exactly, and whether they need any help. A super-short summary of what is agreed gets noted down (when I run these meetings I do this summary real-time within the board software, with everyone watching and double-checking, and it takes an acceptably trivial amount of time to do so).

You then move on to the second-most important bit of work. Then the third. And so on, till everyone has their day’s work identified to the team’s satisfaction. You might keep going a little bit after that to look at what coming up next, or you might end the meeting at that point. Now everyone knows what they’re doing today, everyone is working in priority order, and The Team Board Tells The Complete Truth – Job Done, successful meeting over.

time-out-gesture

This is supposed to be a short meeting, so you have to keep things flowing. When a discussion breaks out in a Stand-up, the team will often let it run for a short time (30 or 60 seconds) to see if it comes to a swift resolution. If not, someone in the team should signal “time out” using the international gesture above (and everyone in the team should be empowered to do this, not just the person running the meeting), and then it’s someone’s job (usually the person running the meeting) to note down who needs to discuss exactly what at a later point in time (often, immediately after the Stand-up). Thus the Action Points / Minutes of a Stand-up are, unlike other meetings, a combination of a) an updated Board and b) a series of discussions whose need has been identified during the Stand-up.

This alternative format avoids forcing people to try to remember what they did yesterday (most people can’t remember what they were doing 10 minutes ago, it doesn’t mean they’re bad colleagues). It asks the sensible question of “do you need any help?”, not some ridiculous question about “impediments”, and most importantly you know for sure and certain that everyone is working on the most important thing they can do. This is guaranteed by the structure of the meeting, and is far, far, far more important to business outcomes than structuring your meeting to ensure nobody is being lazy.

So the golden rules of successful Stand-ups turn out to be:

  • walk the The Team Board in priority order (meaning of course that you have to know how to set up a board)
  • fit people to the work, not vice versa
  • update the board in real time without destroying the flow of the meeting (perfectly possible)
  • keep things flowing with the time-out gesture
  • stop when everyone’s got the day’s work agreed, possibly plus a little look into tomorrow

You can judge the health of a team pretty quickly by the state of their board and their Stand-ups; getting both right is critical. Judging a board is an art in itself, which I will write about separately. But pretty much anyone can observe and judge a meeting; look for the quality of communication and decisions, body language, efficient use of time, what is written down and how, and whether the objectives of the meeting are met quickly and efficiently.

I would encourage anyone interested in a team and/or its deliverables to attend Stand-up(s). Watching people programme or test is often pretty dull (it’s the same as ‘watching people type’), so the Stand-up is the closest you can get to Walking The Line in a factory setting, and your quickest route to assessing the beating heart of a team. Try it – you may well be surprised by what you find, for good or for bad 🙂