Adopting Scrum for managing software projects may still turn up to be a difficult endeavor in some industries, which have been relying for decades on traditional project management. This article describes our strategy for presenting Scrum's benefits - iterative and incremental software development, continuous delivery of value, adapting to change, and prioritization - to convince customers in various manufacturing industries to use this approach.
The Essence of Software Development
During the first encounters it is common for customers to use engineering analogies to describe software. One of the most frequently used in the manufacturing industry is that software is like a house and software development is like building a house based on a blueprint; once the blueprint has been finalized there is no need for collaboration between the customer and the contractor. This conclusion is to be confirmed by the constructors, but comparing software to tangible goods and software development to a production line which builds those goods it's just not good enough and there is plenty of evidence for that over time. Software needs to be compared to something untouchable, like a symphony or a movie, where people are playing music or act according to a score or a script. Software is about people and it's the intellectual product of their collaboration. Just as the same book or script can be the source of countless remakes and the score of a symphony can be interpreted in many ways by different orchestras (noticeable at least to a listener with a musical ear), the same ideas and requirements will result in different software depending on how stakeholders collaborate. Software will fulfill customers' business needs much better when they actively participate in the project than when they stay out.
Mass products are achieved through a repeatable process; the software development process is not repeatable, it is like a journey and should be evolutionary. When a house is built, it is ready only once. When software is built, it may be ready at several stages, each stage providing additional value to the customer and to the end user. Adapting the house analogy, in each stage the software is a different building, evolving from a cottage to a castle.
Continuous Delivery of Value
One of the key characteristics of any software project is the uncertainty of outcomes. It is impossible to guarantee project success at completion. Considering this uncertainty of achieving success, it is important to start delivering results as early in the project as possible.
As an iterative process using prioritization and short development cycles, Scrum aims to continuously deliver maximum business value in a minimum time span.
With traditional Waterfall there is no value delivered until the later stages of the project:
Scrum projects deliver value throughout the lifecycle of the project:
Furthermore, additional value can be delivered due to the changes requested by the client during the project.
Focus on Change
In contrast with traditional project management, Scrum does not need the customers to come up with the entire scope upfront, instead it promotes just-in-time, information based, iterative decision making. Thus, customers can change their minds about what they want or even recognize their true business needs as the project progresses. This is why in the best-case scenario the business value actually delivered exceeds the value envisioned at the initiation stage. Customers might even end the project after any sprint, assuming the contract allows that, if they realize that the deliverables received accomplish the expected outcomes.
Cost of Delay
Very often, when asked which features they value most, the customers will say all of them. They consider that the software they will get at the end of the project should contain all the features they need. It may help to rephrase the question and ask which features will imply the highest cost if their delivery is delayed making the customers realize that they are actually losing money during the time they miss the features in production. This cost of delay can be determined given the business value of the features and the duration of their delivery. Furthermore, using these two inputs we can calculate the so-called CD3 metric (Cost of Delay Divided by Duration) and use it for prioritization.
The business value of a feature can be expressed in a variety of ways, like incremental revenue, cost savings, or cost avoidance over a period of time, e.g. a week, after the feature is delivered. A simple feature related to production execution could be for the shop floor operators to see the production orders with a raised alert highlighted in the top of their order list, so they can quickly react to shortages and malfunctions. The cost avoided by such a feature, e.g. idle time reduction, can be quantified and used as business value. The time to deliver a feature can be measured in sprints, which again relates to a time period, usually weeks.
Derek Huether describes in detail various scenarios for prioritizing features in [1] to show that CD3 is the most efficient. For illustration, let's use the features from the table below:
The first scenario is to not prioritize the features at all and work on them simultaneously. This is the case of the Waterfall methodology as all three features will be delivered after 48 weeks. The customer will lose $92 weekly, so the cost of delay will be in total $4,416 ($92 x 48).
In the second scenario features are prioritized solely by value, so they will be delivered in the following order: C, B, A. A feature will imply cost of delay until it and all the features with higher value are done. The total cost of delay is $3,336, calculated as follows:
In the third and last scenario considered in this article prioritization is done by CD3.The order in this case is B, A, C and the total cost of delay is $2,976:
The following table shows the costs of delay for the three scenarios analyzed:
In conclusion, in this case the Waterfall methodology gives the most unfavorable results, but it turns out that implementing the most valuable feature first may also not be the best economic decision. While Cost of Delay is a powerful way to demonstrate just how important the implementation order of features is for long and complex projects, it is only one factor that needs to be considered when prioritizing feature delivery and it's not meant to turn traditional Waterfall into a less appropriate approach for smaller projects where requirements are static and very well understood.
Build an MVP
A minimum viable product (MVP) is a product with a bare minimum of essential functionality aimed to satisfy at least partially the most important user needs of a targeted group of early adopters, who will provide feedback for future product development. An MVP is functional, it's neither a prototype nor a beta version. It is much less expensive than the final product and it needs a short development time, usually one or two months. In our context, an MVP is meant to illustrate to the customers the Scrum way of working and ideally to get them convinced of its benefits, while still delivering value to them. Sticking to the house analogy, here's what an MVP looks like in relation to the final product (image from [3]):
The MVP is the first released version, the "cottage", upon which all additional functionality will be built.
To Sum Up
In order to get customer buy-in and involvement we prepared an arsenal of specific methods, which come in handy in various situations. Telling a story or adapting a popular analogy seems to be a better approach to remove misconceptions related to software and software development than, for example, comparing empirical process control used in Scrum with defined process control used in Waterfall. Customers want to see results fast so next comes the illustration of value delivery. The facts and figures conveyed by cost of delay could significantly speed up feature prioritization. Finally, deep reluctance might be overcome by deploying on time an MVP with the right functionality.
References
[1] Huether, D. Prioritizing to Minimize Cost of Delay (2015) https://www.leadingagile.com/2015/06/an-introduction-to-cost-of-delay/
[2] Leung, C. H. MVP: Images Explained (2016) http://www.cassandrahl.com/blog/mvp-images-examined/
[3] Kovalchuk, O. What is Minimum Viable Product And How To Make It Right (2018) https://medium.com/anoda-mobile-development-agency/what-is-minimum-viable-product-and-how-to-make-it-right-8b885001c6f5
by Rama Anem
by Ovidiu Mățan
by Ovidiu Mățan
