Main Image

Agile - Fad or Fab?

Prior to Cucumber I had worked in marketing roles at a large NZ company and as such I had been the client of a number of brand, design and digital agencies. Through this role I got to understand what good and not so good client / agency partnerships looked like which gave me an interesting perspective coming over to agency side with Cucumber.

Back then, to me, agile was just a word that meant little more than being able to get up off the floor without needing to hold onto the coffee table.  Fast-forward six years and it is probably one of the more used words in my repertoire. So is Agile just the latest buzz word or is there real value in introducing a framework to increase the speed and quality of delivery?

My view is that Agile is a framework that ensures we first and foremost satisfy the customer through early and continuous delivery of valuable software (or whatever else you are producing). That sounds great. But when a model is essentially built on trust and collaboration, my biggest reservation when Cucumber first transitioned to this way of working with clients over 5 years ago, was how to build that trust with a new client without absolute certainty of price, scope and timing (as you perceive to have with a more traditional waterfall approach).

As I continued to resist this transition, more and more pro-agile rallies were popping up at every conference, blog and water-cooler I frequented. It was time to experiment, I needed to feel what this was like and not just be told about it. So that’s what we did. We built a new Cucumber website where I was the client and we used an Agile approach to do so. Sure it wasn’t perfect, but boy did it feel different!

Through this process there were a few key highlights and surprises for me which may be relevant to note if you are just starting on your Agile journey:

  1. As a team we were focused on talking about the value of specific functionality before talking about how much it would cost. Coming from a world where every slight side-step from the original scope required a change request to be signed off whereby the documentation sometimes took longer than the change, this was beyond refreshing.
  2. What I said I wanted at the start was not what I wanted at all (surprise, surprise). When you interact with technology, it is then that you really get the full experience which is hard to replicate on paper.  Being involved in the process in a meaningful way throughout the creation of the new site meant these changes were fed back into the project without a long ‘change’ phase at the end of delivery.
  3. The whole team was involved in the solution. I don’t think anyone can dispute the value diversity brings in achieving better outcomes and for me this is one of the key benefits of Agile. It is not the sole responsibility of one person to solve problems, suggest alternatives, define the solution throughout delivery – it is the responsibility of the team. As such you have back end developers wading in on design discussions, testers talking about front end development issues and ultimately the client gets a better result for it.

From this first experience to now, our Cucumber approach has matured based on our learning in each development project over the last 5 years. I now understand Agile to be much more than just a framework – it is a mindset and a cultural shift to a whole new way of working that ensures we solve the right problem with the ‘most right’ version of the solution as quickly as possible.

The next challenge for me personally is to experiment with how we utilise this new approach in other areas of the business (outside of development) and use this “iterate and learn” approach in sales, marketing and strategy for the future success of Cucumber. Watch this space.

If you are exploring ways in which to transition to a more agile approach in your organisation and want some help with this; give us a bell, we’ll happily share our skinned knees and key learnings along the way.

leave a comment
2 Comments
  1. Clare

    Hi Maru, great questions. Ultimately I don't think there is a price increase with Agile and I think once clients have been a part of an agile project they understand that perceived certainty with waterfall is really just that - a perception upfront that is not a reflection of where the budget will end up with the inevitable change requests on top. The first time you do this with a client it does require education to understand the principles and why this will enable a better outcome. I don't believe in the no budget school of thought. So we often fix budget (as we know who's involved and how many sprints) and time (i.e. x sprints) and then scope changes throughout the project based on changing needs and amount of work completed. This doesn't always mean scope decreases - it can increase throughout the process. We also recommend the 'Minimal Viable Product' approach to scope and aim to only do what is required to create the right experience and outcome. We start with imperfect knowledge and you can do all the user research and client testing in the world but it is not until the application is being used by real life users at scale that you begin to understand how to optimise this based on interaction so what you think you need is never what you do. Thanks for the questions!

  2. Maru

    Any 'cons' Clare? In the early days, did clients perceive there to be a price increase for the total work over waterfall? Everyone wants an initial ballpark figure, right? What about the advantages/disadvantages to clients of potentially going live with the bare minimum leaving budget for after the new software was in the wild so to speak (i.e. Lean styles)?