The Next Chasm To Cross

There is no question that Agile at scale has crossed the chasm. I would say that even the late majority is now involved. But where are the innovators and early adopters now? I would say they are:

  • Using operating models instead of frameworks
  • Focusing on business agility
  • Driving from Lean principles
  • The use of scaled leraning

However, as I go to conferences & write posts on social media I see that these endeavors are not limited to innovators anymore but are being pursued by many early adopters – the so-called “pragmatists.” The “chasm” between early adopters and the early majority is already being crossed.

I am seeing more and more companies who are looking for what works, even if they have to fill in the blanks a little themselves. While frameworks provide set solutions with some leeway for filling in the blanks, they rarely fit organizations perfectly. Also, current frameworks are based more on Agile than on Lean (even SAFe which incorporates many Lean principles supports a bottom up implementation approach). I think (and hope) that 2019 will see a crossing the chasm of the above topics. To facilitate this is the purpose of my new book and some new social media collaborations. Let me know if you’re interested.

FLEX is not another framework

FLEX is based on a different mindset than current frameworks. Most frameworks have a set structure within which you can add practices. People want to know what to do and frameworks provide this. But the pervading idea is that at the beginning people must just adopt the framework. This has two bad side-effects which I believe are the causes of much of the bad Agile we see out there. The first is that the framework rarely fits the organization perfectly. A slight variance is not bad, but the disparity between the framework’s starting point and what would fit them better creates a dissonance. This not only hurts effectiveness but often creates resistance because the dissonance will create extra work for people who are already overloaded. The second side effect is that you are subtly teaching people to follow.

The way to solve these two challenges is not difficult but takes experience. The first is that some method of tailoring the framework or starting point must be used. The second is that you always emphasize the why of any practice and provide a method for improving or substituting it when challenges occur. Both of these can draw from the deep experience 20 years of Agile now provides – giving us patterns of challenge and success.

It’s important to understand what really needs to be worked on

Experience has shown that virtually all workflow problems can be distilled down to delays in:

  • workflow
  • feedback after a decision or activity
  • value realization
  • knowledge transfer

These all not only delay value delivered but they literally increase the amount of work to be done. Lowering them is critical and can be done by:

  • Managing queues
  • Having small batches
  • Creating visibility
  • Automating testing
  • Having a test-first attitude at acceptance and unit level

It is important to note that most frameworks’ practices work on these items indirectly. Consider the impact of time-boxing & retrospectives.

There is no reason not to work on these directly. One, of course, can add this to most any frameworks, but be forewarned, doing so will likely lead to activities inconsistent with the framework.

My belief is that frameworks should be designed by working on these issues directly & giving practices that support them as a starting point. Then as people learn more they can refine their practices. That way we can use the framework but not be limited to its practices while still being clear whether what we’re doing is good or not.

20 Years In a Week

I try to take a scientific approach to things. I view frameworks & methods as hypotheses for how to best be effective. If I disagree with the hypothesis, I’ll speak about it. Some ppl don’t like that. But in the information age, methods are public knowledge & we should learn from them, not make them dogma. Learning from them also means improving them

When I started Net Objectives (20 yrs ago 1/1) I did it on the basis of adding value to the industry. I’ve always liked Earl Nightingale’s perspective that money received is a measure of value delivered. That’s served me well.

My drive has always been how do I help others learn and become effective. Over the last 20 years I have learned a lot by being a consultant, including:
1) people know a lot more than they give themselves credit for
2) people will listen to a consultant’s dogma as if it were ok that they have dogma
3) people won’t figure out things on their own if they haven’t already, but they are smart & can learn quickly if you give them a little guidance (not tell them what to do)
4) there’s no one-size fits all but there are many best practices that work almost everywhere, yet aren’t popular

If you have a sense that Agile can be better than it is, please drop me a line. I think I can show you why you’re right.

Want Some Free Advice on Solving Adoption Challenges in SAFe? Help Me with My Book.

I am close to finishing “Adopting SAFe® for Your Organization: Achieving Business Agility from Small to Mid-Scale.” We take our own FLEX approach (FLow for Enterprise Transformation) and apply it to SAFe to help solve virtually all of the challenges we’ve seen small to mid-scale organizations have when trying to adopt SAFe. The result is using the core of SAFe while fleshing it out with Lean-Agile principles and patterns of adoption to create a simpler framework, albeit perhaps no longer SAFe, to use.

The list of these challenges is at https://goo.gl/Zcx7cu
Please take a look at let me know about any others.

Let’s not put limits on our methods. And let’s not accept methods with limits.

Here are two serious questions:

