When creating a plan—whether it be a big project release plan or a smaller two-weeks’ timebox plan—you essentially need to know three things:
Tasks —What are the requirements? What do you need to do?
Size — How big are these tasks compared with one another? How long will these take to complete?
Priorities — Which tasks need to be done first because others depend on them? Which tasks are most important regardless of dependencies?
It’s very much like creating a recipe: assemble the right ingredients, measure them to the correct proportions, and then mix them together in the right order.
In an Agile project the prioritisation of tasks is done by the business. It is their project after all; they have the most information about value, they understand the market, they have an idea of what features should be delivered next. Prioritisation is not a decision to be made by the development team.
The size of each task, however, is something that the development team is qualified to estimate. If I want a new wall built in my garden whose estimate should I trust more: mine (the person who commissions the work) or the builders (who do this job day-in, day-out for a living)?
When planning, we use a tool called planning poker to help estimate the relative size of tasks.
One of the biggest challenges we faced when we started down the Agile path was how to accommodate working on multiple projects concurrently. This is a little insight into how we are currently managing ourselves across two projects plus business as usual tasks.
The Agile ideal
Most Agile/XP/Scrum literature assumes a single, cross-functional team working on a single project for a single customer using a narrow range of technical disciplines. The primary reason for this is that task-switching is really expensive: it is much more efficient to remain focused on one project.
That way of working, though attractive, is more or less impossible in our situation; something that I’ve also heard from other university digital teams. We don’t just work on projects, we have business as usual commitments (which include meetings, support calls, personal development, blogging, editorial calendar updates, etc.), consultancy (where we work on approved institutional-priority projects managed by other teams) and portfolio mechanics (board meetings and related admin, writing up project ideas and terms of reference documents, etc.).
After all that excitement has been deducted from our working week, we are generally left with only about 40% of our time to dedicate to pushing projects towards completion. We therefore need to be careful to extract as much value as we can.
Over the last year, as we’ve been formally trying to work in a more agile way, one of the biggest challenges I’ve faced as a project manager is resource management. In other words,
How do we know how much time each team member has to work on projects?
When we’re planning the next sprint, how do we track how much work has been assigned to a team member, so that they have neither too little nor too much work.
Agile planning in theory
In theory, Agile planning should be pretty straight forward.
Imagine we have a team of five developers, each with 6 hours available for work each day. That gives us 30 hours per day, and assuming 9 days of project work (with one full day set aside for retrospective and planning) then within each two weeks sprint we should be able to dedicate 270 hours to development work.
During the planning session then, with the business having prioritised the work to be done next, it’s up to the development team to estimate the size of tasks and stack these up in a backlog. We know that we should aim for around 270 hours of work (or perhaps a little less, maybe 265 hours, to create some slack — breathing room to make provision for some tasks running on a bit longer than anticipated).
Moving through the sprint, developers pull work to themselves and gradually over the fortnight all 265 hours of work is completed.
Within a few sprints the team begins to establish a velocity—the average amount of work that can be comfortably completed. This really helps to plan further ahead as the team becomes both more predictable and reliable.
One of the principles behind the Agile development method we use is that “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” (Source: Principles behind the Agile manifesto)
This is about continuous improvement. It’s about slowly but surely getting better at what we do. It’s about recognising that our processes are not perfect, that we are not perfect, but that together we will slowly work to improve things.
The Japanese have a word for this: kaizen (改善), which means “change for better”.
We run two-week sprints: from Monday to Thursday on week one, and again Monday to Thursday on week two. A portion of Friday is kept clear each week for support and maintenance, but the larger part of the second Friday is devoted to planning in the afternoon, following a sprint retrospective in the morning.
The retrospective is always facilitated by someone; so far, it’s always been me.
Step 1. Ground rules
Before the retrospective, as a team we collectively look over our Trello board (where we track our projects) to look at what work we completed during the sprint, and evaluate whether we successfully met our sprint goals or not.
This allows us to go into the retrospective with a clearer picture of what happened. So much happens during a sprint that it can be hard to remember what we did two weeks ago.
Then we set the ground rules for this session and all agree to the following:
We will stick to 1 hour.
We will be honest.
We will accept everyone’s opinion without judgment.
We will try to not interrupt.
We will talk from our own perspective, and not speak for anyone else.
We will not make jokes about other people in the room.
We will not check mobile phones, email, etc during the retrospective.
As part of setting the stage for the retrospective, I read out what is known as Norm Kerth’s ‘prime directive’, and ask everyone to verbally agree to it.
The prime directive, which was written by software consultant Norm Kerth, sounds quite Star Trek-y, but it’s not quite as geeky as that. Its purpose is really to help ensure that teams have the right culture of openness and honesty.
This is what I read out:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Step 2: Brainstorming
For the next 20 minutes — though it’s usually shorter — armed with a stack of Post-It® notes and a Sharpie® each (other sticky notes and pens are available), we individually reflect on the last sprint and brainstorm ideas that fall under the following headings, which I put up on a whiteboard:
Step 3: Mute mapping
Having filled the whiteboard with a colourful patchwork of ideas, the first thing I do is read out each idea. We now hear what everyone has written. Sometimes this prompts new ideas; these get added to the board.
I then set a timer for 10 minutes during which we silently group all the cards into categories. There are three rules:
Put related ideas close together.
Put unrelated ideas far apart.
It’s a surprisingly effective technique.
Once done, I take a whiteboard pen and draw circles around each group of sticky notes and we give collectively decide on a label, e.g. content strategy, social, tech, tools, training, time management, etc.
Step 4: Vote
Having categorised the ideas, each member votes on which categories should be improved during the next sprint.
I hand out five magnets to each member of the team. Participants can use them as they like, depending on how strongly they feel about the issues raised. They may put all five magnets on one category, or one magnet each on five categories, or somewhere in between.
Step 5. Retrospective objective
There should now be a clear winner.
Or sometimes three.
We clear the board of all the other categories and discuss which category or categories we should focus on during the next sprint, and brainstorm ideas to finally agree on specific actions to improve how we work.
These objectives then become actionable tasks during the next sprint. Sometimes we might add something to our process, or else we might remove something. Either way the idea is to make things go better.
Sometimes it’s obvious and the actions that come out of it are pretty simple to fix. During the first retrospective, for example, almost the entire team identified that their PCs had too little memory for the work they were expected to do with it. Simple fix: order more memory. The total cost was about £200 but as our PCs now start up a little faster and don’t grind to a halt while trying to multi-task or open enormous graphics files we must already have recouped that cost through increased productivity.
Daily stand-ups are too long
Another example. It was identified during one retrospective that our daily stand-up meetings were taking too long. There are only seven of us so they shouldn’t be taking any longer than 15 minutes maximum, if you stick to the guide of two minutes per person plus two minutes.
The retrospective objective for the next sprint was simply this: use a timer for stand-up meetings. A simple solution and it proved very effective.
We ran timers every day for the following two sprints and now we don’t need one: daily stand-up meetings are now as short as they should be, and any extra chat is left to the end and optional.
Ad hoc requests
Sometimes the answer isn’t quite so straight forward. A noticeable frustration was noted during our last retrospective about ad hoc requests that land on our desks from time to time. There had been a surprising number during that past sprint.
On the surface it looked like they all fell outwith our general team objectives. But as we discussed them more fully it became clear that only one did. What initially seemed like an enormous mountain of a problem turned out simply to a simple conversation to have with someone.
The real value in retrospectives
This is where the real value of holding regular retrospectives becomes apparent for me. These often small niggles, if left unaddressed, can prove to be destructive in the long term. Not only do they affect productivity but they can also destroy team morale.
How long had people been grumbling about their PCs being slow? Six months? A year? Longer? One this was identified it took 10 days to resolve.
If our stand-up meetings had continued to run for 30 or 40 minutes then that too would have had a detrimental affect on the team. Not just that it eats into development time it may have led to some team members not sharing valuable information for fear that the meeting went on too long. And as we all know from Master Yoda, fear leads to anger, anger leads to hate, and hate leads to suffering.
Collectively unpacked what was behind those ad hoc requests, I felt, gave us a real clarity about the different types of requests we get, how to evaluate whether we take them on straight away or not, and how to deal with them.
In identifying that all it required was a conversation, it gave us an opportunity to build bridges and educate rather than defensively close doors.
At the end of this week we’ll sit down for another retrospective. I don’t know yet what we’ll discover, but I do know that it will be valuable and another step towards us becoming a better team.
Originally published on the University of St Andrews web team blog.
The photograph above, taken a couple of months ago, shows the planning board in our office — an information radiator — that shows us at a glance how many tasks are left to do, what’s currently being worked on, what’s in testing, what’s done and (unlike, I would guess, most other Agile boards) what we’re waiting for.