Shifting customer needs are common in today’s marketplace. Businesses must be adaptive and responsive to change while delivering an exceptional customer experience to be competitive. Traditional development and delivery frameworks such as waterfall are often ineffective. In contrast, Scrum is a value-driven agile approach which incorporates adjustments based on regular and repeated customer and stakeholder feedback. And Scrum’s built-in rapid response to change leads to substantial benefits such as fast time-to-market, higher satisfaction, and continuous improvement—which supports innovation and drives competitive advantage.
— Scott M. Graffius, Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions
In the Introductory Series, we talked about the Development process and the fact that there is an Order of Operations to the process. Most importantly, we talked about the fact that the early stages (which involve understanding the Customer) must be done to a high level of quality before any work in the later stages (e.g., writing code). The flow of Development looks like this:
You might notice a few extra tidbits on this diagram. I added the notion of additional ingredients at each stage – for example, the “Build & Test” stage also requires tools, processes and frameworks. I have also reflected that there is normally documentation coming out of each stage.
Recalling that we need to perfect the early stages of the process before moving to the next, it would suggest that processes and tools (especially those that focus primarily on the later stages) are a much lower priority. Based on that assessment, the Scrum methodology and tools that support it (such as Jira or VersionOne) would seem to be something tackled only once you have the Customer needs worked out. But, interestingly, Scrum transcends all phases of the Development process. Because Scrum advocates a rapid iteration through the entire Development Life Cycle (often 2 weeks per iteration), this forces regular Customer feedback. Let’s understand this through an example.
Let’s assume you did a horrendous job of understanding the Customer’s needs and in your first iteration, you produce something absolutely repulsive to the user. Within two weeks, you will get that feedback from the Customer (this is where, ideally, you need the Customer to be the real Customer, not a proxy for the Customer, such as a Product Owner). With this feedback, you tackle Sprint 2 and try again. I suspect that the second version of the product is slightly less repulsive. The rapid iterations create a virtuous cycle of improvement and customer feedback. This is why Scrum is a process that can lead to much better quality of Stages 1, 2 and 3, solely due to its rapid iterations.
Similarly, Lean Startup (one of my favorite books –link) advocates building an MVP (Minimum Viable Product) and getting it in the Customer’s hands as quickly as possible. In that regard, it is very similar to Scrum and leads to the same end result: even if you did an abhorrent job of garnering requirements, successive iterations on the MVP and beyond will result in continuous improvements to the product, as well as a forced understanding of the Customer’s needs.
To be clear, many methodologies and tools don’t achieve this same result. If a methodology does not include regular interaction with the Customer, it is not likely to help. And a tool alone (e.g., adopting Jira) will not, in itself, solve any issues of understanding your Customers. And lastly, switching tools (e.g., from Jira to VersionONE) is unlikely to help, unless in that process you enhance the transparency and access to the Customer. Yet, we often find Engineering teams and leaders fretting about which tools to use for tracking work, storing documentation and sending messages. None of these will solve your misunderstanding of Customer needs and are, therefore, a complete waste of time until you have a handle on your interactions with the Customer.
I’ll talk more in future posts about both Lean Startup and Scrum. In the meantime, please comment below.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker