You’ve been assigned to “rescue” a project. In your first stand-up, the team shuffle into a semicircle, fold their arms and lean insouciantly on the wall of the featureless war room. Only the senior developer looks at you — once — then rolls his eyes.
Everyone in the room knows they’re on the problem/stalled/death-march project. As project or delivery manager, you are merely the latest wave of febrile enthusiasm appointed by management to throw yourself onto its implacable rocks.
Where do you go?
There’s several ways to play this. You can go all drill-sergeant, glare down the baleful looks, bark out orders and fire out Jira tickets. You can meekly apologise for your presence and blame the client, management or ‘the situation’, until such time as the project is canned.
Or you can try to make a difference, persuading a dysfunctional team to work together again.
You might not pull it off. It might deprive you of sleep, your hair colour, or your nails if you’re prone to biting them.
But if you succeed you will have not just rescued a project and earned the right to write up your experience on Medium, you will have made the working life of each member of the team more tolerable. And given yourself the confidence to do it again.
Now for the bad news: I don’t have a magic formula for rescuing failed projects or for energising and motivating new or existing teams. But I know what has worked for me in the past.
First, you have to sort out the hygiene factors. Is the Jira board a mess, with no clear priorities, full of scrappy tickets that say little more than “fix this because it’s broken”? Tear it down and start again. Set up the project properly. I use a backlog of user stories with acceptance criteria, story points, etc. If the team aren’t familiar with this or whatever method you are using, teach them. I wrote my team an “Agile / Jira Guide” for reference as and when they needed. It’s their Jira board. They own it once a sprint has started so they need to know how, and why, it works.
When it comes to planning sprints, involve every team member and encourage discussion. Don’t give them a ready-made plan and ask for feedback. Instead, co-develop the plan with them, so it’s theirs.
In doing so, you’ll tease out a lot of the blockers to progress. The team is the solution; there isn’t a solution apart from them.
Next you have to demonstrate your value to the team. That doesn’t come from issuing orders (or tickets). It comes from serving the team.
What’s a problem for them? Let’s say it’s an overly attentive client (for which read ‘interfering’). Then your role is to hold the metaphorical umbrella and catch the client’s rain so the team members can get on with their jobs.
My scrum master training really helped with this. The team are the experts; they know where the project is going. The project or delivery manager’s job is to keep it on track and remove any impediment to their progress.
Indispensable project managers are an impediment. Aim to set it up properly and render yourself more or less useless. You know you’re doing the job well if you could disappear for two weeks and the project would keep going (which also means you can take a holiday. Remember holidays?)
Then give the team some identity. This has to happen organically. You can’t impose it like some Butlins Redcoat delivering organised fun. Let it evolve.
Again, there isn’t a formula for success, but here’s an example:
For the past few months I’ve been working on a fairly trying B2B banking application suite; a programme made up of lots of small projects to overhaul the interface. It’s not the kind of work which would inspire our team of talented UX/designers over the long term.
Soon after we set up, we acquired / pestered our office manager for a camouflage net with which to decorate our project space because the word “net” features so much in what we do. From that grew ‘the jungle’: the camo net sparked imagination and we started to use the jungle as an extended metaphor for the work we were doing. Images (and sounds) of animals appeared in internal presentations. The team went ape (fnar).
None of this happens quickly. So how do you sustain it over time? A key component in our team has been the hiring and onboarding process.
Personality and cultural fit is paramount to the team. Whenever a new person is required we all meet them and afterwards get to vote on them. It’s like selecting a new housemate. You — hopefully — won’t be seeing them in their jimjams, but you will see them every week day for as long as the project lasts, so you’d better get along.
And, in case you were wondering, yes, members who joined the team last week get the same vote on a new addition as a core member who has been on the team since inception.
Sense of humour is a good indicator: if you take yourself too seriously, you probably won’t fit. Our peer reviews can be quite loud. In fact they used to get quite heated, but we’ve learned to listen to each other.
We sit together, not heads down with headphones on, but chatting to each other. We’re a rowdy team. We don’t leave people to manage on their own. To get emotional about it, we look out for each other; we look after each other.
In a previous project, where I inherited two disparate teams, I sat the iOS and Android developers across the table from each other, so they could learn from each other. When one got stuck the other team had often tackled a similar problem and could help them out. I also encouraged friendly rivalry. “Burn Wars” were very effective i.e. which team has the best burn down rate that sprint? They were full on Agile / Jira nerds by the end, I believe, because they finally had ownership of the project.
Similarly, in my current team you don’t hand over work, you share it. That’s not just a semantic nicety: when you’re ready, you shout out for someone to review your work. It increases the quality of the finished product as well as the quality of life for those working in the project.
So to recap, whether it’s a new team full of fizz, or you’ve been ‘volunteered’ to manage the battle-weary on a death-march, start with the hygiene factors; prove your worth; develop a team identity; and encourage humour and playfulness.
If after four weeks, they fire you and you’re scouring the contracting boards, please don’t blame me.
If you succeed, glory in the knowledge that you have improved the lives of your team members. They will be better partners/parents/pet-owners as a result. Share your experiences with your peers. Then go on to the next project and do it again.