Manifesting Business Agility

By scale, I don't mean large companies, I mean projects that require multiple teams. The Lean Startup’s MVP is an incredibly useful concept that teams use to do discovery, implementation and delivery in the creation of new products. These teams focus more on learning than development - quick feedback and pivoting is essential. It requires operating at their own pace.

But most organizations need to first unjam their teams by getting them to work together. MVPs provide little guidance here. Different methods are required to solve these two different problems.

Organizations should also be striving to create dedicated product teams that are fairly autonomous from other teams. Again, the concept of the MVP provides little guidance. Existing products require more parts of the organization to be involved (e.g., marketing, documentation, support). These dependencies should be identified early so everyone is prepared when work comes their way. Focusing on MVPs is a start small go big approach whereas most enhancements start big (initiatives) and go small (next increment of value).

The concepts in the MVP are useful. But how to implement them depends upon the context in which they are used.

Weekly sessions on Disciplined Agile Value Stream Consultant

Next one April 2. 8am Pacific. 

I will be holding weekly, one hour sessions on the Disciplined Agile Value Stream Consultant workshop. These sessions have 3 purposes:
1) provide me feedback about sections of the workshop I am working on
2) provide you some keen insights the Disciplined Agile has that I have not found in many other approaches
3) provide a glimpse of what the DAVSC workshop will looklike.

There is no charge and no PDUs. It will be a learning experience for all of us. You don't need to register, just join by going here at 8am Pacific this Friday, and Thursday for the next few weeks. I'll post a notice here when I'm going to discontinue this.

Please message me your contact information if you want to be kept up to date on these and on whether recordings are available. 

Meeting link:
https://lnkd.in/gFUHSeM
Meeting number:
472 420 644
Password:
abcd

Join by phone
+1-855-797-9485 US Toll free
+1-415-655-0002 US Toll

As I’m finishing the portfolio & product management section of the Disciplined Agile Value Stream Consultant workshop, several important messages become clear:

Why the MVP is the wrong artifact to use at scale. E Reis designed MVPs for semi-autonomous, cross-functional teams to discover what a new product should be & create it. They require short cycle times, without long range planning, so they can respond to what’s learned.

Why the MBI is the artifact to use at scale. MBIs define the next part of an initiative for which value can be realized. They provide guidance to create new product teams & coordination for existing teams.

How to use MVPs in large organizations. Large organizations should use MVPs for new products with semi-autonomous, self-organizing teams implementing them.

Portfolio & product management is needed at all scales. When framework designers only have these at large scale to avoid complexity, small orgs are faced with using a complex model or not having guidance on part of their value stream.

How the MBI simplifies portfolio & product management. Strategies->initiatives->MBIs/MVPs->realization of value is a simple model that can be used at all scales.

Detailed posts to follow both here and on the Disciplined Agile Linkedin group where I'll be spending more time on detailed discussions. 

Note: MBIs (Minimum business increments) are the most important concept I've used in Agile at scale. Here's an article on them. https://bit.ly/3bh4H1x

I'm in the process of building a 4-day workshop for the PMI's Disciplined Agile offering - The DA Value Stream Consultant. I won't say it's our equivalent to the SPC because it covers more ground - but that'd be a fair way to describe it.  Don't ask for details about the when it'll be available or other details as I can't speak to that. But as I'm working on the materials and instructor notes I'm looking for feedback from people. In particular, seeing if what I say is understandable and makes sense. 

The way to participate is to check out the resource pages I'm building. The main page includes a table of contents at the bottom which lists existing pages.  You can discuss things on the Disciplined Agile LinkedIn Group as well as I post updates to the site there. It's also a good place to discuss things with me and DA champions who hang out there. I am looking for feedback and am happy to answer questions.

Thanks. Hope to see you there. 

Value streams are the flow of work from start to realized value. The Lean mantra "flow when you can, pull when you must" sums up how you'd like work to take place in a value stream. Anything that slows down the work (hand offs, handbacks, waiting for someone) is not a good thing. This is why Lean suggests looking at delays in workflow and feedback. These delays typically cause waste.

Delays in workflow usually appear as:

1. A handback in a value stream
2. The need for someone’s help who is not available – either because they are in another value stream or because people within a particular value stream are not coordinating well

Value streams can be improved by:

1. Keeping work within the capacity of the people in the value stream
2. Allocating people to a value stream so that are available as needed – note, when not possible, use a kanban system to manage the work to be done by these people
3. Attend to the workflow in a value stream so that people don’t need to wait for each other (e.g., have cross-functional teams)
4. Have a workflow where handbacks aren’t required (e.g., test-first)

Value streams also provide a way to see how work in one part of it effects work in other parts.

Note: SAFe has redefined value streams to some extent.

In lean, the term "value stream" means "the set of actions that take place to add value to a customer from the initial request through realization of value by the customer. The value stream begins with the initial concept, moves through various stages for one or more development teams (where Agile methods begin), and on through final delivery and support."

You don't define them, they represent what is. You can, of course, define what you'd like them to be and to take actions to improve them. It's important to refer to value streams as "what is" and "ideal" or "what we want" value streams as something we want to create. Then we can see what steps we need to take to improve our value streams. 

One last point. In an article on value streams, SAFe claimed:

"By their very nature, value streams are long-lived and generally independent of each other"

This is not correct.  The major cause of multi-tasking is that value streams overlap with each other (not independent). And project thinking has them be short-lived.