Manifesting Business Agility

Scrum is based on a few values, practices and empiricism.
DA Scrum (DAS) is based on Lean, Flow, ToC and science. While both can start out the same way, the flexibility of DAS is much greater. This is because Scrum uses practices in an attempt to achieve what principles tell us is good whereas DAS uses principles to drive results by helping us select the appropriate practices teams adopting it.

There is no question that Scrum can be a good framework when cross-functional teams and sprints are both advisable and readily achievable. It also provides discipline for those new to Agile. Scrum's practices are good because they reduce batch size, shorten feedback cycles and remove delays in workflow. But what if these two practices are hard to achieve? Scrum provides little guidance to transition to them or find equally valuable but more suitable solutions.

DA Scrum’s approach is to achieve the result Scrum attempts but by providing adopters the ability to do it in a way that works for them. This enables adopters of DA Scrum to do Scrum practices from the outset, create a transition path to them or adopt a different set of practices entirely.

Being locked into Scrum has many teams abandon Scrum thinking they can't do Agile.

Fortunately, I haven’t had too many of these. I thought it’d be useful to mention what I learned from them.

Failure: Created viable plan for client but management would not follow through - was 8th in long line of failure

What I learned: Don’t assume what managers tellme is truth. Said wanted to improve but truth was wanted low risk in adoption.

Curtailed: Followed SAFe roles by the book, but client didn’t like roles & stopped engagement because of my rigidity on roles

What I learned: Must adjust approaches to culture and desired career paths

Almost lost: Doing team-agility workshop & provided lean-thinking to explain why Scrum works. Halfway through I was warned if I didn’t just tell them what to do they would not come back the next day.

What I learned: Some people just want to be told what to do.

Lost – Large company wanted Scrum training. I knew a modified version would work better and made that very clear.

What I learned: When upper management says “adopt Scrum” convincing mid-management of a better approach is a no-win situation since they have to confront management on better plan.

Bottom Line: You must adjust what you do to the client’s domain, attitude and culture in order to be effective.

qWhile I agree Agile can’t fail since Agile is a concept, I believe different approaches can contribute to its success or failure. I think this should be self-evident but I hear many people say “Scrum (or SAFe) doesn’t fail, people fail.” I mention Scrum and SAFe because I hear this often about these two. I trust I’ll never hear someone say that about Disciplined Agile, but if you do, let me know and I’ll talk tothem.

There are two major reasons having a sense of responsibility is important. First, blaming people has one stop striving for improvement. Approaches need to recognize Gerry Weinberg’s comment “no matter how it looks at first, it's always a people problem” and incorporate this into their approach. This is one reason attending to culture is so important – and why it’s so damaging that few do.
Consider a set of instructions to put together a piece of furniture. Poor instructions will make the job harder. While a person failed, better instructions might have helped. In complex situations the need for guidance is even greater. 

Trying to defend an approach by saying it’s too complex or you can’t figure out everything are just other ways to justify stopping improvement.

Disciplined Agile is agnostic in the way science is agnostic – we look for what’s of value and discard the rest. Our approach is held up to objective measures. With over a century of Agile experience on our IP team, we find value most everywhere. Many people look at a competing approach and see just what’s wrong. We look at it and also see what value is in it. We then include that value in a cohesive approach based on Flow, Lean, Agile, ToC, organizational development, human psychology and more. These are not buzz words to us either. Each contributes as aspect of an ontology that helps explain how things work.

Disciplined Agile does not include the entirety of other approaches. With few exceptions most do not have a scientific approach and/or have an architecture that does not allow inclusion without also adding complexity. But value is there. Scrum provides the value of cross-functional teams, XP technical practices, SAFe coordinating teams with dependencies, Kanban guiding change through Kaizen, …

We can provide dispersed nuggets of value because we are built on a broad foundation of what is so, not merely a few practices that worked for one of us at some time in the past.

Any approach to Agile at scale must attend to the following:

1. Organizations need a well-defined place to start
2. Since no one size fits all this starting point must be tailored to the organization adopting it
3. The process of tailoring must be done in conjunction with the people doing the work
4. The process of tailoring the starting point should also teach how to do ongoing improvement

Architecture for an approach must enable content to be presented while:

• Avoiding cognitive overload
• Being sufficient
• Being extensible
• Never having the addition or subtraction of a process that is useful be grounds for saying you’re no longer doing the approach

Developers of this architecture know

• That the content is always incomplete
• We live in a complex world
• Must provide a way to get feedback on all decisions/practices as to whether it was useful, not useful or if something is missing

The general attitude follows George Box’s mantra – “all models are wrong, some are useful.”