Agile: Our Highest Priority
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. - Agile Manifesto
It's Primary
In addition to be listed first this principle implicitly states that it is the most important. In many ways all the other principles hang on this primary principle. While this principle seems almost obvious, there is a lot of depth to actually following all that is packed into this single sentence.
Satisfy the Customer
What does it mean to satisfy the customer? It can mean building things the customer has asked for. But I believe there is a lot more than that. Often the customer doesn't know what will satisfy them until they have seen it. For example, several years ago I was building a brand new product and started out by doing generative research via interviewing our target customer - K12 classroom teachers. When we showed them our wireframe prototype, many of them indicated they wanted a way to personalize the information being presented. However, when we actually tested this idea we found that exactly zero of them took the time to do that, favoring instead to use the predefined information. The lesson? Teachers like the idea of customization but do not have time in their day-to-day to actually do it.
The point is determining what will satisfy the customer is hard. You can even ask them and still get the wrong answer. This is why the next point in this principle becomes imperative if you are going to actually succeed in satisfying your customer.
Early and Continuous Delivery
In case you haven't discovered this, yet, building something that users actually love is hard. In fact, one of the reasons I fell in love with Agile is that I got tired of building feature after feature that nobody used. When I switched from developing software to running an innovation lab, I quickly discovered that most of my ideas turned out to be bad despite how much I loved them and thought they would work. It didn't take too many failures before I realized we had to reduce the cost of finding bad ideas.
The way to do fail fast is to share your work even before you are comfortable doing so. We built up muscle memory for boldly putting our ideas out into the world as fast as we could so we didn't waste any more time than necessary on bad ideas. There are numerous tactics for doing Lean Experimentation, but probably my two favorite examples are Wizard of Oz and Concierge.
Wizard of Oz Example
We ran a 5 day design sprint in partnership with one of our suppliers around the concept of a library voice assistant (Alexa for the Library). When we got to day 4 where we were supposed to build the prototype, the question became how do we create a voice assistant in one day that was just real enough for librarians to react to it. We ended up using a very simple chat type interface where the user could input questions and get responses. The responses were very limited and often dead ended with "I'm a prototype and don't know the answer to that question."
To add the speech-to-text we turned to actual intelligence (AI). We used Zoom on a phone and shared the prototype chat screen. Behind the green curtain, our wizard would listen to the questions and choose the right response from the list of options they had. This worked so well, that we had to tell the librarians how we were doing it at the end of each session because they were so excited about it.
The point is, we were able to test the concept of a voice assistant with a prototype built in less than a day. We discovered that the librarians mostly felt threatened by it, some were creeped out, and a few saw the potential for students using it when they didn't feel comfortable asking a human.
领英推荐
Concierge Example
Our innovation lab did find good ideas in addition to lots of bad ones. One of those good ideas was book clubs for classroom teachers. You may be familiar with book clubs if you attended public school in the USA. The idea is that the teacher sends home flyers with their students. The students can purchase books which are delivered to the classroom and the teacher gets a portion of the proceeds which they can use to purchase books or other supplies.
We did a lot of generative research and had weekly show-and-tells with teachers early on using rapid prototyping tools. When we had enough confidence to build software, we built the minimal features necessary to run one book club. This meant that a lot of the integrations to backend systems were not there. We weren't connected to inventory, ordering, billing, fulfillment, etc. Basically we had a way for students and their parents to see the books they could choose from (which was hard-coded) and a way to order those books. We used PayPal to process credit cards rather than the company's in-house processing tools.
When it came time to deliver the order, we walked down to the warehouse and asked them to pick the books for us. We boxed them up along with some stickers, bookmarks, etc. Then we got on a plane and hand delivered the box to the classroom along with some goodies to really celebrate book day.
We learned a LOT of valuable lessons without spending the additional 6 months or so that it would end up taking to integrate with all the backend systems that would automate much of the work.
Valuable Software
What makes software valuable? In the use cases above we had specific questions or assumptions we were testing that we believed answered those questions. For example:
The point is, just delivering software early doesn't mean it's valuable. A term I've come to love that describes this is "outcomes over outputs." We want our software to change the user's behavior in some way that aligns with our business goals. We use leading indicators to determine this.
In the case of book clubs, a leading indicator was parents visiting the book club site. It's early enough in the funnel for us to get data very quickly as we experimented.
I've come to realize that a feature is not really "done" until you've deployed it AND gathered leading metrics on the affect of that software. I've seen development groups focus on things like velocity, but their definition of done is delivery the software to production (or worse, delivering it to a QA environment). Until it is live and you actually gather data to determine if it did what you hoped, is it really done? Personally, I don't think so.
I hope you made it all the way through my lengthy ramblings about the first Agile principle. Please leave your comments. I'm curious what other's think about the Agile principles and if you agree or disagree with my interpretation.
I highly recommend Outcomes over Outputs by Josh Selden. It's a quick 1-2 hour read and will change your thinking.