Project Management

Manifesting Business Agility

by
This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.

About this Blog

RSS

Recent Posts

Big Change Up Front (BCUF)

Why Lean and Flow Thinking Make Things Simpler

An Introduction To Lean

Waste From a Lean Product Development Perspective

A Pragmatic Introduction to Lean Development

Big Change Up Front (BCUF)

Originally published 1/1/20211. I have some additional information at the end to bring it up to date.

Throughout the Agile movement, one acronym that has been used in a derogatory way has been BDUF (Big Design Up Front). The problem with BDUF is that we are laying out our entire plan when we know the least about our actual product. Agile is about doing a little, learning, doing some more, learning some more. It is about being incremental and iterative in our discovery, creation and learning.

The irony of Agile's (currently) most popular method, Scrum, using something comparable to BDUF hit me this morning in responding to a discussion on a user group regarding Scrum roles. The challenge was that the roles of ScrumMaster and Product Owner are pre-defined for Scrum teams. For those that don't have either true teams or these roles, one has to make a Big Change Up Front (BCUF) to start Scrum.

This is not necessarily bad. It presents both opportunities and challenges. But the risk of using pre-determined roles is somewhat overlooked - and it is dangerous to do so. For some, BCUF is wonderful. Creating a team alone solves many of the problems being faced. But for others, this change can be traumatic and can have dire consequences. Which way it goes depends considerably on who is requesting the change and the maturity of the people involved.

I find it odd that we denigrate BDUF while not even questioning whether BCUF is good. David Anderson created Kanban to avoid BCUF. Odd that Kanban has often been attacked as not good because it's "evolutionary" instead of "revolutionary." I have long contended that an "evolutionary" approach to change is "revolutionary." 

The Lean/Kanban alternative is to first understand your current process and to gradually change it. You do this by creating visibility into it using a Kanban board which represents the value stream. You discuss your policies to make them explicit. You manage your work in progress to do step by step improvements to your work flow.

I am not suggesting that BCUF is always bad. There are times I've used it when there is a well identified problem with a clear solution and almost universal buy-in. However, not looking at whether a BCUF approach should be taken is dangerous. It's one of my complaints about consultants who have only one tool in their arsenal and why at Net Objectives we have several (Lean, Kanban, Scrumban, Scrum, hybrids even).

BCUF can be expanded beyond the team. It is common practice when adopting Agile methods to do a pilot project. But this is also a kind of BCUF. We assume that the change here (at the pilot) is the correct thing to do without understanding the nature of our true challenge. See How Successful Pilots Often Actually Hurt an Organization (blog and 4 minute video).

To me, the question is never if something is bad, but rather when is something bad. This creates more learning. So, next time you start an Agile transition at the team or organizational level, ask yourself, is BCUF appropriate here?

Bringing this blog up to date. 

A few years after this blog was written, the Disciplined Agile approach came into existence. It suggests that we need to look at the current situations companies are in. This includes their culture and what the best approach for the organization at hand​ is. This means not only to choose your way of working but to choose the way of implementing change. 

One could also argue that always doing small change up front is also a problem. Sometimes started starting with a big change is what it takes to ensure the change will stick. Again, one has to have both a flexible approach and not insist on predetermined methods just because it's easier to train consultants to do this. 

Posted on: February 19, 2020 10:11 PM | Permalink | Comments (7)

Why Lean and Flow Thinking Make Things Simpler

First, let me start out with what I mean by “simple.” I view “simple” as being “fit for purpose.” Think about it this way, maybe something has fewer parts, or fewer concepts than something else, but if it isn’t “fit for purpose” then you have to add concepts or actions to make it work. Processes and models and everything else do not live on their own – they always exist in a context. Being “simple” without attending to the context something is in is a meaningless statement.

