If a Project is Going Well, Does it Matter if it's Agile?

I recently watched a talk where a 75% complete project was held up as an example of a software project going well, something we could all learn from and model. The team was happy and the client was as well. Sounds great!

Some points that the team made in describing the project:

• The development started after a discovery project of a few months
• Hundreds of stories were detailed before work started
• Hundreds of features were mocked up and connected in a clickable prototype after discovery
• Burndown looks like a model burndown chart with relatively few new stories being added
• Delivering builds regularly to a staging environment for testing
• Will be deployed to production at the end of the project
• On time, on budget

The team is performing Scrum sprints and ceremonies like backlog grooming and retrospectives and is happy with how things are going so far.

Is this an Agile project?

This is quite clearly not an Agile project despite the fact that the team is using some of concepts from Scrum.

A long discovery phase is virtually identical to a planning phase of a waterfall project. This is quite definitely big upfront design and a long period of time with no value delivered. Similarly, going to production at or near the end of a project is also a very clear indicator of a Waterfall-style project.

The team may likely be getting value out of the Scrum ceremonies and increments, but they appear to be primarily used to break up the work into sizeable chunks, not focused on delivering incremental value and facilitating learning and adapting to change.

Does that matter?

Well I don’t think it matters in the sense that Agile equals good and Waterfal equals bad. There are projects that succeed within both approaches, but I do believe that there is a stark difference in how these approaches view success and how they attempt to maximize the likelihood of achieving it.

At surface value, if we limit ourselves to think in terms of project-based measurements — scope, budget, and time, a Waterfall project could certainly be a shining example of success. Limiting change will help the project to succeed — meaning deliver the initial plan on time and on budget.

If the client and team are happy, isn’t it a success? For everyone involved, it may feel like that is the case.

Things get a little more complicated, though, when we ask ourselves if those are at all the right measurements to be focusing on.

How should we measure success?

If we step back a bit from the project itself and look at its purpose, a successful project or feature will typically deliver on a positive outcome for the business — increasing user satisfaction, attracting customers, increasing revenue, reducing costs, etc. Delivering the project is not the goal, the effect on the business is.

Now let’s say a lengthy project is on schedule, budget, and the timeline looks good. Will it achieve the business goal once it is delivered?

I’d argue that a Waterfall approach cannot begin to answer that question for problems with any amount of complexity. To be fair, it doesn’t even try. The bet is that the original plan should work, and progress is measured by looking at the amount of work completed against that plan. With a Waterfall approach we can’t know the answers to this question until the project is over.

How many systems are delivered on time, on budget, that didn’t really solve the right problem effectively? Did they find out at the end of the project?

A product-thinking approach would consider that too late. If we can get honest feedback that would change our direction, why shouldn’t we learn that as early as possible? So if we shift our mindset away from scope, schedule, and budget and try to focus more on achieving outcomes, our picture of progress and success changes entirely. We want to deliver something simple early, get feedback, and adjust our course if our experiments aren’t driving the behaviour we expected.

A key difference is that we not only welcome change, we make sure the channel is wide open as early as possible and we are listening. Our bet is actually against our initial plan and we want to know why it isn’t optimal as early as possible.

For me, a few core ideas have shaped what I value and how I prefer to work with a team:

Continuous discovery

Up front work of detailing stories and prototyping hundreds of features feels like waste.

From experience with Agile projects, we know that good discovery and story writing practices facilitate parallel work and a large amount of upfront work creates a bottleneck that delays delivery of an MVP of a product or feature. A story isn’t meant to be detailed way in advance, but is intended to be a placeholder for future collaboration when the time is right.

Delivery and research can happen at the same time. Deferring defining far away work helps us to avoid wasting time researching and designing features that may never be built, but most importantly moves collaboration and decision-making to a point in the future where the team will understand the problem much better than they did before the project had started. When a team collaborates on just-in-time design, they can bring more valuable insight and experience to the discussion, leveraging the knowledge gained from the problems they’ve already solved together.

While I advocate against overly detailed up-front story creation, I do value collaborating early on a product vision and high-level plan for an MVP. One of the best tools that I’ve found to do this is using a story map to collaborate on the vision and clearly communicate the initial understanding of the product.

Continuous Discovery | Silicon Valley Product Group

Essential XP: Card, Conversation, Confirmation

User Story Mapping - Jeff Patton & Associates

Focusing on outcomes

With a project that is planned upfront, the focus turns to delivering features. When code is written and works as we planned it, it’s considered done. 75/100 features delivered feels like 75% done.

A project not yet in production has not yet delivered value to the customer. A project that is 75% complete but not in the hands of real users has delivered 0% value. No one can use it. And as a result, there is no feedback to learn from. Without feedback or measurements from real usage, we cannot be sure that the product is delivering on the outcomes it was meant to until we’ve done all the work, so we can’t take that feedback and learn and adapt our behaviour. We also can’t effectively prioritize or know what really is the most important thing to do next. Everything is a guess originating from our initial plan.

A better alternative is to focus on delivering value and outcomes. With product-thinking, we build a simple version of the feature, get it in the hands of real users, and then measure to see its it is achieving the desired effect. We test, learn, and adapt with each experiment. If it’s not working, we adust our plan.

Product Thinking vs. Project Thinking | by Kyle Evans | Product Coalition

In an outcome-based approach, our focus is on really, really, actually solving the problem for our customer, not just on shipping an attempt, marking a story as complete, and moving on.

Continuous delivery

When we start focusing more on outcomes, continuous delivery helps us make that possible.

So, in an outcome-based approach we want to focus on shipping small releases frequently and facilitating a feedback loop to evaluate each change. Modern tooling is geared toward enabling teams to continuously deliver and better understand our users’ behaviour. CI/CD pipelines allow us to build, test, and deploy our changes more frequently, and analytics and monitoring tools enable us to have insight into how our products are being used to drive our decision making and continually adapt our plan to better drive outcomes.

What is Continuous Delivery? - Continuous Delivery

It’s no coincidence that the research presented in the book Accelerate found that frequency of delivering was one of the clearest differentiators of high-performing team vs low-performing ones.

Accelerate book

Conclusion

To me, the mantra of on time, on budget misses the mark and I cringe whenever someone speaks to this as the mark of a project well done or something to aspire to.

While a Waterfall style project may go great, achieve business outcomes, and be by all accounts a success, it’s just not a strategy that is repeatable because of what it measures and optimizes for during implementation.

I believe that focusing the delivery approach on outcomes, delivering value early and frequently, setting up early feedback loops, and welcoming and adapting to change to increase the odds of succeeding at building the right thing and any attempt to create a more repeatable approach should consider this. Cheers 🍻

Hi. I'm  Mark Thiessen. I love technology, jiu-jitsu, and coffee. My opinions change over time.
I'm passionate about working with teams to learn to continuously deliver software and help ensure the valuable things are delivered incrementally and measured and improved.