Yes, I’m frustrated

A friend of mine said I sounded frustrated in my posts. My reaction to myself was, of course, that I’m not supposed to be frustrated. But the truth is, I am

The reason? After 20 yrs of working to help people see how to do their work better I find I’m fighting the same battles I was 20 yrs ago. Only the difference is now we know what to do & there are active forces working against it. Waterfall was just an ineffective belief system-but no one was behind it.

Back then no one understood Agile or Lean or test-first or the importance of flow. We didn’t have modern learning methods nor the technology we have now that enables remote, on the job training.

The choice no longer has to be Scrum or Kanban but rather an integration of the two in a manner that works. It has been demonstrated that learning ATDD/BDD up front is critical. Learning how to be an Agile coach should be multi-month program working with your team on how to help them be more effective. And improving organizations must be based on increasing the ability to take strategies through deployment & realization

Unfortunately, our focus is on frameworks & certification. While containing good ideas they distract us from the real work at hand. If you have this sense as well, as always, I’m happy to chat

Two approaches to training – you get to decide which you want

Which has you feel more trusted and respected?

1) Consultant comes in and says “do this until you understand what I’m telling you. Only then can you modify it. Trust me.”

2) Consultant comes in and says “when looking to improve, look at this and these patterns. Imagine how they have affected you in the past. Take those experiences with these new insights and solve your problems. I’ll be here to guide you but won’t tell you what to do since you need to understand why what you’re doing is going to work or not. And I know you can. Trust yourself.”

Neither is inherently better. It depends upon you.

How Frameworks Help Us and Hurt Us

Frameworks provide us with:

  • A list of roles, actions and artifacts which are useful
  • A set starting point

However, frameworks don’t discuss:

  • When they are most applicable
  • How to transcend them after the adopting organization has successfully adopted them

Frameworks are also not meant to be modified. The reason for this is stated as self-evident & therefore rarely (ever?) discussed. However, there is much evidence that a framework being adapted to an organization while still providing a set starting point is a better way to go.

The net result of the above is that people tend to adopt a framework as is. And many tend to require adherence to it. All of the above strikes me as particularly non-Agile. We have put fences around what we can do. The justification for this has been twofold – people need to follow something until they can think on their own and it’s too difficult to come up with a tailorable model.

The first one strikes me as not having confidence in people’s ability to figure out what they need to do. The second one misses the point. I’m not suggesting that the people adopting a framework figure this out, I’m suggesting that consultants and trainers figure this out and be what they present to their clients.

Using a Flow Model to Guide a Transformation

Two common approaches for Agile adoption have been frameworks (eg Scrum, SAFe) or improvement via kaizen (eg Kanban Method). The advantage of the first is that it provides a solid starting point. But this works against us as well since the preset framework may not fit the team or organization attempting to use it. Also, frameworks tend to work on proxies of the work to be done. For example, having cross-functional team working in a time-boxed results in lowering delays and handoffs. Good things. But by focusing on the time-box instead of the delays time-boxing reduces, those using Scrum don’t learn as much about reducing delays as they might otherwise.

The Kanban Method has the advantage of focusing directly on the work. By not having an immutable aspects, however, it often does not provide enough structure.

What’s needed is an explicit approach which directly focuses on the work but is contextualized to the organization using it. I suggest laying out the ideal workflow (value stream network) for the organization as a start. This can be used to identify current impediments to that workflow as well as action items to remove them impediments. A customized roadmap can now be created by seeing the optimal sequence of implementing these improvements.

Shift Your View To What’s Important

One of the major tenet’s of Lean is to not focus on individual activities but to look at the flow of value from concept to realization. Focusing on people, btw, is not Agile in my mind. We should be trusting and respecting them – not judging them. They are doing the best they can. management must provide them with a great eco-system in which to self-organize in order to achieve the business’ objectives.

The challenges around velocity illustrate this. If one understood the goal is to shorten cycle time (the time from concept to realization) it would be clear that managing (not measuring) velocity has no value. Many of the challenges we have in Scrum and SAFe is because these frameworks have us subtly look at the wrong thing.

But these things sure look important so someone sometimes has to shake us up to look at the right thing. The beauty is, once we look at our present in the right way, we can reflect on our past and instantly get a lot of experience. This is why newbies don’t have to be patronized and told to just use things as they are. They can think for themselves with years of experience once they know what to look at. This is the difference between giving advice and giving a new way to see a problem. I prefer the latter.

