Closing out agile projects

I’m working with a couple of agile projects teams at the moment and helping them think about what needs to be done to finish up their work.

There isn’t a huge amount of material out there on closing agile projects out (I Googled) so I thought it might be useful to write this piece. I got some additional links via Twitter friends.

There is more material out there about closing waterfall projects out and some of this is useful to the agile world. I’ve included some references at the end of this article.

Why do a closeout?

It’s important to do an effective close for several reasons

• It can help ensure that everyone is as happy as can be with the work done — enabling everyone to know where things stand
• It helps draw a line under the work & lets people move on emotionally
• It increases the impact of the team’s work by, e.g. communicating and sharing it more effectively
• It helps individuals from the team and those working to support the team do better next time
• It helps anyone picking up the team’s deliverables or ways of working

Handover

I’m speaking here specifically about non-software teams, although most of this is applicable to the software world. (There’s a fundamental debate about whether software development should even be organised as projects and I’m not going to get into that here. See the #noprojects hashtag for more.)

The deliverables of a non-software project are often things like documents, slide decks, videos, user research outcomes / user needs, changed content, data repositories etc.

As the organisation has invested time & money to generate these assets it’s important that they are retained and disseminated to those that need them.

Show & Tell meetings are a way of spreading the word at a very high level and Slack, Drive, Confluence and other modern collaboration tools can also be used to store & share project deliverables and project knowledge. You may also be able to find someone to continue to own some of the assets after closeout.

It can also be useful to create a single master document outlining the materials produced by the project and how they have been organised and to store the master document with the materials.

[Edit 23/May/24 Design Histories and Project Stories can be a good way of capturing important information as the project proceeds — also makes handover easier as you have already done the hard work of collating important project information.

Learning Lessons

If you’ve been working in an agile way you’ll have reflected regularly on how the team was doing and may have already identified blockers and potential improvements beyond the team. Take time now to hand these onto those responsible for making such improvements.

Think about the following:

• Over the course of the project what were the important lessons learned about how the team worked?
• How effective were you at working in an agile way? How might you have organised yourself differently?
• What could you improve in the environment around the delivery team — e.g. IT provisioning, project governance, your team space , were stakeholders engaged?
• If you used suppliers, how did they do? Did you spend money wisely? Would you use them again? Should your organisation use them again?
• What was your own personal contribution? Take time to celebrate your own successes. Solicit feedback from others on your strengths & what you might take forward for your next piece of work.

Some activities that can help here:

• Timeline Retrospective — mapping out the important events across the life of the project. Helps teams remember the highs & lows of the project but also to remind them of just how much they’ve achieved.
• Getting Input from Busy People — useful technique for gathering data when people are pressed for time (as they often are towards the end of a project)

I’m also a big fan of taking plenty of photographs of the team walls and the team in action to help them remember their work. Share these with the team before they disappear off.

Loose Ends

Some loose ends that may be forgotten but are actually important:

• Let your Show&Tell or other invitee lists know that you’re done
• Clean down your task board and team area — my friend Chris Morgan was always keen on the Boy Scout Rule — leave your ‘campsite’ in better shape than when you arrived there
• Decommission any services that are no longer needed and return any borrowed equipment
• Make sure suppliers, contractors etc. get paid and get feedback; Close off any purchase orders after all invoices raised

Some ideas on how to do a poor closeout

I like to turn things around and think about how not to solve a problem, so, here are some ideas for doing the worst closeout possible.

• Leave no time for closeout activities — it becomes all rush, panic and recriminations
• Have people focus on close out rather than finish delivering — leads to a great closeout but an unfinished project
• Focus on box-ticking rather than having a valuable closeout — you can have some completed forms rather than customer satisfaction as a memento
• Move people off the project before closeout
• Keep people on the project but also have them start several other projects
• Don’t handover documents, code etc.
• Leave suppliers unpaid — as you collect your bonus and head off on your post-project vacation
• Leave your wall in place, your desks untidy and some old socks in a drawer — the next team that uses your space will love your work
• Curate your deliverables in a system that’s only accessible to your team, in a locked room, in a different building
• Don’t share any user research outputs you have — I’m sure they won’t benefit other teams anyway
• Leave without telling people you’ve left — I’m positive nobody wanted a final word with you
• Quibble with your customer / supplier over whether the work is done — it’ll make a great story in years to come
• Fail to thank those around the delivery team who helped in your success — I’m sure they’ll welcome you back for your next project
• Don’t celebrate — in fact moan about everything that went wrong and everyone who annoyed you, everybody likes to hear disaster stories
• Be unrealistic about how the work went or what it achieved — was it really the best project the organisation has ever done?

Saying Thanks

Receiving recognition for a job well done is important, as is giving it. Too often people leave the organisation or are moved onto other work without any recognition for their efforts.

If I’m Delivery Managing a team I’ll often create a ‘Wall of Praise’ as part of the team’s working space and ask them each week to thank someone — not just someone in the team — for something specific they’ve done.

Project closeout is a good opportunity to generate more of these thank yous, especially if you have not been doing them regularly over the course of your work.

If the Wall of Praise isn’t your thing then giving people LinkedIn recommendations or references my be more suitable

And with that I’d like to thank some Twitter friends for their support in writing this article…

Further Reading Material

How to break up with your team — Cara Bermingham

Some thoughts on Project ‘closure’ — The Agile Pirate

Agile Project Closure — Steven Thomas

and some material you can adapt from the Waterfall world…

(Worth noting that Waterfall projects often focus on getting sign-off at the end of the work, whereas agile projects work with stakeholders at every iteration to get a steer in the right direction.)

The top 4 items that should be on your project closure checklist — Project Management Tips

Stop Ignoring Project Close Out — Robert Gordon Seller

The Seven activities of project closeout — Guy L. de Furia <- included for its list of problems during the closeout phase

7 tips for project closure — PM Partners

Finally

Let me know if this article helped your project closeouts be more successful.

Please recommend this article if you found it useful.

Follow me on Twitter @markdalgarno or subscribe here for future articles.