Agile Projects: The People Side

This was first published on the Cabinet Office website.

We talk a lot about agile here at GDS. We use agile methodologies to focus on our users. The faster we can build a functioning product, the sooner we can get it in front of real users and start iterating based on their feedback.

This has a number of implications for how we organise our projects and manage our people, and I wanted to explain how that affects they way we work.

Multi-disciplinary teams

In practice, we group our people into small, multi-disciplinary product teams. These teams will work closely throughout the day, often meeting first thing for a stand-up, a very quick recap of previous day’s work and a round up of what they have planned. If an area grows too large we break it out into smaller teams again — no one wants to be in a stand-up of 30+ people!

A typical product team will have a product manager (defining the vision for the product and how it will meet user needs), a delivery manager (agile project manager with a focus on making things happen), a technical architect and then a mix of developers, designers, web ops and content designers. We also have folks focused on understanding our users, including customer insight, user research and product analytics.

Transition team stand up

Matching people and projects

We have chosen to organise all of our “makers” into a flexible pool called the Delivery Team which currently has over 70 people. As requests for skills come into this team, we look at what is needed and then match to someone with the right skills and interest in that area.

We want everyone to have challenging, rewarding work, using their current skills well and stretching them to develop further in their chosen specialism (or in a new area if they desire).

Since we may well move people from one team to another based on the needs of the project, we deliberately keep line management separate from project assignment. Some worried that this would be confusing but in practice it has worked well. Each individual can turn to their delivery manager for project specifics and has their line manager as sounding board and for career, personal development and similar topics.

Harmonising not standardising

Over the past few months we’ve also tried to do things in a similar way across products where it makes sense. For instance, having the same sprint timings makes it easier to move people from product to product; encouraging all our delivery managers to use terminology in a consistent way has also helped us to communicate better.

Don’t do it all by yourself (you can’t)

At the moment we have a number of product teams all running in parallel to build GOV.UK as well as a number of other projects.

In order to meet all the short term demand, we have added to our core staffing with a number of contractors from a range of small and medium sized businesses. They’re working on projects with very specific time-limits, and they’ve help make make sure our core staff have the flexibility & agility to respond to changing needs. They’ve also brought us some external perspectives and practices, which have been helping us to meet user needs in the best way possible.

Using the Best Plan Format

The most frequent mistake I see in Project Planning is what I call “premature Gantting” — going straight to creating a huge Gantt chart (often in MS Project).

Why is this a mistake? Because a huge Gantt chart, with many lines of tasks, all precisely allocated to specific dates looks very authoritative. It gives the impression that you’ve spent hours working out the exact dependencies, estimating the length of tasks and precisely scheduling all the work that needs to be done and who needs to do it.

If you truly have done all that work, then perhaps you’re fine. But the reality is that most of us have ACTUALLY spent half an hour scribbling on the back of an envelope, or at best on a flip-chart, to get some rough stages and some key dates. All the detail was then made up when the Gantt chart was created, primarily because the software demanded it.

What’s the solution? Let the format of your plan reflect the stage of development that it is at. Internally, I will frequently go into a meeting and DRAW the plan stages on the whiteboard. For communication with the customers/stakeholders, I’ll create a simple plan (sometimes even a flowchart) that reflects the reality of the situation.

So far, everyone involved has appreciated the honesty — and it’s prevented projects going wrong at a very early stage in the game.

Management By Optimism

Parkinson’s Law says that “work expands to fill the time available”. If you don’t have much to do, it doesn’t inspire productivity. If you have loads to do, it often inspires procrastination, but I digress.

Today, however, I want to address the corollary to this. Some people seem to believe that since work expands to fill available time, work will also CONTRACT to fit the available time. It usually plays out like this:

Project Team Member: Getting the environment set up took two weeks longer than anticipated, so now we don’t have enough time to test. I think we need to move the go-live date.
Project Manager: No, no, I’m sure you’ll manage it.
Project Team Member: As I said, I think compressing the testing down to just 2 days is a serious mistake. We’d be risking the whole project!
Project Manager: Listen, I’m sure you understand this is a really important project. We MUST make that date. You’ll just have to make it work.

This, my friends, is Management By Optimism. It is probably the most dangerous management trend in evidence today. When you see it, start to worry, because it is probably the biggest threat to your projects and to your careers.

Management BY Optimism is very different to being optimistic. Being optimistic is seeing the cup as half-full — trying to think the best rather than the worst in a given situation. Management By Optimism, on the other hand, is about IGNORING potential failure. Just because the impact of a particular risk is severe, the risk is regarded as extremely unlikely. Rather than facing the problem and dealing with it, it is ignored until a catastrophic point is reached — or until the relevant manager can jump ship and blame the sinking on the crew.