The Insidious Side of Scrum and How I’d Fix It (and yes, I know it wouldn’t be Scrum anymore)

Scrum is based on empirical process control. If I understand this correctly, this means that we base our actions on what happens and inspect and adapt accordingly. Scrum is accordingly set up with a set of rules, roles, artifacts and events designed in such a way that if they are followed good results will happen.

I believe it to be true that if you in fact do what Scrum tells you to do you will get good results. But that’s not a huge endorsement. If you follow a financial advice system that says to buy stocks low and sell them high you’ll also make a lot of money. And if you don’t, it’s providers can always say you didn’t follow the method.  The question is not if Scrum’s practices will work if you follow them, it’s can you always follow them? And even when you can is it the best way to go? And, perhaps more importantly, does taking this attitude that you should learn how to be Agile by using Scrum defined exactly as it is the best way to go? Because we must remember, our goal is not to do Scrum. Our goal is to be effective.

Let’s look at the typical way teams are told to adopt Scrum. It is suggested that they follow Scrum’s rules, roles, artifacts and events. But what if the team has problems with doing this? They are told to keep at it until they can do this. Since many of the teams are new to Scrum and Agile they are told to trust their trainers and coaches (in other words, not trust their own thoughts about what might not be working but to do what they are told). Personally, I find this somewhat disrespectful. People know a lot about their jobs and as a coach I wouldn’t expect anyone to do something merely because I said it’s a good idea. If I can’t get them to see it’s a good idea then that’s a failing on me.

But there are two other problems here. One, it may not be possible to follow Scrum’s practices. And two, even if possible, it may not be desirable. I have seen many cases of this over the last 20 years of using Scrum. Yet, in 10 years of discussing this I have yet to have one CST (certified Scrum Trainer) admit to such a possibility even though I’ve given them dozens of cases. Instead they always claim if people were committed enough they could do it. In other words, they don’t acknowledge Scrum may be off, but rather people just are not committed enough to do Scrum (implying, of course, that Scrum is the right thing). But wait a moment, what if there is a better way? Why stick to Scrum? Is it really always the best way to become effective? Sounds like brand selling to me. And that’s not a bad thing – you wouldn’t expect a Chevy dealer to say a Ford is better.

Here’s the problem. When Scrum is taught, the training almost always focuses on the framework. This makes sense. If it focused on the actual laws of software development there’d be no Scrum brand involved. In any event, Scrum isn’t based on the actual laws of software development. It’s based on  empirical process control. But that doesn’t mean that’s what it should be based on – this is just an a priori assumption that is always accepted. But Scrum is what it is. So when there are problems, there is no basis for figuring out how to solve them other than following Scrum’s rules. People intuitively know this is not quite right. So resistance is not uncommon. When things don’t work well, people often don’t like to keep doing what’s not working. Even if they try, if they are in a situation where Scrum is not ideal, at some point people will give up. But since they don’t know what else to do they will likely just drop a Scrum practice and voila you have Scrumbut. From’s site – ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

And now Scrum is off the hook because although the team is not getting effective, Scrum’s proponents can claim it’s not their fault because the team is not doing Scrum. Yes, the team is not doing Scrum. But Scrum’s definition is partly at cause. I believe what’s needed is to integrate how to remove dysfunctions into our Scrum training so that we have the opportunity to remove dysfunctions whether the solution strictly follows Scrum or not.

So what can we do instead? There’s a lot of evidence that taking an approach based on the Lean principles of systems thinking, just in time (reducing delays in workflow and feedback and in acting no new information) is more effective, Can we take the rules, artifacts, roles and events of Scrum and implement them within a Lean-thinking approach instead of an empirical approach? What would happen if we did this? Full-disclosure – doing this would result in something not Scrum. I’ll call it Lean-Scrum to differentiate. This is because The people who invented Scrum (Ken Schwaber and Jeff Sutherland) have the right to define what Scrum is.

So how would Lean-Scrum work and how would people trying to adopt it manage the situation where Scrum doesn’t work well?

