FLEX as a Pattern Framework

A pattern is a solution to a recurring problem in a context. Christopher Alexander, who created the concept, says :
“Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

In FLEX’s case, the context is achieving business agility – the quick realization of value predictably, sustainably and with high quality. This, of course, requires solving several problems with each of these problems being solved in a different manner. FLEX groups these patterns those patterns that solve the same conceptual problem. Hence it consists of pattern groups with each group consisting of a set of patterns that solve the problem associated with the group. The primary groups are:

  1. Value stream management
  2. Strategies, & initiatives
  3. Portfolio management
  4. Product management
  5. Intake process
  6. Planning
  7. Development
  8. Release
  9. Realization

Patterns must include their purpose, the forces they deal with and their proposed solution(s). Patterns are also named in order to be able to identify them. This has the added value of improved communication.

The Mistaken Assumptions of Essential SAFe and What They Tell Us

From the SAFe site:

  • With such a robust framework, the question becomes; how closely does an organization need to follow various SAFe practices to get the desired result?
  • [Essential SAFe] provides a starting point for implementing SAFe and describes the most critical elements needed to realize the majority of the framework’s benefit.

SAFe is projecting the word ‘robust’ (which means strong) on itself instead of using the more appropriate ‘complicated.’ This is merely putting lipstick on a pig.

SAFe’s complexity makes it hard to implement as a whole. There are many essential concepts in the higher levels, however. The choice becomes insufficient or overly complicated.

Essential SAFe has Mid to small size organizations (especially those within larger companies) lose the opportunity to solve one of their biggest problems – prioritizing what to work on. Claiming that one should start at the bottom is reckless.

The bottom line is that SAFe is an overly complex framework requiring one to start with only a part of it. But this violates what SAFe claims to be built on – systems-thinking and Lean. It also loses the opportunity of getting the higher levels involved quickly.

There is cause and effect between actions and results

While I agree that complexity means that we can’t predict what’s going to happen when we make a change. But not having certainty does not mean there aren’t forces we have to attend to. It’s like driving. While complex, driving on the correct side of the road makes what happens both more predictable and effective.

What we must be aware of is that we may not get what we expect to happen. This is not failing but rather an opportunity to learn about learning the relationships between the people and actions in our organization. Some we don’t see well and others don’t behave the way we expect. But by considering what should happen contrasted with what does, we learn about these relationships when we get unexpected behavior. We can then take action based on this new knowledge.

It’s not failing when we learn fast in this way. It’s how we get improvement in complex systems and those that can go off course because of small misunderstandings and mistakes. The key, of course, is feedback, continual learning and creating a model of how things work we are always suspicious of. If all you do is inspect and adapt without creating a model of what’s happening you lose the opportunity of increasing your understanding.

In my FLEX book I am building out such a model. Check it out at  https://portal.netobjectives.com/pages/books/going-beyond-lean-and-agile/creating-a-roadmap-for-improvement/#ActionsThatHelp

Issues with using preset training materials

It’s exciting to see how the competency of internal change agents is going up – many well above the average consultant. They don’t help in what to do as much of it being an issue of the time to do it

Turning to set training materials is often their only option. But using set materials without change is almost certainly not ideal for the organization. This makes it hard to adapt the method to the organization and avoid a “one-size fits-all” approach. While this may benefit the people selling the materials it is certainly not a benefit to the change agent

This is why FLEX has two courses:
1) FLEX for Change Agents. This is a 3 day course intended for people who will teach FLEX internally. Its high level agenda is:
Day 1: 1/2 day on FLEX, and a 1/2 day on doing an assessment to determine their organization’s challenges
Day 2: Full day on FLEX
Day 3: 1/2 day on how to use FLEX to create a starting framework that will work for their org, and a 1/2 day on how to teach FLEX

They then take a 2-day online workshop that provides the optional practices they need

At this point they can teach the 2nd FLEX course – Adopting FLEX. This is a 2-day course they teach to their organization that they’ve tailored themselves

Agile needs to be flexible

10 Lessons from 20 Years in Agile: Focus on the Work, Not the Framework

This podcast is part of a series, The 10 most important things I have learned from 20 years in Agile (June 3, 2019)

In this series, Al Shalloway shares some of the most important insights he’s had over this time and how they relate to each other.

This episode is about Focusing on the Work, Not the Framework. Continue reading “10 Lessons from 20 Years in Agile: Focus on the Work, Not the Framework”

10 Lessons from 20 Years in Agile: Flexible Concrete

This podcast is part of a series, The 10 most important things I have learned from 20 years in Agile (June 3, 2019)

In this series, Al Shalloway shares some of the most important insights he’s had over this time and how they relate to each other.

This episode is about Flexible Concrete. Continue reading “10 Lessons from 20 Years in Agile: Flexible Concrete”

Focus on the work, not the framework

Talk to most any team that is having trouble with Scrum and you’ll see some common patterns of problems:

  • can’t write small stories
  • work doesn’t get finished within a sprint
  • requirements are not clear

Learning how to write small stories with agreed upon acceptance criteria prior to writing code would be a good idea. Continue reading “Focus on the work, not the framework”

We need to focus on our work, not the framework

A great way to illustrate this is to read imaginary certification question for a framework, vs how to get your work done. Which would you rather be able to answer? My experience is it takes about the same amount of time to learn either one.

“What is a program backlog?” compared with “How does an effective intake process help define responsibilities for product management and make life better for developers?” Continue reading “We need to focus on our work, not the framework”

What work we need to focus on

There are six major actions that need to be in place in order to achieve significant improvement in an organization’s capability to deliver value quickly. These can be implemented in different ways depending upon the needs and culture of the company. These are:

  1. Identify and prioritize the work to be done
  2. Have an effective intake process to avoid pushing too much work onto the development group while ensuring the most important work gets done
  3. Create clear requirements
  4. Coordinate the work of the teams
  5. Teams work together with a common cadence and frequent synchronization
  6. Core DevOps

Here are the best solutions we’ve found in 20 years: Continue reading “What work we need to focus on”

Agile Does Not Have to Be So Hard

Many consultants repeat the refrain that Agile is hard because change is hard, people resist Agile, and systems are complex. These are over-simplifications of what’s really going on.

While changing our personality is hard, changing the way we work is only hard when we don’t see what’s in it for us. Preconceived solutions imposed on us often appear as extra work and we resist it. When a solution is based on solving our challenges we are likely to embrace it.

Understanding Flow and Lean enables making reasonably good predictions on whether something will be an improvement. But the way people work together is complex, meaning there are unknown relationships and personal behaviors. These often block our intentions but expose themselves when they do. We can incorporate these insights into future improvements making them more likely to succeed.

I do believe the most coaches are well intended. But the above reasons given for dark Agile are self-serving and hide major flaws in Agile adoption – focusing on the wrong thing and teaching in the wrong way.

People can understand Flow and Lean principles when they are related to their past experience. The focus needs to be directly on our challenges and how to overcome them. Not a framework that on average may be an improvement.

I will quickly follow up this post with what we need to focus on.