Minimal Viable Change: Going beyond Agile to accelerate delivery and improve DX
Agile has been immensely successful at improving delivery efficiency in software development and dramatically changed how we all work. It is almost impossible to imagine a daily routine without mentioning terms such as standup meetings, sprints, kanban boards, story points, and burndown charts.?
?
But all is not well. Instead of tediously tracking development performance, developer productivity, code quality, and velocity, let's honestly ask ourselves: how often have we participated in a "standup" meeting that takes an hour or longer? Why must users and customers wait weeks for a critical bug fix, a simple yet powerful feature, or a quick performance enhancement to deploy? How many capable developers are sitting idle on any given day? We need to go beyond Agile - we need to be nimble!
?
In this article, I would like to introduce a powerful concept: MVC, or Minimal Viable Change, by citing the section discussed in my new book: "DevStreams," which presents a new paradigm for scaled software delivery based on lessons from Nature and Chaos theory. MVC is a glimpse into the overall theme of the book and a good example of how software organizations can start adopting isolated fragments of DevStreams and benefiting from dramatic improvements in the velocity of value delivery and positive DX (Developer Experience) as they start their journey toward embracing the entire paradigm as an encompassing practice.?
?
So, without further ado, here it is, from the "Integrate, Mutate and Iterate" pillar, introducing:?Iterate: Minimal Viable Change -?
"The facet of iteration is crucial as well. The idea is not to revolutionize or introduce many changes at once. Instead, we are trying to evolve by making small and manageable modifications frequently and continuously.?
I call such a change a?Minimal Viable Change. There is no clear-cut way to define this term; it is more about developing a feeling for it, and we can use a few guidelines to help us get there.
领英推荐
Before we discuss these guidelines, let's first set the premise. The thinking behind MVC is similar to the concept of a Minimal Viable Product – an approach that has gained so much popularity and success that it now seems almost natural. We adopt the essence of this concept and apply it at a smaller scale, the scale of a feature. Similar concept, different scale, self-similarity over scale – fractals again!
ProductPlan.com defines Minimal Viable Product as "a product with enough features to attract early-adopter customers and validate a product idea early in the product development cycle. In industries such as software, the MVP can help the product team receive user feedback as quickly as possible to iterate and improve the product.".
In his Lean Startup methodology, Eric Reis describes the purpose of an MVP as "the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least amount of effort." – we are trying to apply similar thinking at a smaller scale of a product feature.
Now, with a better understanding of what an MVC is, we can continue with providing a few guidelines for applying this concept: The first guideline is that the change should introduce an improvement or at least an intended improvement, which could take the form of added functionality, performance improvement, a modification that uses resources more efficiently, or more straightforward code or even documentation.?
?A Minimal Viable Change should be quick to implement and deploy, and typically a complete life cycle from ideation to production should be between hours to a few days. The final characteristic of a Minimal Viable Change is that its deployment is reversible with minimal risk or disruption to service delivery - the flow must go on! "
?
To learn more about MVC and how we can scale software delivery and improve developer experience by applying lessons from Nature, visit www.devstreams.com to start your journey with DevStreams.