Asking a favor of 15 minutes from any internal consultant of a large organization considering or using SAFe materials for training.

First, I promise I am not trying to get a surreptitious sales call. I am wanting to do marketing research. Here is the situation. I am looking to disrupting the big 8 as I’ll start calling them (Scrum.A/I/O, SAFe, DAD, LKU, LeSS, Spotify). There is more goodness outside of them than inside of them (& i’m excluding what i have to offer when i say that).

I don’t want to go into details yet, but i’m hoping to get a better understanding of the attraction of the certifying bodies as well as well what might be more attractive.

Anyway, if you’re willing to give me 15 minutes of your time I’d greatly appreciate it. Just email me at alshall netobjectives com thanks.

Clarifying my comments about the certifying bodies

While I do believe certification itself is directly hurting Agile, that was not my real point. My point is the following companies occupy most of the mindshare of those new to Agile: SAFe, Scruminc,, Scrum Alliance, LKU, LeSS, Spotify model, DAD. 8 for profit companies (I know SA is a 501C, but de jure only) controlled by a dozen or so people.

Because HR is so crazy about certifications most of the focus is on what these folks are certifying folks in. But the real things to be studied are Flow, Lean, quality code, organizational development, proper management techniques. Not the 8 frameworks mentioned above.

Companies are taking a very non-scientific approach to what is probably the most important body of knowledge there is – adding value in knowledge work with software involved. Focusing on certification (which means a focus on coursework) is the real problem.

What the certifying bodies can do to improve Agile

To avoid being accused of just being negative I thought I’d put out what I think the certifying bodies can do. After all, each has a well organized marketing and training team.

It would not be hard and they could add value to Agile.  It would take the following steps:

  1. acknowledge that certifying people is misleading. A 2-4 day course has only a minor impact on people. Just give accreditation that they’ve taken the course.
  2. admit that their approach is a good approach for certain situations, and specify what those situations are
  3. acknowledge that there is more to learn and that everything can be improved. That no one (including the person running the organization) has all the answers.
  4. encourage their trainers to learn news methods instead of forbidding them to do so
  5. understand that in the long wrong, the customers’ best interest is more important than selling a particular approach
  6. adopt modern training methods
  7. don’t preclude things that everyone needs but give no competitive advantage

Bottom line, put truth before marketing.

Evaluating your intake process on how effective it is to get leadership and management involved

I often hear complaints in the Agile space about how leadership and management don’t get Agile. I think much of that is because of how they are talked to. But I also believe it is the set of practices used makes it hard to see their role without doing a deep study of Agile – something they are neither interested in or going to do (and not something they need to do).

It recently occurred to me that one way to evaluate the quality of an approach is how it affects the conversation with leaders and managers.

I just updated my chapter on Using the Intake Process to Educate Leadership.

SAFe is not Agile if you are planning 3 months ahead

SAFe is not Agile if you are planning 3 months ahead

For companies that couldn’t get anything done in a year and are now getting things done in 3 months, SAFe is great. But don’t consider it Agile.

Quarterly planning presumes more certainty than we have. It’s waterfall thinking. Going from 12 to 3 months is an improvement. But don’t stop there.

If you are a development group of less than 300 people you probably could be doing 2 week plannings or even flow. Every now & then you can do a big room planning for the social benefits that provides, but it’s not needed for planning.

Long planning periods:

  • require reworking requirements in last couple of sprints
  • loses focus on realizing value
  • makes it more likely that features will be bigger than needed
  • loses focus by teams on releasable value
  • results in more work being injected into already planned work
  • has the refinement of any stories pushed out of the PI due to new work be waste
  • makes it harder to pivot
  • causes a loss in a sense of urgency
  • requires more refinement up front without advantage of feedback
  • establishes a baseline of “not good but good enough” so improvement stops

It’s fine to do high level quarterly planning but then work in a flow model to implement it.


The Five Whys of Lean as an Answer to the “But” of Scrum

This was originally published in October 2009

In this blog I discuss the need to get to the root cause of why so many teams are not having success with Scrum.  Merely saying management is not removing impediments or labeling it “Scrum but” does not give much indications as to what or where the problems are. The question is “why does this happen and what can we do about it?” I will suggest one of Lean’s problem solving tools – “5-whys” – may assist Scrum teams in moving forward.

In an Agile Collab interview, Ken Schwaber acknowledged that only 1 in 4 Scrum implementations achieve the success desired by the companies trying it. He attributes this to the organizations accommodating the impediments the team faces instead of solving them. This number has been generally accepted by the Scrum community as accurate (as discussed at Scrum gatherings and on user groups). What surprises me isn’t the low rate of success but rather the general lack of interest into why it occurs. I’ve looked at both sides of this (see Challenging Why (not if) Scrum Works and Challenging Why (not if) Scrum Fails). My own belief is that one has to take a scientific approach and do an inquiry into why things work or don’t work. The intent of both blogs was to spark a conversation about how to improve Scrum.  Unfortunately, neither blog achieved this.

