Manifesting Business Agility

Agile tends to go to extremes. Scrum prides itself on being simple and small but ignores it being insufficient for many. At the other extreme is SAFe, an Agile behemoth that keeps growing and has become overly complicated. Size is the wrong measure of efficacy.

Consider Wikipedia. It’s pretty big. Would it be better if it had fewer or smaller entries? I think not. In fact, it could double in size and be better for it.

More relevant is the architecture in which the information is presented. Consider how Wikipedia is both sufficient (for the most part) while avoiding cognitive overload. It accomplishes this with an architecture that enables quick access to information (briefs for each topic) with an ability to provide more information as needed (hyperlinks). It enables the right amount of information at the right time without causing cognitive overload. This is the issue.

DA FLEX is architected to achieve the same result – have sufficient information, allow for adding as much as is useful, all the while avoiding cognitive overload. It accomplishes this by being organized around the value stream. A relatively small number of entries that can be expanded as needed

I have seen many successes of Agile in my career. Most of the clients we worked with at Net Objectives considered our work there successful as evidenced by us having many repeating clients. When I go through the successes, I see the following patterns:

1. Teams wanted to do Agile and there were no external impediments to them doing it
2. A leader (usually at the director level) grasped one or more of the following key insights/practices and used them as a way to move forward based on their own judgement.
   • Everything was subordinate to delivering value to the customer (& they had learned about MBIs)
   • Reducing delays in the workflow was critical
3. ATDD was embraced by teams and product owners
4. We closely worked with them to create workflow to deliver value (these were usually our Agile at scale, long engagements)
5. We improved their technical skills
6. We unobscured what their real problems were and they solved the
7. We taught them lean & then guided them in using it to change their team structures to reduce delay in workflow

This is not a complete list. In 20+ years I’ve seen few cases of just taking a framework and it working. Applying principles and natural laws in the client's context was always critical.

A CST, in response to my post 'How Agile Fails', asked me “How can Agile fail? Agile is just some ideas shared.” Here's my answer

While Agile's not Scrum, it's pretty common so I'll use it as an example. Scrum has immutable roles, events, artifacts &rules. People are supposed to follow them as is. But since Scrum is based on empirical process control, little Lean, Flow, Theory of Constraints or organizational development is taught. When they have trouble they don’t know what to do. They try, but often can’t solve their problems- struggling while they have day jobs. So what happens is they sometimes substitute a bad practice for a Scrum one they can’t get to work. This often makes things worse.

I don’t blame the folks for abandoning Scrum given they are poorly prepared to adapt it to their needs and are even told not to (Ken Schwaber says "Scrum is simple, use it as is"

A way to fix it this to acknowledge Scrum is just one of many ways to do successful Agile. Scrum has many good practices–but there are no universal practices. People should think of Scrum as a starting point & be given a way to find practices better suited to them as needed. It may not be Scrum, but it may be successful.

I believe we have to stop looking at Agile failures in general and look at _why_ they fail in particular. There are very well defined patterns of failure with fairly clear reasons for them. I have identified many of these in the past but merely got the label "basher" for my efforts. I have since re-focused my efforts on what to do instead of what not to do since there's not much audience for the later.

But knowing what to do is only half of the story. In my 21 years of experience with XP, Scrum and other methods, I rarely hear promoters of an approach look at the cause of failure other than attribute it to management or unmotivated workers. Which, of course, is ironic, because one of Agile's cornerstone's is trusting people which implies to me, anyway, not to make them wrong.

We need to look at failure not as a necessary result but be discerning about what causes it. We must have no loyalty to our own methods merely because they are our own and it hurts our ego to seem them be ineffective.

This is part of the essence of what we mean when we say Disciplined Agile is agnostic. We don't regard our approach as better than anyone else's just because it's ours. When we are proven wrong about something it is merely is an opportunity to learn.

People hold onto ideas they are familiar with. Worse, however, is we create a cognitive bias that what we know is right. I am continuously reminded of Upton Sinclair's comment - "It's hard to get a man to understand something when his salary depends upon his not understanding it."

I believe these two combine to manifest what Bucky Fuller (Author of "Spaceship Earth") once stated: "I am enthusiastic over humanity's extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday's fortuitous contrivings as constituting the only means for solving a given problem."