What If?

What if a leader in Scrum, Kanban, Lean, Flow, SAFe, design patterns, ATDD, …

… when he saw a challenge with a framework he worked on overcoming it

… was focused on results not on creating a unique framework

… didn’t agree with others that there were limitations on what could be done

… didn’t think simple to understand meant difficult to implement

… attended to the dilemmas in creating approaches that were straightforward to start and guided you in improvement

… respected people’s knowledge and didn’t think they should trust consultant’s recommendations but trust themselves after a little guidance

… believed consultants should work themselves out of a job as soon as possible

… thought the attention should be on the work, not the framework

… argued for what worked, not defended frameworks

… put together a framework that incorporated the good that was learned while avoiding the limitations that had been accepted

After 20 years of working on this, there is, and the result is a new kind of framework. One based on patterns thinking that provides a tailored start and includes how to learn to improve. It’s based on laws of development, not my opinion. The first online workshop (with me guiding you) starts this week.

Please let me know if you’re interested.

How does your approach help you start and learn?

Note: This post is one of a series in the post Questions to ask about your approach.

Frameworks should provide a quick start while helping organizations continue to improve. Here are a few different approaches taken.

I. Provide a preset framework that has you do what it says until you learn to adjust (Scrum). The challenge with this is that the preset practices may not fit. This may have them lose faith in the entire transition. In addition, there is nothing in the framework that tells them how to transcend the starting practices. People may eventually feel locked in and just try new things with little guidance.

II. Provide some theory with preset practices (SAFe). This has somewhat the same challenges as I. above with the additional challenge of putting people into cognitive overload which results in few principles being remembered.

Both I & II focus on learning the framework with no training provided to transcend it.

III. Provide great detail in principles and let them figure out the practices. This does ground people in principles, but most want an answer to “what do I do?”

IV. Provide principles, a starting set of practices with options and a roadmap on how to select the practices that work for you. This gets people started on something that works for them while providing a way to improve. Yes, this is FLEX.

Lean-Agile Newsletter – July 17, 2019

Net Objectives

Last newsletter we announced our FLEX Train the trainer program. But as I’m working with clients — some using FLEX, others in improving their SAFe adoption — I find myself recommending the FLEX 3 day workshop to them so they can understand both the recommended practices and principles better, and therefore be more self-sufficient and require less coaching. We have an online one coming up next week (starting July 22), so I wanted to make sure you knew it was about to start. Continue reading “Lean-Agile Newsletter – July 17, 2019”

Know five things to be a flow whisperer

 

Getting people to work together may be difficult. Knowing whether what you are doing is moving you in the right direction isn’t. There are two mantras to follow:

  1. minimize cost of delay (deliver the most value quickly)
  2. flow when you can, pull when you must (avoid handoffs and focus on what’s most important)

The first deals with working on the right things, the second working on them the right way. Both are implemented by: Continue reading “Know five things to be a flow whisperer”

Does your approach utilize the concept of smallest realizable chunk of value that can be realized?

One of the cornerstones of Flow, Agile and the Lean Startup is quick delivery of value to customers. This reduces waste by focusing on what’s of greatest value while enabling pivoting and creating a tight bond between the organization and its customers.

We call this concept the Minimum Business Increment (MBI). The intention is to answer two questions when faced with implementing an initiative. 1:”what is of highest value that I can deliver quickest?” 2: “what besides development is necessary for the realization of this value?” MBIs lie between epics and features in size and are what calculating cost of delay (CoD) should be done on. Calculating WSJF on epics or features doesn’t make sense. Only subsets of an epic as delivered at a time, WSJF should be calculated on that. Features may not provide value on their own, so CoD is incalculable. Continue reading “Does your approach utilize the concept of smallest realizable chunk of value that can be realized?”

Does your approach utilize the concept of identifying the smallest deliverable chunks of value that can be realized in order to achieve alignment and the quick realization of value?

One of the cornerstones of Flow, Agile and the Lean Startup is quick delivery of value to customers. This reduces waste by focusing on what’s of greatest value while enabling pivoting and creating a tight bond between the organization and its customers

We call this the Minimum Business Increment (MBI). The intention is to answer the question “what is of highest value that I can deliver quickest?” MBIs lie between epics and features in size and are what calculating cost of delay (CoD) should be done on. Calculating CoD on epics infers delaying the most valuable part of an epic or the rest of it. Calculating CoD for a feature that can’t be delivered by itself is meaningless. Continue reading “Does your approach utilize the concept of identifying the smallest deliverable chunks of value that can be realized in order to achieve alignment and the quick realization of value?”

What agreements does your approach suggest you make with each other across the organization?

Many frameworks imply this agreement is to follow the framework. Others, such as Scrum, go further and insist you follow at least the immutable practices, rules, events and roles. This puts the focus on how individuals follow their role in the framework instead of how they work together.

While this may seem natural, it takes everyone’s focus off agreements between each other. It also has people follow the framework instead of seeing how they should really work together.

Continue reading “What agreements does your approach suggest you make with each other across the organization?”

What role do value streams play in your approach?

To be clear, I am referring to Lean’s (not SAFe’s) definition of the value stream – the set of actions that take place to add value to a customer from the initial request to delivery. The value stream begins with the initial concept, moves through various stages for one or more development teams and on through final delivery and support. You can’t define value streams – they are what is. You can, however, map them, define a “to be” value stream and you can improve them.

Continue reading “What role do value streams play in your approach?”

Good enough to ship is OK, even probably good. Good enough to stay, however, is not

The opening of the Agile Manifesto is:

“We are uncovering better ways of developing software by doing it and helping others do it.”

I would assert, however, that any approach (primarily frameworks) that has fixed practices in it (e.g., Scrum, SAFe) without a method of guiding how to go beyond them (e.g., Scrum, SAFe) may be great starts but are not truly Agile. The key is also _may be_ in that predetermined practices are not universal. BTW – LKU Kanban has its shortcomings as well in not attending to the entire value stream nor attempting to get to cross-functional teams.

There is nothing wrong with this. The trap is that people stop trying to go beyond them. Continue reading “Good enough to ship is OK, even probably good. Good enough to stay, however, is not”

Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question

originally posted July 2017. Co-written by Jim Sutton and Al Shalloway

Abstract: This blog suggests that instead of looking at whether we should choose between Scrum and Kanban, we can see Scrum and Kanban as process patterns and benefit from the best of both.

Scrum and Kanban are often presented as “solutions” for developing software within an organization. Yet every real organization combines unique histories, personalities, and individual skills and beliefs. Even the best off-the-shelf “solutions” require variations to fit the context of the real organization to which they are being applied. If the adopted approach is not designed for these variations, the results will be less than hoped for.

Continue reading “Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question”