In the past, the generally accepted reason simply seemed to be people were not disciplined, educated or motivated enough to do Scrum properly.  More recently, the belief that developers don’t properly understand what they need to do has resulted in much discussion about having Certified Scrum Developer courses to solve this problems.  But I am afraid both of these are superficial answers.

The issue of teams doing a pseudo Scrum by cherry picking their practices has reached epidemic proportions. One hears of this so much that there has become a name for it “Scrum but.” That is, “we do Scrum but for this”.  However, why do people do this?  This is an important question.   In some situations this is probably a good thing.  After all, Scrum is not a prescriptive methodology but rather a lightweight framework. One would suppose that would mean that there aren’t any absolutes in Scrum, but I’ve heard several CSTs say if you aren’t doing daily stand-ups or retrospectives then you aren’t doing Scrum. The reticence of many Scrum CSTs to present a model of why and how Scrum works (many claim such a thought process is actually counter-productive) only exacerbates this situation. In other words, if one doesn’t have a set of principles to work from, one is left with little understanding of why practices work or not.

So what’s supposed to be in Scrum and what’s not supposed to be in Scrum and who is to decide? If one believes that practices are context dependent and that teams need to be self-organizing then one would expect the teams to decide what they should be doing. Tailoring Scrum should therefore be left to the team and an outsider shouldn’t pass judgment on the team’s efforts. However, since teams don’t understand Scrum well at the beginning of their adoption of it the advice is to require teams to follow a starting set of rules and to only tailor them after you understand Scrum. But why should we believe the starting set works in all situations?

Ironically, many Scrum thought leaders believe software is so complex there is no causality you can understand. In other words, you need to just solve the problems as they show up. In other words, after you’ve tried things and learned them, then you should do things in a way that works for your situation. While this makes sense, it seems to have led to the current situation that if it works, we’ll call it “Scrum” but if it doesn’t, well, we’ll call that “Scrum but.”

The dilemma of Scrum becomes evident. While we don’t want to be prescriptive, when you learn Scrum there are rules you need to follow.  Then, as you get better, you can tailor it to your needs.  The unexamined assumption is that you can always do this.  I do not think it is as simple as this. I believe we need a real analysis of why teams accommodate their problems or why teams don’t follow certain Scrum practices. In other words, let’s get to the root cause of Scrum not working or teams doing “Scrum but.”  To do this, let’s use a Lean tool called “5-whys.”

Five Whys

When something goes wrong, we often jump to conclusions about what caused it. Even when correct, we often stop there – instead of asking ourselves, “well, what caused that?” In other words, we don’t get to the root cause.  Thus, even if we fix this problem, if the root cause is still present, it’ll likely cause another problem.  A popular Lean tool to get to root cause is called “Five whys.”  It basically is an a technique where one keeps asking “why something happened” until the root cause of the original incident which set off the query is uncovered. This may take anywhere from 2-9 levels of questioning – so “5” should not be taken as the exact correct number of “whys” to ask.

Let’s use Five Whys to determine root cause for accommodating impediments and “Scrum but”.

The root cause of accommodating impediments

One of the common impediments teams face in corporate-wide Scrum implementations is that team members are often assigned to work on several projects. It is easy to dismiss this on the lack of commitment of management. If it’s available for them to solve it, there is a kind of implication (and insult) that they’re not up to it – either in intelligence or in commitment. But the truth is somewhat different when one looks at the issue.  The question “why don’t they solve the impediments?” and “what do they need to know to remove the impediments the team is facing?” are questions that should be asked, but rarely are.

Teams often run into impediments whose cause are outside the team. The teams therefore can’t solve them. But why doesn’t management? For example, many Scrum teams are composed of members who work on other things besides their main project. This causes thrashing an delays.

Why does this happen? Because management believes that one of their jobs is to make sure that everyone has productive work to do.

Why? Because management tends to look at people’s productivity in making management decisions.

Why? Because productivity is what they have been taught and used.

Why haven’t they been taught more useful agile methods? Shouldn’t this change in Agile? Not necessarily.

Why? Because many Scrum thought leaders believe you shouldn’t teach much, just create a framework.

Implicit assumptions that may not be correct

Two (unexamined) tenets of Scrum are impediments that slow the team down will be recognized as impediments and that the team is capable of removing them. Besides my earlier statement that impeded teams may not have the capacity to remove the impediment I will go further and state that teams may not even recognize all of their impediments as just that. Many things that slow a team down are often just viewed as the way it is. There is no notion that it is an impediment. For example, I don’t consider the fact that I have to take planes when I want to travel long distances an impediment – it’s just the way it is. Now in this case, I think my perception of reality is correct (but it would be cool if one day I woke up and found out I could fly on my own!).

The whys of “Scrum But”

Let’s take another example of applying 5-whys to a common “Scrum but” – retrospectives.

Why is the team not doing retrospectives?
Because they don’t see the value of the retrospectives.

Why don’t they see the value of the retrospectives?
Because they think there is more value in doing their work.

