Finishing an 8 year sprint – how we used Lean and Agile methodologies for our very own “Phoenix Project”

Almost all of our work involves building scrum teams for established IT companies, however, when we are asked to help struggling teams or new entrepreneurs we like to assist when we can. We often offer pro bono work to startups, coaching lean development, and we help older teams transition to scrum and adopt more modern development methodologies.

Last year we were approached to help a UK company finish a project they’d started eight years earlier. They had their own team and they thought they just needed help introducing scrum. It’s not the type of work we usually do, as they had their own development team, but when they told us they hadn’t even launched the software and desperately needed help we stepped in to see what we could do.

Eight years ago our client had a great idea for a product, they developed an MVP and then, before launching it, decided they couldn’t sell it without feature X so they delayed the launch, then they decided they needed feature Y, then feature Z and so the cycle continued. Many developers passed through the code and it got more and more complicated as more and more features were added. And, as expected, as the complexity increased exponentially, more maintenance work was required just to keep it all working and to tie everything together, the result … a hugely complex impressive piece of software with more features than you can imagine, but with no users and with too many bugs to release. And to compound the problems, as it had no test coverage and was so complicated it was almost impossible to test in its entirety. Our client had tried to finish it for years but just couldn’t and needed someone to get it over the line.

When we develop for our clients we always try to follow a lean development approach where the product roadmap is defined by user feedback rather than intuition. However it is often difficult for entrepreneurs to grasp this approach and, consequently, many people we’ve worked with over the years have fallen into the anti-lean trap where they believe that their intuition is king. As a result, many have delayed launching their idea until they had “finished” their product rather than getting into the hands of users as soon as they could. And as expected, on launching they’ve often found that what they thought people had wanted wasn’t reality.

In our first year, we fell into the same trap. We built an iPhone walking app that we dubbed “Google Maps for the countryside on an iPhone 4” . It worked amazingly well but our whole business model was wrong and it earnt less than 100€ in 2 years. We’d developed what we thought people wanted rather than asking them. A simple smoke test or RAT could have saved us thousands.

So, when we were approached to help this UK client finish off the project they’d started eight years ago we knew it would be a challenge, not only technically, but also on a personal level, as lean development was not something the owner knew about.

Step 1 – agree a “definition of done”. When we started working, if we had been truly lean we’d have stopped all development on day one, smoke tested the idea and based on the results decided the next steps. However, persuading someone to potentially abandon a project they’d been working on for almost a decade is difficult emotionally, so we met halfway and, with them, designed an MVP. “Finishing” the project would take years so we agreed on the minimum functionality we needed.

Step 2 – decide how to run the project. Traditionally they’d sent tasks via chat and then organised priorities by the daily needs and ideas of the owner. Without clear sprint goals this had led to the system growing without a clear direction. We introduced a basic workflow in Jira and began transitioning the team (and the owner) to scrum. Showing a product owner the impact of introducing tickets mid sprint to a burndown chart is a powerful tool.

Step 3 – organise the backlog. With over one thousand tasks in the backlog, many of which were totally obsolete, we set about isolating the tasks needed for the MVP. We wanted to scrap the whole backlog but that was out of the question so we created a frontlog and moved the relevant tickets across.

Step 4 – start the MVP sprint. Initially we created the sprint based on the relevant bugs and unfinished functionality tickets in the frontlog, however it was soon apparent that for one thing to work, something else (not in the sprint) had to be created or fixed. After a month no noticeable progress had been made. Our client was more frustrated than ever and the development team saw no light at the end of the tunnel.

Step 5 – redefine the MVP. After many difficult conversations with our client who just wanted everything to work we agreed on perfecting eleven workflows. Enough functionality for him to demo and launch a very basic version of his product. We needed a clearer “definition of done” so we created very detailed user stories and user acceptance criteria and the team regrouped with a new reachable goal.

Step 6 – product launch. Eight weeks and 150 tickets later we pressed the “complete sprint” button in Jira. We had an MVP that worked flawlessly in the agreed eleven workflows. 

Our client is now actively selling the product.

Whilst I have hugely oversimplified the process and effort required to get this project over the line. The core principle is that we only succeeded because we religiously followed Lean and Scrum. By setting a very clear definition of done and not being afraid to say “no”, our scrum master was able to deliver a product that our client had not been able to finish for almost a decade.

There is still a long way to go with many months of work required to “finish” the software in its current state but at least we have a platform to work on from now. 

We use Scrum every day on every project at Secret Source. The way we do it varies depending on the needs of each project. This project was a real test for the resilience of scrum as a project methodology and was a real test of our abilities. This was our real-life Phoenix Project.

If you’re interested in how we run our projects, need some help with Scrum or Lean development or to understand how we’ve built our happiness first culture please  just get in touch or follow us on LinkedIn to get our regular blog updates.