So how does Lean and Flow Thinking make things more “fit for purpose?” Making things fit for purpose requires making decisions to either change where you are or to change an approach you’re about to undertake. But how can you do this, how can you determine if something is better than something else in the context you are in? Given we’re in complex systems you can’t ever be sure your prediction of a new action will be correct, but you can be guided several Lean and Flow measures. And you can validate whether you achieved an improvement or not. Lean and Flow helps here by providing metrics such as cycle and lead time in addition to guidance such as focusing on quality and reducing delays in workflow and achieving feedback.

While virtually all approaches have accepted that Lean and Flow thinking is useful, most still define themselves around a framework that has a core of immutable roles, events, artifacts and rules. These core concepts can’t be adjusted without going outside of the framework. Although they use Lean and Flow principles, people can only use these to make adjustments that fit into the core framework. Since there are no universal practices, this means that adopting such frameworks means there will be a lack of fit for purpose in many situations.

Nevertheless, many practitioners argue for the universality of their core. For example, it is common in the Scrum community to insist that cross-functional teams can be used everywhere when we should be asking "when are cross-functional teams fit for purpose and when are other structures better?" Scrum’s mantra of being “simple to understand but difficult to master” may be more of an indication that its simplicity is in its definition and not its fit for purpose. This is not necessarily a good thing. This is just an example, I'm not picking on Scrum.  You can substitute any method and any of its required practices here.

This is one of the reasons that, although some people have claimed Disciplined Agile is more complicated than other approaches because it provides options, it is actually simpler from the overall view of what it takes to implement.  Scrum’s mantra of being “simple to understand but difficult to master” may be more of an indication that its simplicity is in its definition and not its fit for purpose. This is not necessarily a good thing.

The bottom line is providing choice when it makes things fit for purpose simplifies things. Forcing people to work a particular way complicates things.

Posted on: February 04, 2020 06:11 PM | Permalink | Comments (11)

An Introduction To Lean

There are many ways to look at Lean. Many people have taken the principles they've seen in Lean manufacturing and directly translate them into the product development arena. But manufacturing is not like product development. In manufacturing we're trying to limit variation and the only discovery is how to improve the repeatable process. In product development, we're trying to discover what is needed and how to create a physical manifestation of it if we're creating a product, a better process if we're if we're creating a new service or software if we're creating a software product. This process is considerably different than reducing waste in a manufacturing line. A metaphor can be in manufacturing we're cooking from a recipe, while in product development we're creating the recipe.

What we want to do is to look at the principles underneath Lean-Thinking. 

  • Take a systems thinking approach
    • Attend to the entire value stream
    • Align the organization around purpose
    • Think long term
  • Delight customers
    • Discover true value
    • Deliver incrementally to different customer segments
  • Invest in your people
    • Give them a sense of purpose
    • Provide them with a great working environment
    • Acknowledge them
  • Increase flow
    • Have efficient value streams
    • Avoid handbacks
    • Remove delays
    • Small batches
    • Speed, quality and low cost work together
    • Focus on flow efficiency, not resource efficiency
  • Build quality in 
    • don’t tolerate defects
    • test-first
    • common cadence and integration
    • look to the source of your challenges
  • Keep getting better
    • use the scientific method
    • look for emergent behavior
    • the role of management
    • Plan Do Study Act

 

Posted on: January 31, 2020 10:53 AM | Permalink | Comments (10)

Waste From a Lean Product Development Perspective

Last blog I posted DOWNTIME, a common way to look at waste in Lean-Thinking. Here it is again:

  • Defects
  • Overproduction
  • Waiting
  • Neglect of Human Talent (Unused talent)
  • Transportation
  • Inventory 
  • Motion
  • Excess Processing (over/extra processing)

