As a Agile coach, I refer to a few tools to help me think about where my Scrum teams should go next on their path to Agility. One of these tools is the Agile subway map, a list of Agile practices grouped in different categories. It helps me think how a specific practice could help a team solve its actual problem. In the following picture, we can see how these practices are interconnected while the colors at the bottom indicate each category.
Another tool that I find useful is the list of the most popular Agile techniques surveyed by the annual Agile survey. Each year, VersionOne surveys thousands of organizations to get an overview of Agile adoption across our industry. One data point that I find interesting in this survey is the list of techniques implemented by Agile teams. Just like the Agile subway map, it helps me think about how a technique could help solve an actual problem the team is facing.
Unfortunately, I find there is something wrong with these practices/techniques. They are all based around IT. None of them really address how to do customer development. Customer development, a term coined by Steve Blank, is used to describe the parallel process of building a continuous feedback loop with customers throughout the product development cycle. While the reader could be tempted to consider the “Product Development” line in the Agile subway map above, notice how these practices are all related to the software development team and not the actual customer. Personally, I do not find these practices useful to discover customer behaviors to then engage with them.
Advocates of the Scrum framework would be tempted to mention how the Product Owner role can cover the customer development area. While it is true that Scrum and XP, two of the Agile methods that have stood the test of time, address business themes like value and Return On Investment (ROI), they fall short on guidance as to how these themes should be implemented in software development.
In the last few years, what seems to have gained a lot of attention in the Agile world is frameworks/processes to scale Agile to the enterprise level. The most popular ones seem to be Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD). In my opinion, these are just mechanism to deliver software to the customer. They want to solve the problem of delivering software at the enterprise level but they don’t seem to focus on solving the problem of the customer.
If you simply look at their summarizing high-level view, notice how the customer development, or the “outside the organization” box is missing. Can you find these boxes in the Scaled Agile Framework big picture? I can't. DAD even says on its home page that "The focus of DAD is delivery". The picture below is the DAD high-level view of its hybrid framework. Where is the customer development area in this picture?
I truly believe these are just delivery mechanisms to push features out the door faster.
With Agile, you make more shit. But it’s still shit.
At the 2012 Lean Software and Systems Conference 2012, I remember Jeff Patton saying how “Value is hypothetical. You just don’t know”. In his view, value is a bet. While the Scrum guide states on page 5 that the “Product Owner is responsible for maximizing the value of the product”, I find that Agile has been pretty silent at helping the Product Owner achieving this. At a gathering of Scrum experts last June, I ended up in a session where we discussed how to identify value. The best answers we came up with were techniques like A/B testing, feature toggling and impact mapping. We, ourselves as experts, were having a hard time naming techniques to measure and identify value in products.
Jeff Patton said another interesting thing during his presentation in 2012. He said “With Agile, you make more shit. But it’s still shit”. In other words, Agile has become a software delivery process where we make features faster. But we aren’t solving the problem of the customer. This seems to go in the same direction as Mary and Tom Poppendieck pointed out in their latest book “The Lean Mindset”. In the epilogue, they state how “agile methods often fail to deliver significantly improve business results”. It is now time “to stop thinking about software development as a delivery process and to start thinking of it as a problem-solving process, a creative process.”
Where to look next?
So this leads to an interesting conundrum: “How do I setup a problem-solving process?”. I have to say that I have found some of the answers in the Lean Startup movement. Lean Startup, a methodology first proposed by Eric Ries in 2011, aims at developing businesses and products using the scientific method. As it is gaining popularity, it has attracted the attention of many Agilists.
While I am not saying that we Agilists should switch to the values of Lean Startup, I have found some novel ideas when comparing Agile and Lean Startup techniques. In his blog post “Agile Vs. Lean Startup”, Joshua Kerievsky distill the differences between these techniques. You can also watch his presentation at GOTO conference to get a better understanding of his thoughts on the subject.
One technique that I find appealing is the AARRR metrics, humorously named the “Pirate metrics”. While velocity tells you how much features are going in production, it doesn’t tell you if customers are using these features. In fact, I am not aware of any popular Agile techniques (see Agile subway map or VersionOne survey mentioned above) to help us measure the value of features once deployed in the field. On the other hand, the AARRR metrics offer a very tangible way to measure this. To the reader who is interested to dive into more Lean Startup customer development techniques, I recommend the book “Running Lean”. It presents and describes in detail techniques related to customer development. While we ran short of answers at our Scrum expert meeting last June to measure value, Running Lean offers a breath of techniques like feature fake, scroll heat map and structured customer interviews to work with your customers throughout product development.
Scrum.org is also providing some of the answers through an important initiative it is leading. Named “Evidence Based Management (EBM)”, it sets out on measuring business value metrics. Don McGreal has a great article on how we should set out to measure evidence about the value our customers see in the features we deliver to them.
While I feel that Lean Startup customer development techniques can help Agile deliver value in product development initiatives, I am a bit more skeptical about projects where we rewrite applications. For example, I work in a government town where public government agencies rewrite their existing applications because they are too costly to maintain. As these applications fit into a business process already in place, we find ourselves implementing the same features simply with a newer technology. In this context, I would be less warm at introducing customer development techniques as we are replacing an existing system over an existing business process. On the other hand, if we would extend the system to new platforms (Ex: mobiles and tablets), I would be tempted to include Lean Startup techniques to truly identify and measure what is value to the eyes of the customer.
Compared to Agile methodologies, where I feel we are working forward from the IT team, Lean Startup moves backward from business results that we are trying to achieve. This leads me to an interesting question. As I am an advocate of the “form follows function” principle, should we then design our software delivery process to serve the purpose of customer development? And if so, could fundamental practices like time-boxed iterations and TDD be dropped for the greater good of flow? As A/B testing, a customer development technique, would be used to challenge an existing feature with a new one, could we drop TDD until the right feature is discovered. As Agile is now in its second decade of existence, I am curious to see if the manifesto will survive an industry that is continuously maturing. Time can only tell.