Agile project life cycle: the long tail

Today let’s complete the Agile project life cycle blog series by looking at how you can maintain your love for your clients and code, even after the project is over (a.k.a. the long tail).

The end is in sight. Or not.

So your team is reaching the end of the project, and it’s all gone swimmingly: sprint goals achieved, bugs fixed, no stories left open, acceptance criteria ticked off – yeah right!

Even in the most disciplined and high functioning teams, there is a little tidy-up to be done to push things over the line. In some cases, an entire backlog of issues remains, as the focus has been on building features rather than dealing with bedding these features in. This can create a nightmare for ongoing support, once the project is ‘finished’ – this is often referred to as ‘the long tail’.

Finding and fixing software problems after delivery is often 100 times more expensive than finding and fixing it during earlier phases.

Of course, if your team isn’t supporting this long term, then sure, throw that crappy code over the fence to your client’s team, or a third party. Or even better, just ignore support altogether and hope it goes away (this is my favourite. I call it the ‘Ghost Team’ – during the project you’re fully committed and there, but a day later and it’s like you disappeared). This is quite common, even in this day and age of ‘BAU’ being literally business as usual. This gives development a bad name, and uses so much of businesses’ budgets, just to keep things running smoothly. Just think of all of the great new features we could be building with that money instead. I know it’s not the sexy part – bug fixing, writing unit tests or automated test suites, or writing great documentation –  but neither is doing your laundry or brushing your teeth. But if you don’t do it, things start to get smelly pretty quickly, and your mum ain’t here to pick up after you. So let’s talk about some practical ways you can stop throwing crap over the fence and start being proud of the entire engagement you have with your clients.

Plan it before you get there

Firstly, the key to good BAU support is planning it before you get there. If you don’t already do it, get into the habit of adding this into your project plan at the beginning of the project. Yes, even Agile projects have a project plan, just not a low-level horrible gantt. You need to map out timings for thing like load testing, PEN testing, and content loading, so make sure you have this sorted early. Part of this is answering the question of who is going to maintain this site after the project is over, and how.

How we handle the long-tail

At SilverStripe, we have an awesome operations teams (Ops) who look after our clients, as well as our partners’ clients on our platform. Any SilverStripe site can be hosted on our platform, and that comes with so many cool support features, but that’s another story. They support the infrastructure and security components of the sites they care for, which is something that often gets forgotten. With over 500 security patches coming through AWS every year, are you applying these to all of your clients’ codebases? Maybe. Maybe not.

Our project teams plan a handover to Ops teams anywhere up to a month before the project ends to make sure they have a chance to understand the site, the client’s needs, and the tricky parts. Hopefully, the documentation speaks for itself, but if not, the Ops teams will push back until it does. The client is introduced to our Service Delivery Manager (Hi Matt!) and he explains the process of raising issues or enhancements through our helpdesk.

Then there is the custom code – the project codebase itself. If there is a major issue found after a month, who is going to down tools and fix it? Most smaller agencies do fix the issues, but it plays havoc with the current project work they are knee deep in. Again, if the code is not stinky before it’s in support, this helps lessen the impact of interrupting the next project. We also have the option for our clients or partners to purchase Code Care – our custom code support.

For many years we didn’t have a operations team and our project teams supported every project they ever delivered. It was very difficult after a team had delivered so many over the years. Someone was always fixing some legacy code. We finally came to the decision to create the team and we have never looked back. I know this isn’t possible for every agency, but feel free to use ours if you want to.

Some tips

If you are going to continue to support your project long term (but have no dedicated Ops team), there are some ways we’ve found that can help soften the blow of supporting clients while still working on project work:

• Segment someone in the team to work on support for that week/sprint so the others can concentrate on the project
• Include a deeper level of automated tests (unit and functional) so that knowing when something break is easier
• Book time between projects to cover a bunch of lower level support to clear out the backlog
• Bundle issues together to create mini-projects for clients to resolve any issues in one go

None of these take the impact away completely but it eased the pressure somewhat.

Something you can proactively do as a team is to reduce the number of features in progress, in particular in the final sprints. It is easy to book out each week with great new things, but forget about ensuring the previous features are in good condition. I like the 60/20/20 rule for each sprint – 60% new features, 20% fixing anything from previous or current sprint, and 20% to cover any architectural changes or refactoring. Refactoring is a healthy and expected thing, so do not think of this as a dirty word, or hide it from your client. It’s all part of us doing our best work – things evolve.

Another key thing is to think of your clients not on a project-by-project basis, but as an ongoing strategic partnership, with iterative development happening on their site. Adding value for users is a continuous task, and hopefully you consider the initial project as a baseline to leap off from, rather than the end. If this is the case, you can ensure your team has great quality practices to keep the code in a maintainable and loosely coupled state. I have seen some amazing system diagrams on the wall that has each area of a site mapped out, with stickies all over it as to the current state. They even have a ‘smell’ stickie that shows where things are getting a bit bloated or potentially unstable – if it gets smelly enough then some refactoring is scheduled in. It keeps the whole system healthy and visible to everyone.

Ultimately, systems still get old, projects still get bloated, priorities change, we forget and people move on. In this instance, documentation is the winner on the day when something happens. Knowing where to find it, having it up to date from whoever touched it last, and tests that pass based on this documentation is the difference between a quickly resolved P1 issue and a nightmare.

Final question

I challenge you to ask yourselves this question:  ‘If you were going to be given a code base to support going forward, how would you like it to be handed to you, and in what condition?.’ If you expect certain things, then so do others receiving your code for BAU. Keep it in mind all throughout your project, and hopefully the long tail of issues won’t keep biting you in the ass!