So what can you do if you worry that Management By Optimism will scupper your project? Well, firstly, look out for the signs. Failing to consider real risks, reacting adversely to the suggestion that the plan or schedule is unrealistic are both big warning signs. Secondly, try to address the problem in a constructive way. Sometimes we all delude ourselves into thinking things are better than they are. Holding a team risk-assessment meeting can help — just get everyone to rate how severe and how likely they think a risk is. It will quickly become apparent if the team cannot envision a successful outcome when the leader is dead-set upon it (and vice versa).

Or, if there is no other option, bring in the big guns — take it as an issue to the Project Board and make clear that there are real concerns about the chances of success. Much as “it’s going to be late/over budget/under quality” is unlikely to be POPULAR news, any senior manager worth their paycheck should realise that early warning is significantly better than unanticipated failure.

Do you have some examples of Management By Optimism and perhaps other ways to combat it? Share in the comments!

Solving Problems Isn’t Hard

Solving problems isn’t hard. Once you know what you’re trying to achieve, then for most problems you can see a few ways to get there, so it just comes down to choosing the best course of action and following through.

Problem definition, on the other hand, can be damn hard.

When you’re facing some problem and it’s driving you crazy, sometimes you’re best to stop and wonder whether you’ve really defined the problem accurately. What are you trying to solve? What is the original problem? Why is it such a problem? How else could you frame it? What description would make it more tractable?

If you can get the problem definition right, your chances of finding an optimal solution are greatly improved. Don’t keep soldiering on down the wrong path, refusing to acknowledge that failure is also an option.

Starting Out in Project Management

Although I won’t do a full repeat of my talk at BarCampLondon2, today I wanted to talk a little bit about starting out in Project Management. Most folks don’t start their career as a project manager … they come to it later, having been in an operational role or part of a project team first.

One of the difficulties for a first-time project manager is that being a great project resource (i.e. team member) is what gets you the job as project manager, nine times out of ten. Unfortunately, the characteristics of a great project resource are not necessarily the same as those of a great project manager. Standing out in a project team is about getting more done than your fellow team-mates, knuckling down and “getting on with it”. By definition, this focuses you on the executional level of the project — getting tasks done, once they’ve been assigned to you.

In contrast, being a great project manager requires excellence at all the OTHER parts of the project — planning, communication, dealing with stakeholders, managing risk, seeing the “big picture” and so on. There’s also a big part of project management which is more about management than about the project — your team will function best if they are left in peace to do their work and move the project forward, so making sure they don’t NEED to worry about all those factors is paramount.

In traditional project management, there are a number of stages: Initiation, Planning, Execution, Control and Closure. The crux of my talk last weekend was that the real success or failure of a project is determined in the Initiation, Planning and Closure stages, whereas most of the focus is traditionally on the Execution & Control phases. This is not to say that these are the most time-consuming phases — nor that the Execution & Control are not important! — just that they are the structure that allows for success .. or not.

In my experience, some of the most typical mistakes first-time project managers make are in these stages:

  • INITIATION — not making sure everyone is 100% clear and aligned on the purpose of the project. Realising this later on when the software “doesn’t do what we wanted it to do” or when the savings/value promised are not delivered is much more costly.
  • PLANNING — thinking that the plan, once written down (as thousands of lines in MS Project) will be followed to the letter. Plans are not robust. Task planning is especially fragile. If you spend your time worrying about the fact that task #137 is only 70% complete, then you’re not keeping your eye on the rest of the project.
  • CLOSURE — if you think your project is finished and others don’t, then you have big problems. There are a number of reasons this can happen (probably fodder for another blog post), but the most frequent are either that you haven’t met everyone’s real objectives for the project (see above) or that you haven’t provided for the future of the area you’ve been working on. This leads to the “undead stakeholder” phenomenon that seemed to strike a chord with everyone I mention it to.

So, what can you do if you’re managing a project for the first time? Or even if you’ve already managed your first project and weren’t happy with the results? There are a few things you can do:

  1. Educate yourself. Even though Project Management may not seem as real or worthwhile as development or design, it is still a valid skillset and there is a lot of information out there, notably some great books.
  2. Think back. When you were working on projects, who were the best project managers? Who do you remember fondly? Who do you definitely NOT want to emulate? Learn from their mistakes and adopt their best practices.
  3. Ask around. There are probably other young PMs in your organisation. Maybe you could even meet up and swap horror stories.

UPDATE: I’ve since written a book aimed at those just getting started in project management — have a look at The Principles of Project Management.