With a little reflection, it's clear that the O, T, I and M relate to manufacturing. Attempting to bridge Lean manufacturing to Lean product development is not as effective as looking at what the underlying principles to both are. I've converted this into waste of Lean Product Development. 

  • Eliminate waste. Build quality in. When errors are found, stop the work and immediately get to the root cause of the error. This highlights that quality is important and is often due to the system. Not stopping the work means we're more than likely to keep repeating the error. Eliminating defects in product development means to be clear on what is needed before building it. In software development this means conversations between the product owner, developers and testers that create acceptance tests prior​ to construction. (Defects)
  • Build in small increments to provide value quickly and to turn your attention to the next item that will provide more value. Building incrementally helps avoid building what's not needed. As we deliver value customers become more aware of what they want.  If they don't know what they want until you show them what they don't want, the show them something as soon as possible. Small things get developed faster. In addition, the return on investment of new features tends to level off. Make sure you stop working once the rate of return slows down. (Overproduction)
  • Delays in workflow and feedback.  People tend to be always busy, but if you follow the work you will see that it waits much, even most, of the time. But work doesn't sit idly as it waits. It grows, that is, it takes more work to complete because of the waiting than it would have otherwise. When there are delays in feedback, we continue working thinking we're on the right track when, in fact, we're not.  This causes more work.  (Waiting)
  • Learn as an organization. ​Lessons are often learned in pockets without any transference of knowledge. Effective organizations are learning organizations. (Neglect of Human Talent)
  • Multi-tasking is one of the most insidious causes of wastes. It directly causes delays and lowers the effectiveness of people.It is most often caused by improper allocation of capacity to value streams. Avoid allocating people to more than one value stream whenever possible. (Transportation).
  • Have the minimum amount of work in process (WIP) that you can have while keeping flow going. When work in process goes beyond capacity you are working against all of the afore-mentioned principles. (Inventory)
  • People being in multiple value streams makes then multi-task. In product development, shifting ones attention from one item to another not only makes people ineffective but results in loss of information while adding delays. (Motion)
  • Considering features too early usually results in overthinking. Incrementally designing a product enables you to attend to features that are truly needed. (Excess processing)
Posted on: January 30, 2020 11:02 PM | Permalink | Comments (4)

A Pragmatic Introduction to Lean Development

Most introductions to Lean focus on a variety of principles such as the following from the Lean Enterprise Institute (note the acronym)

  • Defects
  • Overproduction
  • Waiting
  • Neglect of Human Talent (Unused talent)
  • Transportation
  • Inventory 
  • Motion
  • Excess Processing (over/extra processing

This is definitely a useful way of looking at Lean. But another way is to look at what these would suggest you look at, want to achieve and something you have to do to achieve it.

 

Attend to how workload relates to capacity. Workload should never exceed capacity. Doing so creates multi-tasking, delays and waste. This requires having a well-defined intake process and do portfolio/product management to ensure working on only the most important items.

Assess the efficiency of your value streams. The people in most value streams are multi-tasking due to them being in multiple value streams. This causes delays and waste. Have people allocated to only one project as much as possible.

How large are your batches of work? As a rule, smaller increments that realize value is better. Do your work in small increments and use iterative development to discover what’s needed. Decompose strategies into initiatives into small business increments. See Minimum Business Increments for more. 

Is collaboration taking place across the value stream?  Teams should not be geared towards local optimization but should be looking at improving the effectiveness of the value stream as a whole. Create a common cadence for planning, coordination and synchronization.  Institute DevOps or the equivalent across all value streams.

What is management’s role? Management needs to attend to improving the environment so that people can get their work done. Management must look up the value stream to see what the direction of the company is and then collaborate with those downstream to interactively build a great environment within which they can work. 

How long are your planning cycles? Plan in short cycles. Work on removing impediments to shortening the cycle. Work should flow from initiatives to realization of value. Consider whatever requires an increase in planning times to be an impediment and work to remove it. 

What is the quality of your product? Quality includes both internal (how it’s been built) and external (what customers think of it). Build quality in. Get clarity on specific acceptance criteria that can be used to validate what's being created before starting work. 

These suggestions are based around Inherent Simplicity. More on this at Dealing with Complexity by Creating a Bias For Simplicity 

 

 

Posted on: January 28, 2020 11:42 AM | Permalink | Comments (9)
ADVERTISEMENTS

"Talk low, talk slow, and don't say too much."

- John Wayne

ADVERTISEMENT

Sponsors