Manifesting Business Agility

For every problem there is a solution that is simple, neat, and wrong - Twain

Everything Should Be Made as Simple as Possible, But Not Simpler - Einstein

The concept "simple" has been confused in the Agile space. Fewer parts does not equate to simpler, but it is often stated as if it were. There is also a difference between how simple something is in its design and how simple it is to use. Sometimes a complicated (internal) design provides a simpler (external) behavior. Cameras with autosteady is an example.

This leads to a useful insight - the simplicity of fit for purpose is more important than the simplicity of how it's built.

Another myth - providing more means you're being more prescriptive.

Not if the "more" are options to use. For example flow or iterations. Less prescriptive, possibly more complicated, but not with good design.

Simple to understand is important. But the understanding needs to be about what to do - not about the approach being taken. "Buy low sell high" is simple to understand, but difficult to do.

We must remember there are two bodies of knowledge required when we adopt Agile. The first is understanding the doing of Agile (eg, small increments, quick feedback) and having an Agile workflow. The second is how to do these.

Note: This is a rewrite of my earlier post "The challenge with "release every sprint"" which I have deleted. It wasn't well written and after a considerable amount of Linkedin conversations I rewrote it to this.

From the Scrum guide "Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint." Within this, there are three ways of planning a sprint. 

1) Early Scrum had a team plan for a release at the end of the sprint. 
2) More recently, teams plan for what will be released by the end of the sprint while intending to release incrementally during the middle of the sprint. 
3) It's possible to do a third kind of planning - a secession of releases starting from the beginning of the sprint and continuing until the end of the sprint.

#1 is still the most common type of planning. #2 is better, but still has one focus on the big batch of the sprint. Sprint lengths don't usually exactly correlates with when something can be released. #3 is the best, but requires a concept of what the smallest releasable chunk of value is (like an MBI in DA or MOVE in tameflow - not the same as an MVP). It also has one build in small sections and pivot each time. There is no tendancy to get stuck with the sprint plan, but pivoting occurs with every interim release.

#3 disengages releases from the sprints altogether. This is essentially a flow model. While sprints may be useful as training wheels, there is overhead with them.

This is a follow up to Why You Should Use Disciplined Agile If You Are Motivated to Improve Your Team’s Methods But Are Having Trouble With Scrum.

Step 1: Go beyond empiricism and add a model explaining why Scrum works. Learn the core concepts of Lean (use small batches, remove waste by removing delays, build quality in) and flow (manage queues, focus on time of value delivered)

Step 2: Understand the objectives of Scrum’s practices in light of this theory

Step 3: Identify the practices you’re having trouble with. For each practice, look to see if the theory above provides insights on how to do it better or if it suggests using another practice. Do not just abandon it. Meet the objectives of the practice by doing what works for your team. Don’t worry whether you’re following the Scrum guide

Step 4: If your team can’t reach agreement on a new practice, try an experiment for a sprint. See what happens &adjust

Step 5: If you can't finish stories in a sprint, go to 1 week sprints. While counter-intuitive this helps because 1) it forces a focus on finishing small stories & 2) you don’t waste time analyzing & planning stories you never get to (those that roll over)

For years scrum has stated it's "simple to understand, difficult to master." The problem with simple to understand is that that what's important is how simple it is to use. This is a major difference in philosophy between Scrum proponents and those using Flow, Lean and ToC. We focus on "simple to use."

Consider bikes. A one speed bike is simply built, easy to understand, easy to start with but not necessarily easy to use. If you're biking up hill for a long time you might find a 27 speed bike geared somewhere between 1 and 9 better. You can keep it simple to understand by having someone who knows bikes set the speed before you use it.

You can also start with simple braking - just use the right brake (safest and easiet to use). When the rider is more experienced you can tell them about the left (front) brake.

Simple is related to "fit for purpose." A one speed bike may be fit for purpose in some places, but it certainly isn't fit for purpose everywhere. A well designed system can expose it's extra features as people are ready for them.

Disciplined Agile Scrum is designed to be simple to start with and use and to be expandable as needed. Might be a little harder for the consultant, but that's why you want a DA Scrum Master.

for more blogs on Scrum go to Blogs and Videos on Scrum.

“A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system … The secret is cooperation between components toward the aim of the organization.” —W. Edwards Deming

Leadership and management play an important role at all scales. While being a servant leader is important, that must come in the context of the big view of the organization. In essence the purpose of leadership is to facilitate the movement of organization to provide more value to its customer in a way that is consistent with its strategic vision.

This respects the ability of workers to self-direct and self-organize while creating an effective eco-system within which they can work. This is accomplished by MIDDLE management looking UP the value stream to see the vision of the organization.  They then look DOWN the value stream to see what they need.  Management then works with those doing to work to create an environment within which the vision can be manifested. This is called Middle-Up-Down Management.

• Middle-Up-Down Management is described in Toward Middle-Up-Down Management: Accelerating Information Creation, Nonaka (1988). Although Nonaka co-authored the New New Product Development Game (1986), on which Scrum is based, Scrum ignores this foundational aspect of Lean management.
• It balances the imperative to ‘process’ information in a mature organization with the need to create information in a fast-moving, learning organization
• Middle management becomes the driving force for organizational change to meet the strategy of the business

In any organization, the layer of middle management, those who sit between the topmost strategic level and the level of the “gemba” (the place where the work is done), can be either the largest barrier to change or a true catalyst for improvement. In many Agile transformations, the role of middle management is not only undefined, they are cast as the antagonist to any productive change. This is counter-productive.

We believe that management, at both the strategic and middle/operational levels, has a key role to play both in transformation and in the ongoing success of the Lean-Agile organization. We subscribe to Nonaka’s vision of middle management as the place where strategic direction meets creative response. It is where strategy is shared downward and real-world learning is shared upward.

In our model of transformation, transformation itself becomes a part of the work to be done. Middle management becomes the focus of getting to done and is the ‘owner’ of the new forms of leadership and work that it unleashes.