MVPs are used to discover when a product is useful. MBIs are used to define the smallest increment of value that can be built and released that realizes value for the business. Although both of these are about doing a small amount of work and releasing it, they are quite different in both intent and method.
An MVP is intended to create a new product without an existing customer base. It is built by taking the smallest step possible to determine if it is viable. An MBI is for building the smallest enhancement to an existing product. Continue reading “Minimum Viable Products (MVPs) are very different from Minimum Business Increments (MBIs)”
Organizations going to Agile at scale are often pretty set on SAFe. It’s a popular framework so it must do some good. And it does. It attends to the key objectives required but gives only one solution when there are several options needed. While alluding to Lean principles, no one can learn how to apply these in just two or three days.
Taking an implementing SAFe can provide key insights especially if consider three things when in the course: Continue reading “Questions to Ask Yourself While in an Implementing SAFe class”
Talk to most any team that is having trouble with Scrum and you’ll see some common patterns of problems:
- can’t write small stories
- work doesn’t get finished within a sprint
- requirements are not clear
Learning how to write small stories with agreed upon acceptance criteria prior to writing code would be a good idea. Continue reading “Focus on the work, not the framework”
A great way to illustrate this is to read imaginary certification question for a framework, vs how to get your work done. Which would you rather be able to answer? My experience is it takes about the same amount of time to learn either one.
“What is a program backlog?” compared with “How does an effective intake process help define responsibilities for product management and make life better for developers?” Continue reading “We need to focus on our work, not the framework”
There are six major actions that need to be in place in order to achieve significant improvement in an organization’s capability to deliver value quickly. These can be implemented in different ways depending upon the needs and culture of the company. These are:
- Identify and prioritize the work to be done
- Have an effective intake process to avoid pushing too much work onto the development group while ensuring the most important work gets done
- Create clear requirements
- Coordinate the work of the teams
- Teams work together with a common cadence and frequent synchronization
- Core DevOps
Here are the best solutions we’ve found in 20 years: Continue reading “What work we need to focus on”
Many consultants repeat the refrain that Agile is hard because change is hard, people resist Agile, and systems are complex. These are over-simplifications of what’s really going on.
While changing our personality is hard, changing the way we work is only hard when we don’t see what’s in it for us. Preconceived solutions imposed on us often appear as extra work and we resist it. When a solution is based on solving our challenges we are likely to embrace it.
Understanding Flow and Lean enables making reasonably good predictions on whether something will be an improvement. But the way people work together is complex, meaning there are unknown relationships and personal behaviors. These often block our intentions but expose themselves when they do. We can incorporate these insights into future improvements making them more likely to succeed.
I do believe the most coaches are well intended. But the above reasons given for dark Agile are self-serving and hide major flaws in Agile adoption – focusing on the wrong thing and teaching in the wrong way.
People can understand Flow and Lean principles when they are related to their past experience. The focus needs to be directly on our challenges and how to overcome them. Not a framework that on average may be an improvement.
I will quickly follow up this post with what we need to focus on.
Systems thinking tells us to attend to the relationships between the components of a system more than the components themselves. The challenge is as the number of components increase the number of relationships between them increases exponentially. And, when these relationships have to do with human behavior they are only somewhat predictable. But this complexity does not mean that we cannot make reasonably accurate predictions about the affects of change in a system. Nor that we can’t learn how to make better predictions when we are wrong. While it is true that one cannot have certainty on what affects a change will make, there is a fair amount of predictably available.
The approach to take is to make predictions based on the laws of development present and on the known relationships and current state of the organization. We can make a change, but know we may be missing some relationships and possibly be misinterpreting others. We therefore consider the change an experiment. One that we think will work. If we don’t get an improvement we have likely found out about a relationship we weren’t aware of or a relationship that we have to be careful of. In either event we’ve learned something and our next “experiments” should be better.
Most frameworks are adopted in one way. Scrum has immutable roles, rules, events and artifacts so any start will attempt to have those. While you may vary things inside of it, this makes it somewhat of a static framework. SAFe’s implementation roadmap is the same regardless of the organization using it, taking a bottom level up approach since that is supposedly simpler. Neither take a look at where the organization is with the exception of some minor adjustments within the framework.
Taking this approach has the following disadvantages I’ve mentioned before:
- there is a tendency to focus too much on the framework at initial training – leaving less time on what the organization really needs to learn.
- when challenges arise people tend to look at the framework for answers, when a basic understanding of Flow and Lean would suffice
- the framework often doesn’t fit the organization adopting it well for any number of reasons and often does not fit the company’s culture
The result is that they only fit a certain number of organizations and those are typically the ones where teams are easy to form. A framework that adapts to the organization adopting it is critical. This increases adoption speed and value achieved while avoiding resistance.
MVPs were defined by Eric Ries to mean “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
If you are an established company, especially if you are using SAFe, the chances are excellent that you area not creating a new product but enhancing an existing one. You already have a customer base, know a considerable amount about your product and you have competitors you are trying to either keep ahead of or catch up to. This is a considerably different situation than creating a new product that you hope will create a new market.
In this situation, product development starts with initiatives to build. he question isn’t so much how do you discover if there is a product, as is it “what is of the most value that we can deliver sooner.” This requires a different tact. This is what a Minimum Business Increment is for. MBIs are that smallest part of an initiative that will realize the most value when delivered. This is a far cry from the MVP where we start small and extend.
While both MVPs and MBIs are conceptually about value sooner, they are considerably different in implementation. If you’ve been having trouble using MVPs, now you know why.
The certifying bodies who control their IP have incentives to keep costs high. They do this by having a limited supply of trainers, using small classroom size techniques, and providing more training on their frameworks than we’ve found necessary. This extra focus on the framework takes away from the skills people have to learn to be effective. Continue reading “The high cost of certification”