Agile Projects: The People Side

Published Updated Meri Leadership, Management, Project Management

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.

Avoiding the Watermelon Phenomenon

Meri Management

“If you can not measure it, you can not improve it.” – Lord Kelvin

My recent experience using The Eatery got me thinking about how much having the right measures helps you track and influence performance. Data is awesome and measures are great — nothing focuses the mind more than a graphical representation of how broken something is.

Unfortunately mistakes are often made:

  • Picking what CAN be measured, rather than what SHOULD be measured. For example, airlines are reputed to determine an “on time” departure based on whether the plane left the stand on time — not when it actually took off. As a customer who has spent a lot of time sitting on the runway, this is pretty annoying!
  • Focusing exclusively on the measure, rather than what it tells you about performance. We’ve all seen a team get obsessed about getting a particular measure to “green” or “100%”, often not really thinking about what the impact will be of doing so. Sometimes it’s fine to have 87% — and the incremental work to get to 100% is time & effort better spent on something else.
  • Losing track of the bigger picture. My personal peeve here is measuring whether everyone in the organisation has an annual review (because that’s something easy to measure) rather than whether they actually make a difference — the folks over at Sonar 6 have covered this in one of their colour papers on performance management very effectively.

All this can lead to what one of my colleagues refers to as the Watermelon Phenomenon — when something is green on the outside, but bright red on the inside. Effectively, your measures are telling you everything is fantastic, but your users/customers/employees are telling you it is B R O K E N.

So, what to do?

  1. Think about what REALLY tells you whether your business/process/organisation is healthy. Is it sales? Is it customer service? Retention rates? Happiness? How on earth do you measure HAPPINESS? Don’t worry about that right now. Just think about what you think are your key indicators of success/health, in an ideal world.
  2. Now, what could show you AFTER the fact how you are doing? These are called “outcome measures” or “blackbox measures” and are typically hard numbers — sales, profit, retention, etc. The disadvantage is they are often broad and reported after the fact — but they are still important.
  3. Then, think about what your early warning measures might be. In people management, how many people you are attracting (recruitment) and keeping happy & engaged (retaining) are your outcome measures … but how do you tell BEFORE someone goes as far as leaving that you have a problem? Is it an employee health survey, the team’s feelings about their manager, how much your competitors are paying? Working this out and then finding a way to measure it without losing track of the end result, is probably the hardest challenge.

What’s the worst measure you’ve ever seen, in terms of the behaviour it drove?

Deadline First, Plan Second

Published Updated Meri Management, Project Management

I’ve just invented a new acronym (yeah, yeah, I know, like the world NEEDED another acronym, right?!): DFPS (Deadline First, Plan Second).

Deadline First, Plan Second describes the all-too-common phenomenon of project deadlines being set before any of the planning and estimating has been done. We’ve all been involved in or heard of such a project — the kind precipitated by a big announcement that The Next Big Thing (TM) will be delivered by March 1. Post announcement, a team is pulled together tasked with actually making it happen.

This throws many good project management practices straight out the window. It doesn’t matter if you do a proper plan, involve the team in estimating and figure out that the project will REALLY take 9 months instead of 5. The announcement has already been made — pointing out that it’s unrealistic is only going to get you accused of not being a team player. Alternatively, your management may view it as a crafty way of getting more money or people. So you may go in trying to convince them that it’s not going to happen and come out with twice the money, but you’re still signed up to an impossible deadline.

The good news? People who pull deadlines out of the air often don’t really understand the intricacies and complexities of your project. Duh, right? If they understood, they wouldn’t be setting impossible deadlines! Although this may sound like I’m just hammering home bad news, there is a flip side to this coin. If the deadlines are arbitrarily set, they are quite unlikely to have a detailed understanding of the scope of the project.

Reality is that you can probably negotiate your way through on all the other project variables – cost, quality & scope – you just need to accept that someone high up has nailed their future to a deadline and so now that is set in stone. So long as there’s a big “we did it” announcement on March 1, the definition of “it” is probably fairly fluid.

My advice? If you blatantly need more money or people, go the “it’s impossible” route at first. Get some extra resource thrown at you. Then, very helpfully, start preparing plans of what actually IS achievable for a Mar 1 go-live. Aim low at first — your project board or management team are going to be horrified at how little you’re saying can be done, so they’ll want to argue you up to more stuff. But be very aware of where your limits lie. Plan to under-promise and over-deliver. Give them something that works, but doesn’t sing, dance & play the ukulele. By then they may well realise they don’t need all the singing and dancing anyway!

PS If you’ve been keen to find a way to introduce a new approach, like Scrum then a DFPS situation might be just the leverage you need. Worth a try!

Scale and Consistency

Meri Management, Productivity

One of the things that becomes a problem as your company (or product or service) expands is how to ensure a consistent experience across the board. Whether it’s that you’re operating in multiple countries or just spread across multiple servers, quality of experience can start to vary, not just for your customers but also for your employees.

This is why in huge companies, “procedure” can come to dominate. You want to make sure that all your employees get equal access to career progression, training, personal development. So you mandate that all your people managers follow certain procedures — annual reviews, work plans, etc etc. You want to make sure that anyone who calls customer service receives pleasant, friendly and above all useful service. In an attempt to standardise quality, you give people scripts, mandate that phones must be answered within a certain number of rings, and so on.

Many of us have felt the impact of these kind of procedures — the call centre guy who can’t wait to get you off the phone, because a “successful” call must be finished in less than 3 minutes; the manager who sits you down for a stale, scripted “career discussion” that makes you feel more like leaving the company than going for that next job or promotion.

My theory? These procedures are written in with the best will in the world. The need to write them down is the problem however — the “spirit” gets lost. People become slaves to the letter of the rules.

Have you seen this happen? Ever seen it combated in an effective way?

Geek Project Management @ Refresh Edinburgh

Published Updated Meri Conferences, Management, Presentations

I’ve just done my talk on Geek Project Management at today’s Refresh Edinburgh event. It seemed to be fairly well received (fingers crossed anyway!). Some of the content was pretty similar to my BarCampLondon2 presentation, but I’ve done a fairly significant rework on it so I think it’ll be a lot easier to take away some immediately useful tools.

If you’re interested in seeing the slides, then here you can find them in Powerpoint and PDF form.

Tags: , , , , , , .

Busy != Productive

Published Updated Meri Management, Productivity

The people I really respect are those who can get mountains of work done and deliver amazing results … and still have a life.

It’s really easy to mistake “busyness” for productivity. The folks always rushing around, having meetings and complaining about how busy they are certainly LOOK like they’re doing a lot. But the reality is that effort and output are not always related. Productivity is about getting loads done — how you spend your time should be up to you.

Some busy people are also productive; some productive people are also busy. There are times when you’ll see me running around like a maniac, juggling half a dozen projects and priorities. But if you measure (and therefore reward) “busyness” as opposed to results, then you won’t get what you want. You’ll get an army of employees who are too busy to talk to each other and potentially on the verge of nervous breakdowns, who actually don’t achieve very much.

Measure results. Measure the outcomes, not the actions. Don’t reward someone for working night-and-day on a task, reward them for producing the deliverable at the end. Reward the person who gets the same work done in less time MORE than the person who is missioning for days and days. That way, you’ll encourage your team to be more productive, rather than just busier. They’ll find their own ways to improve the way they work and the entire team will benefit as a result.

Management By Optimism

Published Updated Meri Leadership, Management, Project Management

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

Meri Leadership, Management, Problem Solving, Productivity

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.