Minimum Viable Products (MVPs) are very different from Minimum Business Increments (MBIs)

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)”

Questions to Ask Yourself While in an Implementing SAFe class

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”

Focus on the work, not the framework

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”

We need to focus on our 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”

Lean-Agile Newsletter – May 16, 2019

Net Objectives

This newsletter continues our theme on what’s the next thing after Agile, as well as presents a few of Scott’s top posts this month. You can subscribe to the RSS feed on NetobjectivesThoughts if you want to get them as he writes them (and you’ll get mine as well).

FLEX Workshop. Aug 16-18. Southern Orange county.

FLEX is the culmination of how Net Objectives has been working on Lean-Agile at scale for well over a decade. It incorporates Flow, Lean, Systems-Thinking and Agile while driving from a business value delivery perspective. FLEX creates a framework tailored for your organization that continues to adapt as you grow. You will leave this workshop both having tailored a framework for your organization and having been given some expertise on how to go back and educate your associates. Licensing of materials is also available.

Webinar: June 3rd. The Six Most Important things I’ve Learned in 20 Years of Agile

Al Shalloway has been on the forefront of most Agile and Lean methods of the last 2 decades. In this webinar he shares the six most important insights he’s had over this time and how they relate to each other:

  1. How to design with patterns thinking
  2. The objective is business Agility
  3. Why the Concept of the MBI is so critical
  4. Lean-thinking (systems thinking and delays and management)
  5. Acceptance Test-Driven Development with Behavior Driven Development
  6. Why we need to focus on our work and not a framework

Each of these insights is critical to achieve effectiveness at any scale beyond a team. Al explains each concept and how they work together to provide guidance on how to improve the effectiveness of your organization

Webinar: June 17th. Creating the Next Paradigm Shift in IT and Product Development

Agile has been around for more than 2 decades. This is more than a lifetime in the information age. Dark Agile (as Agile done poorly has started to be called) has been around for just about as long and seems to be increasing. The reason is reflected in Einstein’s observation – “We cannot solve our problems with the same thinking we used when we created them.” The next paradigm is not based on Agile but on flow.

This talk discusses the main shifts required for the next wave after Agile:

  1. Focus on achieving Business Agility – the quick realization of business value predictably, sustainably and with high quality
  2. Attend to flow to achieve this
  3. Use Flow and Lean Thinking to achieve flow
  4. Focus on the work to be done, not the framework
  5. How Systems thinking, attending to complexity, and the role of Lean-Management are the foundation for this

Scott Bain’s TDD Posts

TDD as a Sustainable Process: Introduction LinkedIn Blog & Audio
Sustainable TDD: Part 1 LinkedIn Blog & Audio
Sustainable TDD: Part 2 LinkedIn Blog & Audio
Sustainable TDD: Part 3 LinkedIn Blog & Audio

My Top Posts for May

What I’m Up to- Leading the Next Mindshift LinkedIn Blog & Audio
Why We Need Adaptive Frameworks LinkedIn Blog & Audio
How MVPs are limiting you if you’re using SAFe LinkedIn Blog & Audio

A side note for those considering or wanting to improve SAFe. As a former contributor to SAFe, an SPCT and Gold partner, I know how to make SAFe better. If you’re considering doing SAFe or want to see how to improve it, see Part IX: Using FLEX to both enhance and simplify SAFe.

As always, happy to chat with you about your challenges and how we can help.

Al Shalloway

CEO, Net Objectives
425-269-8991 @alshalloway

SAFe® is a registered trademark of Scaled Agile, Inc.

What work we need to focus on

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:

  1. Identify and prioritize the work to be done
  2. Have an effective intake process to avoid pushing too much work onto the development group while ensuring the most important work gets done
  3. Create clear requirements
  4. Coordinate the work of the teams
  5. Teams work together with a common cadence and frequent synchronization
  6. Core DevOps

Here are the best solutions we’ve found in 20 years: Continue reading “What work we need to focus on”

Agile Does Not Have to Be So Hard

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.

Qualities of a good framework

Good frameworks are based on the value stream. This makes it easier for people to see their challenges and how they relate to each other. Roles are defined as responsibilities in the value stream and not as separate people. Roles can be expanded as required by the organization’s size.

Good frameworks adapt to fit the organization’s culture and situation. Resistance to adoption is lowered since the framework is presented as a solution to people’s challenges and not as something that may or may not help them.

Any practice or event in the framework should be presented as an example of what can be done. Alternatives, for different situations should also be presented.

The explanation of the framework is presented as an example of what a good organization does. More options can be provided as needed. This allows for adding options without adding complexity and still providing an holistic view.

When an adoption requires only part of the value stream to be worked on, how to influence the rest of the value stream is included.

It includes a support system to help people solve their challenges adopting it.

If licensing framework materials, how to adapt and teach the framework is also be provided.

What I’m Up To- Leading the Next Mindshift

I believe the next mindshift in software development will be as big as the one from waterfall to agile has been. Agile is now over 20 years old– a lifetime for the information age. This is evidenced by rise of new methods like Flow and Lean and new technologies like the cloud and AI.

Agile’s growth has been fueled by the successful marketing of a few companies that somehow created the belief that certification in a framework is more meaningful than learning the principles underneath them and the work required to be effective (e.g., ATDD, automated testing). Most certification courses are not taking full advantage of the latest insights now available. And most use old-school training methods that are expensive, inefficient and in some cases preclude customizing the materials promoted

We’re told complexity prevents those new to Agile from understanding principles from the beginning and that there aren’t best practices that can be readily tailored to the needs learning them. Many of us have demonstrated otherwise.

I’m up to changing this along with many other thought leaders.

If it seems that I’m tearing down something, it’s only so I can help build something better.

An Agile Fairy Tale

Once upon a time 2 really smart guys came up with a simple framework for teams who knew what they were doing to build products. It worked well. Other people who knew what they were doing started doing it. Then those that didn’t know what they were doing started doing it figuring they’d now know what they were doing as well.

It became popular because for the cost of a 2 day course you could get certified in that you knew what you were doing.

The framework was promoted as being the same as Agile, when it wasn’t. Companies that wanted to go Agile wanted folks who knew what they were doing so started hiring these master. This had the framework start to be used everywhere, even where it was not designed for. And, with its success, it became closed to new ideas by allowing new things to be put into the framework, but never allowing a challenge to the foundations of the framework

Then another group decided that they could take this framework and wrap it with their own. Now they had a big framework for all companies. And they put Agile in its name because no one knows what Agile is anyway

So now we have all of these people doing something called Agile that isn’t.

The moral of the story? A framework won’t help you become Agile. Focusing on your work may.