Lean-Scrum would essentially say to start with Scrum but consider its roles, rules, artifacts and events to be examples of what could be done. That each of these have an object. If the practice of Scrum works then great – do it. But if not, teams should feel free to find another way to do things. This must be done in a disciplined way. This can be accomplished with this four-step process:

  1. Are you having challenges with the practice because it is being done poorly? If Yes, then inspect and adapt and see if you can do it better. If No, continue.
  2. Is there something else in the organization that is causing us this problem? If Yes, then see how to fix that or at least influence the fixing of it. If No, then continue.
  3. Is the ecosystem that the team finds itself in causing the problem? That is, are people not collocated when they need to be or are required skills missing? Can you improve on this? If yes, do so. If No, continue to see if another practice that works within this ecosystem will work better (see next step).
  4. What else can we do that meets the same objective of the practice? If there is something else you can do, then try that. If not stick with the practice until you learn more.

Step 4 begs the question of telling if you meet the objective of the practice in a different way. This can be determined by looking at the underlying principles in software development. This is always in theory to some extent, because even if a change will improve things if made, there are often side effects caused by people not adopting the change that work against it. We therefore must always be diligent and validate any change we make.

The measure to use is the value stream impedance scorecard. In a nutshell, the VSIS indicates how much resistance the system will impose on work being attempted. It is based on what improves total value manifested. Lowering this resistance usually results in more value manifested.

Psychologically this is a much better approach. Now people have a solid starting point. But if they have challenges with it, they can think for themselves and come up with what they think is a better way without just going off the deep end.  Hence, they don’t resist and can self-organize in more effective methods. Scrumbut can be avoided because people will understand what they need to do. It also avoids the stigma of being taught Scrum but then having to abandon it. Staring with Scrum and then going beyond it feels wrong – especially to management who said the team is going to do Scrum and just paid for Scrum training.

We call this approach Scrum as Example because it considers Scrum as an example of what we could do and that we can do other things while still being effective.

I’ll close this article by asing why is it that people do Scrumbut? If we trust and respect people the only conclusion we can come to is that they don’t realize it’s a bad thing. So why don’t we give them the understanding to realize that? When you believe software development needs to be controlled by an empirical process it’s because there is no understanding of it – one can only see it by doing it. There is no model that could explain it. When you believe that Lean-Agile principles can explain it, however, then we show people why Scrumbut is a bad thing and how to avoid it.

Agile Developer Habits 101 – How Will I Know I’ve Done That

I have learned that developing good habits is key in improving my abilities. A series of good small decisions can often prove to be better than infrequent good ones. The most effective way to develop a habit is to have a trigger for it. That is, when an event occurs, do the thing you want to. Otherwise good habits just devolve to good ideas that don’t happen.

One good habit is to validate you understand something that someone has requested of you. In this case our trigger can be a request. The habit is to validate it by asking them what their acceptance criteria is. This doesn’t mean that they are right in their criteria – people often ask for the wrong thing. But a critical first step is to ensure you understand what they asked for.

Habit – validate understanding.

Trigger: When someone asks you to do something.

Action: Ask – “how will I know I’ve done that?”

Intention: Validate that what they say matches what you heard.

Habit – understand their why

Follow up Action: Ask – “and why do you want that?”

Intention: Validate you understand their objective as their might be a different way to achieve that.




Why Agile Coaches Need to Know Both Scrum and Kanban

Scrum and Kanban are the two most popular Agile team-level methods available. While the difference between them is mostly thought to be sprint-based or flow-based, that is just one way in which they differ. Other significant differences include how to start, how to improve, and how people should be organized. They are based on different theories of how to manage software development work and whether you need to change your roles. And this creates other differences such include the amount of discipline to use them and the cultures in which they fit. Continue reading “Why Agile Coaches Need to Know Both Scrum and Kanban”

The Dark Cycle of Scrum and How To Avoid It

1) management tells teams to do Scrum

2) they try but can’t. A common challenge is they don’t know how to break down big epics into small stories (which is often not taught in initial scrum training)

3) at some point they give up and do ScrumBut by not following sprints. They justify not doing Scrum by claiming that they are now doing Kanban (because they don’t have sprints). But they don’t do any of the things Kanban says to do. This is like saying “we do Agile because we don’t do documentation.”

4) their performance goes down

5) Scrum consultants are brought in and management is told the problem is “well, they’re not doing Scrum, can’t blame Scrum”

6) management tells the teams to do Scrum, because Kanban doesn’t work.

The solution is to teach Scrum, when it’s used for software development, with what is necessary to do software development.

The fact that Scrum can work anywhere works against you if you get generic Scrum training instead of Scrum training designed for you.

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.