Why do they think there is more value in doing their work?
Because the retrospectives haven’t really done anything for them.

Why haven’t the retrospectives done anything for them?
Because they often don’t get agreement on what to do.

Why don’t they get agreement on what to do?
Because they think software development is about intelligent people using their judgment – that is, there are no real rules to use or a scientific method to apply.

Why do they think this?
Because software is so complex and no one has presented them with a theory to explain it.

BTW: This is one reason I talk a lot about the theory of flow underneath Lean-thinking. I have seen that it can provide a thought process that helps unite the team.

The dilemma (faulty thinking?) of Scrum

Scrum is in a dilemma here. On the one hand, Scrum is based on being a light framework that doesn’t give a model to work from. On the other, without such a model many Scrum practitioners don’t realize the importance of the practices or how to manifest the affect of the practices in their own context. It seems that the reaction has been to insist that certain practices be done (at least at the start) – which is ironic because Scrum is not intended to be prescriptive. If there isn’t a model, then how can one tell if one is doing Scrum? The common thinking is that you’re doing Scrum if you are removing your impediments, but you’re not doing Scrum if you are accommodating them. This, of course, assumes that Scrum can always work – a dangerous assumption, in my mind. It also makes it very difficult for new teams to know how well they are doing.

Getting beyond “Scrum But”

To get beyond “Scrum But” one needs to be able to understand when the practices of Scrum work and when they don’t.  I believe this requires both an understanding of why Scrum works and a scientific approach in how to apply these rules.  Unfortunately, I have not seen the Scrum community embrace this approach.


One important aspect of systems-thinking that has long been ignored by the Agile community is that a system is not its components. Rather, it must be recognized that these interact in a way that creates the behavior.

But the nature of these interactions are very complex – meaning that they can’t be predicted. Unforeseen events occur, unexpected interactions and sometimes small, even obscure events happen that cause huge side effects. This is a reflection that product development (creating the unknown) by a group of human beings (by nature unknowable) comprise what is known as a complex system.

Many people have gotten caught up in the theory of complexity going further than what I need is necessary for pragmatic effect. While it is true that complex systems can’t be predicted, there are many patterns of behavior exhibited by them. In the same way engineers were quite effective in building magnificent edifices (e.g., the Pyramids) without a full understanding of the science underneath the methods used, it is possible to adjust the behavior of complex systems without understanding the full nature of the principles involved.

We mostly need to know that 1) our changes may produce unexpected behavior and 2) we are embedded in a system where small errors can cause big, undesirable affects (the essence of Chaos Theory). However, instead of giving up and saying we can’t predict things, we can move forward with an knowing our understanding is always incomplete. We do, of course, need quick feedback, both of our actions in our work and in any actions we take towards its improvement.

Both agility of development and improvement of our methods is required.


Systems thinking and complexity

An excerpt from the preface of my book.

One important aspect of systems-thinking is that a system is not its components but is defined by the way these interact in a way that creates the behavior.

But the nature of these interactions are very complex – meaning that they can’t be predicted. Unforeseen events & interactions occur. And sometimes small mis-understandings cause huge side effects. This is a reflection that product development is both complex (unknowable in advance) and chaotic (small things can have big effects).

While I believe a deep understanding of complexity can be useful, very little is needed to attend to it. In the same way engineers were quite effective in building magnificent edifices (e.g., the Pyramids) without a full understanding of the science underneath them, it is possible to adjust the behavior of complex systems without understanding the exact results of proposed changes.

We mostly need is to know that 1) our changes may produce unexpected behavior and 2) we are embedded in a system where small errors can cause big changes. This requires quick feedback both about the actions we take and process improvements we try. Both agility of development and improvement of our methods is required.

Impediments to flow

Flow-thinking is my latest thing. It’s looking at how to achieve value in the quickest way. This is not necessarily going faster – but mostly avoiding delays. I have observed that when I consult with clients I look for the following:

  1. hand offs (these delay value because they typically cause a degradation in understanding)
  2. delays in workflow (i.e., waiting for someone)
  3. interruptions to workflow (often caused by working on too many things)
  4. delays in feedback – a symptom is when work goes upstream (e.g., dev back to product owners)
  5. doing less valuable work than what could be worked on
  6. doing work manually that could be automated

As you minimize these you almost certainly will improve your value delivery. Quality typically goes up as well.

Question to ask when you hear something you know is wrong

When we hear something that we know is wrong we typically ignore it or argue with it. But there is often truth in something we don’t yet understand. One can’t tell at this point of course. It could be wrong. But it could hold some value if we’d explore a little further.

I have found it valuable to ask the question:

“what if this (absurd) statement is true?”

A good way to explore this question is to pretend the statement _is_ true – at least for a little while. This opens the door to many other questions such as “what am I not seeing?” “what am I looking at that is in my way?” “what does this person see that I don’t?” “what are they not looking at that I am looking at?”

You can even (for a limited time) act as if it is true and see what happens. Maybe you’ll learn something. Worst case is you’ll learn you were right (or still think so).