The “Tim” story

I had the chance to work on a discovery sprint recently. During this two-week sprint, I revisited a bunch of agile delivery fundamentals in a way I haven’t in a long time. The project was suffering from some of the great, classic mistakes of software delivery we all know and love such as working in silos, internal politics, inability to deliver anything into production, finger pointing, comments like “we tried agile and it didn’t work” and so on.

Our discovery sprint team started using an example we called the “Tim” story. Tim is one of the executives in charge of the project.

After doing twenty user interviews, looking at code and reading a business case and other artificacts, one of our findings was the project was using a waterfall approach to manage a project with complex business rules, an ERP system. The team would talk about insufficient requirements and failing tests. Everyone was blaming each other.

Our recommendation was for Tim to be migrated out of the old system into the simpliest version of the new system that could be deployed to production. Because the team were working in silos, they had accomplished a great deal in their own silo but nothing worked together thus zero business value had been delivered in two years of working on the project.

Tim would receive his paycheck from the new system and if that failed, he could receive a handwritten paper check, bugs would be fixed and we’d try again two weeks later. Because Tim as an employee is one of the simplest payroll scenarios, the salaried employee with no special circumstances, we described this to the team as “the happy path”. Once Tim was being successfully paid by the new system, the entire management team working on parts of this project would be migrated. This is a way to deliver small iterative value while also demonstrating how committed the executives and team members are to the effort.

Now, a lot needs to happen before Tim can get his first paycheck. The system needs to be deployed to production, how a single employee is migrated from the old system to the new system needs to be understood, there needs to be confidence in the basic security of the production system and more.

As additional groups are migrated, the complexity will increase. For example, an employee that is working two different jobs with overtime and several dependents. They split their paycheck into several bank accounts and had previously worked at the company, quit and has now returned to their old job.

The team should take these complex use cases that the new system needs to support, focus on them as a team one-by-one and see success. They should continue in this “continuous improvement” phase of the project as new groups of employees are onboarded.

Contrast

Now, contrast the “Tim” story with the project team’s current way of working. For over two years the team has been assembling a complex list of never-ending requirements aspiring to a place where “we have all the requirements” (unrealistic) and “we have confidence the system works for all HR and payroll complexities” (impossible) and “then we can do a big bang cutover to the new system” (dangerous).

When our discovery sprint team talked about the happy path versus waterfall big bang approach in our readout it resonated with the whole team. You saw head nods from non-technical folks, agreement and understanding from Tim and validation from others saying things like “We tried 5 test cases six months ago and they all failed but they were our most complex payroll scenarios involving overtime pay, employees working two jobs and more. We never thought to start simple. This totally makes sense.”

In past products I’ve worked on, I’d tell a very similar story about “how we can take the first $1.” Executives would often scoff at this and talk about how we need to support millons of dollars of revenue and get inpatient. However, it’s powerful. Understanding the first simple flow, the happy path, the MVP, etc is still a great thing to lean on if you are trying to help unstick a giant enterprise project or working on your next small startup.