Most people think of Agile as the ability to make changes mid-project. It seems like in most people’s minds that means changing their mind about the aesthetics of a project before the project is even life. That’s not necessarily what Agile is about. While Agile definitely welcomes change, it’s a little more involved than that.
Let’s take a look at the first 3 principles from the Agile Manifesto, by the Agile Alliance.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
When you read these 3 principles carefully, you realize that Agile welcomes change with a purpose not just for the sake of changing something. It also focuses on early deliverables of valuable software. These are important words that should not be overlooked.
Far too often, I witness designers and marketers fall into the trap of making changes based on their own assumptions, and not based on actual feedback. Falling into this trap can delay getting your software into the hands of users that can give you real feedback.
So yes, Agile is all about welcoming change, but ONLY for the customer’s competitive advantage, and ONLY when delivering working software.
When you look at the 12 principles of the Agile Manifesto as a whole, you realize that being Agile is about strategy, not just being able to change requirements late in development.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Agile Manifesto, by the Agile Alliance.
Agile means being able to adapt quickly to a business change. And to adapt in a way that gives us a competitive advantage. It means that business & dev work hand-in-hand. And it means that the team becomes more efficient with every interval of deliverables.
A pandemic recently forced us to adapt
At Photon Software, we recently launched a new service offering. We did it because we realized that for us to survive long term, not just past this pandemic, we had to pivot. Part of that pivot was an end-to-end data & analytics service we call Spectra.
Spectra is a great example of the benefits of Agile because within one month we went through 3 different iterations of the product, gathering feedback and making changes to deploy a new version.
Basically, we took the Lean Startup approach, which is a book by Eric Ries that, in my opinion, translates the Agile process into a business lingo that helps middle and upper management understand the value of continuous integration.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Agile Manifesto, by the Agile Alliance.
When we first launched Spectra we designed and built a landing page in 3 days. We are a software company after all, so it was pretty second nature for us. We knew that by having an MVP to show clients we could at least begin to gather feedback on what we thought was a great new service offering!
The way that we positioned Spectra at first was too technical. Customers didn’t see what we were trying to do and it was hard for them to identify the value of the product/service. Our deck & landing page were all about servers, real-time databases, & data structure 🤦🏻♂️.
The feedback that we gathered on that first week was clearly telling us that our offer — the way we were positioning our product — was too developer focused. But we assumed the product itself was perfect. We just had to change the way we were selling it/presenting it. So we did…
Within the second week of being live we deployed a new version of Spectra. This one was simple and easy to understand. It talked less about the tech and more about the benefits and its value. We were happy with this new version.
We shared the new version of Spectra with a new set of clients. We also shared it with a handful of clients that we had shared the previous version with. Then we gathered feedback from everyone once again.
With the second round of feedback we realized that our product needed to change. It was lacking focus — It offered hosting along with analytics and it forced customers to switch hosting providers. It wasn’t clear to our clients whether they were paying for hosting or analytics. And they certainly hated the fact that we forced them to switch providers. This time around customers clearly understood our product, they just didn’t like it.
So we went back to the drawing board. We scrap our hosting offering and focus only on data & analytics — where clients saw the most value. We also allow clients to use the service without forcing them to switch hosting providers. And by removing the hosting offering from Spectra, it allowed us to simplify the pricing structure. Then once again, on week 3, we deploy another version of our product.
Minus a few tweaks that we’ve made since then, the third version of Spectra was very close to the final product. Throughout the third and fourth weeks we buttoned it up. By the time a month had passed we had a finished product with a clear pricing structure and value proposition. And that is the power of Agile and continuous integration.
As a team, we could have easily spent a month planning out and designing the “perfect” product. But it would have been the perfect product only if seen from our lens. From our clients’ perspective, and therefore, from a sales perspective it would have been a failure. At the very least, far from perfect.
By getting an MVP out in the hands of our customers as soon as possible we were able to test our theories before they were fully developed. This may sound irresponsible to some business people. I get it. To be honest, I believe there is a bit of an art to it. It’s not always that simple to describe what an MVP should be.
But I think the important thing to understand about Agile is that it is an infinitely ongoing approach. For example, within the Agile mentality Spectra will never be truly finished. We may get some interesting feedback in the near future that forces us to rethink an existing feature or introduce a new one. In fact, as a team we should strive to continue to gather feedback from current and new clients to learn how we can make Spectra better.
The point of Agile, is that you are constantly changing, pivoting, and self analyzing in order to gain a competitive advantage. And in tech, if you don’t do these things, you die. Plain and simple.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile Manifesto, by the Agile Alliance.
The reason why Spectra was a success story for us is because at the top of our priority, with every single iteration we worked on, was to satisfy a customer’s need. And since we were gathering feedback directly from our customers, with every iteration we got closer and closer to the right product.
A Common Question I Get
How do you handle a different pricing structures with new iterations when you have already sold a previous version to some clients?
A lot of people have asked me this question. The concern is valid. Unfortunately, there is no one correct answer. It will vary per project.
For us, with Spectra, it was easy. Our prices went up with every iteration so we simply honored the price that we offered to our early adopters.
Got Questions? Post them in the comments section below!
Recognitions
Featured photo by İrfan Simsar on Unsplash.