1) As a provider of a framework whose intent to increase the ability of an organization to deliver value more quickly, why would you put limits on what could be in your framework? This means limits on both what could be added to the framework or what could be substituted for any of the frameworks rules, roles, practices and events? If you do, you are limiting the effectiveness of the framework.
2) As an adopter of a framework with the intent to increase your organization’s ability to deliver value more quickly, why would you accept limits by the framework you wanted to use? In other words, if something was more effective than what was in the framework, you’d have to stop using the framework to adopt the practice, … Why wouldn’t you find a framework that didn’t require this?

As far as I can tell, the only real acceptable answers are:
1) I don’t know how to do otherwise
2) I don’t know of a framework that doesn’t do that

Let me know if you have other answers.

Lowering the cost of your framework training by making it better

Framework proponents suggest starting with framework training & later adding what else is needed (e.g., prod management, test-first). We believe this leads to a significantly higher cost of training

Companies with more than a few teams need a blend of Scrum & Kanban. Few companies need all of SAFe. The most important aspect of a workshop should be how to work together with your associates

Training should be oriented around

  1. the context of the people being trained
  2. increasing collaboration
  3. learning by doing actual work
  4. needed essential skills

Training in frameworks is important. But when people are given the skills they need from the start, less knowledge of the framework is needed to move forward. This is especially true when these essential skills are learned together. Not having these essential skills leaves them unprepared & often causes resistance to the framework, which, by itself, is not helping.

Unfortunately, this type of training cannot be done with certification, since certification requires a focus on the framework. Less framework, more how to do is required. Fortunately, there are many qualified, non-certified trainers out there who are more concerned with you getting what you need

Attend To Culture. Excerpt from “Adopting SAFe® for Your Organization: Achieving Business Agility from Small to Mid-Scale” book 2 in the FLEX series

One must address the culture of the organization when attempting to improve it. Culture affects Lean-Agile adoptions in several ways. These include:

  • How attached people are to their roles. Scrum and SAFe require new roles for people.
  • The rate that people want to move forward. If slow, Scrum and SAFe may pose a problem.
  • The amount of discipline needed. If high, Kanban may pose a problem.
  • How much people will resist a specified approach. If high, Scrum and SAFe may pose a problem
  • How much do people already know. If high, standard training may pose a problem.
  • How much more do people think they know than they do. Must engage in a discourse with people more than a training mode.

These factors should be included in deciding how one will proceed with any adoption.

Introducing a New Kind of Framework FLEX: FLow for Enterprise Transformation

I have long believed that frameworks should meet the following requirements:

  1. provide an explicit method to start that can be tailored to the organization adopting it
  2. provide a method to improve the practices being used based on the situation of the people using it
  3. be able to incorporate new ideas as they become available

These are difficult to achieve and are not met by any of the popular frameworks. This difficulty is not because such a framework needs to be massive, but rather because it needs to be based on a clear, workable model of how software development works. Not having this model has led to both incomplete and/or complex frameworks.

FLEX is a framework that does meet these requirements. It considers other frameworks as tools to use and uses them to provide recognizable starting points to virtually any company. But by including a method to adopt new practices, etc., as needed, it adjusts to what’s needed without having to re-invent the wheel.

FLEX accomplishes this by having a set of intentions to achieve collectively that will increase an organization’s business agility – the quick realization of value predictably, sustainably and with high quality.

Attending to What Management Wants in an Agile Adoption

Proponents of Scrum often put the responsibility for failed adoptions of Scrum at the feet of management who don’t want to change. While I believe this is true some of the time, I believe the challenge is that Agile adoptions based on Scrum often don’t attend to management’s needs.

I believe management concerns regarding Agile adoptions are focused on reducing risk, making sure it fits their needs, and to be able to adapt when needed. It’s tempting to say “let’s just adopt Scrum.” But this ignores that we live in a complex world where you reduce uncertainty not by having a preset list of things you must do, but rather by learning to adjust to the situation at hand. These are things beyond our control.

What is in our control is our actions. 15 years ago we didn’t have a solid understanding of the “task work” so to speak of Agile. Why working on small batches were good, why visibility was essential, why managing queues is critical, … Now we do. This enables us to go beyond Scrum effectively.

Adopting Scrum is very often the best place to start. It provides structure & discipline. But get training from someone who knows how to go beyond it when that’s the right thing to do.

—–

Addressing the issue of how to adjust Scrum while not worrying about if it is still Scrum is based on  20 years experience with Scrum and is described here:  How to improve or change your Scrum practicesThis is part of our larger Scrum Support system.   I believe having a framework where being effective sometimes requires you to go beyond it is insidious. I contend there are place in any tech org of more than 50 people that no one set of practices work, particularly in shared services, DevOps, maintenance. We have put this together because we’re not limited to Scrum.