How FLEX and Team-Agility answer the tough questions

On a user group someone asked What’s wrong with Scrum?

My response was:

Nothing. besides the fact that it's 24 year old technology, pretty much ignores Lean and Flow thinking? or that no one offering certification will acknowledge where it applies and where it doesn't? oh, and relegates technical practices to a second round?

Further discussions led to my post:

"the question is how good is the fit for use of Scrum? where? how? what's better?"

I was later asked: “Al, are you able to answer your own questions - with a shameless plug? What about FLEX? Is that a better fit? Where? How? What's better?”

I gave this short answer on the group:

OK here’s the quick answer.

Yes. But I have to clarify that FLEX is our approach to improving an organization. Team-Agility is our team-level approach and is therefore most comparable to Scrum. Both are based on Flow (Don Reinertsen’s work) and Lean. Both of these are based on systems-thinking, which Scrum is not.. The general approach of both is:

1. See where you are
2. See what challenges you’re having
3. Use Flow and Lean thinking to surmise what improvements can be made
4. Attend to culture and see what a good starting point would be – make that explicit
5. Adopt that starting point while learning how to use Flow and Lean to continuously improve
6. Get feedback on how things are going – do Plan Do Study Adjust (this is different from inspect and adapt) and challenge not only how you can improve what you’re doing but if what you’re doing is the right thing (double-loop learning – not in Scrum)

The philosophy of both is that people have experience in principles (albeit, often in not following them) and know more than any consultant will about their organization. Having them understand what they need to overcome is not that difficult. But expecting them to re-invent the practices that are well known is waste and leads to things like Dark Agile because people don’t know what to do.

-----------------------------------

Here’s the full answer

I'll answer this for both FLEX and Team-Agility. FLEX is our over-reaching approach for an organization while Team-Agility is what we offer that's comparable to Scrum. Team-Agility can be thought of as team-level FLEX. Both FLEX and Team-Agility, however, answer all the issues I brought up the same way.

First, however, I want to say that for all my 20 years in Agile and espousing how to do things better, I don't think I've ever once publicly complained about any Agile method without having an alternative to it and presenting that alternative privately to the owner of the method in question. In '03 I started running into the limitations of Scrum. By '07 I realized that Lean was a great help for those doing Scrum and by '07 was espousing Lean for those doing Scrum. Ken threw me off the Scrum Dev group for 'selling Lean.' This exposes the core problem. BTW: This general behavior of being ignored has repeated itself with David Anderson (Kanban) and Dean Leffingwell (SAFe), although not with quite so much drama.

I view that when you propose an approach you should think of it as an hypothesis of the best way to do it. Hence, suggesting Lean would help Scrum adopters is not "selling Lean" but rather trying to improve Scrum. In any event, you can't sell Lean - it's a thought process, a set of principles and approach to solving problems.

This is a key difference between Scrum and Lean. Scrum's assumptions about empiricism can't be challenged, or if it is, you're not doing Scrum anymore. I'm not trying to do Scrum. I'm trying to find the best way to improve organizations. Scrum is a tool, that can be applied in some situations. It's value is limited by it having several immutable aspects (roles, rules, artifacts, events - see the Scrum Guide).

Lean, on the other has created a model to explain behavior - small items are better, attempt to achieve flow, use pull to manage work in process, many more. Lean itself isn't a process - it's a thought approach based on laws of product development and principles which help work with them. It comes up with things like work-cells (manufacturing's equivalent to cross-functional teams in software development) because that's the best way to achieve flow. But the key is flow, not the structure of the teams. Flow is how quickly work goes from concept to realization of value. Flow-thinking is essentially Don Reinertsen’s work (Principles of Product Development Flow).

Since I mentioned Lean in the manufacturing context I need to emphasize Lean thinking is domain independent. You can go to manufacturing to learn how it applies in the physical world when making things, but Lean software development is quite different because software development is different from the physical world (let alone manufacturing). Lean has been muddied by several Scrum experts who discuss Lean in the manufacturing world without the 10 years experience I've found it takes to truly understand it.

So let’s go through the issues. FLEX and Team-Agility::

• are both based on Flow, Lean (both of which are based on systems-thinking)
• both provide a starting point based on the organization/team using it. People need well-defined starting points, but they must be designed for the people using it. We start where best and then guide change as the people can best accommodate it. Scrum suggests starting with a theoretical best start (kind of ironic now that I think about it since Scrum is based on empiricism but doesn’t look at the evidence that perhaps this is not the best way to start).
• incorporate technical practices in the first round of training based on what they need.

Team-Agility can provide what appears to be a Scrum/Kanban hybrid. It can also provide Scrum as a starting point. In this situation we call it Scrum as Example. Scrum as Example starts just like Scrum but everything is viewed as an example of what to do. So if something doesn’t work, a practices/artifact/whatever can be substituted by something else that is intended to accomplish the same thing. Whether it does can be determined by seeing if flow increased by seeing if things like cycle time and cost of delay go down.

Regarding how people interact with the adoption of a new method FLEX and Team-Agility both include how to change culture via changing management methods and how people don’t resist change, but rather how they resist imposition. Knowing what to do is no longer the problem. But when people are involved (i.e., all the time) how people will react to the approach you are taking is perhaps the most important aspect of the approach. FLEX and Technical Agility both take the approach of seeing where people are, having them understand why they are having challenges and then building a clear starting point while having them learn some Flow and Lean principles to guide them in the future.

This is perhaps another key difference. People shouldn’t have to come up with practices, whereas Scrum leaves people to do this. Both FLEX and Team-Agility provide them in a “as you need them manner.” But people know more about principles than most believe. Consider this, you may have not known you were violating the principle that working on small things is better, but once it’s pointed out you have years of experience in seeing why that’s a bad thing to violate.

Finally, while FLEX and Team-Agility are brands, I have put them out into the world with a request that they be challenged. Because both are intended to be the best way we know how to do software development. This enables them to be improved by the community – another challenge with Scrum. It holds a few people as its authority. I may be the authority for how we teach FLEX and provide certification for it, but I am not the authority on what FLEX is based on – “what’s the best approach to improving organizations.” While I am an expert in this, there are many others. I’m wanting all of them to work together to improve our approaches.