Getting back to the original Scrum

This post begins my series on Getting Back to the Original Scrum.

I understand why people think I don’t like Scrum. I have been struggling with this myself. I have used Scrum for almost 2 decades with great results. But I teach it differently and base it on a different model than the Scrum Guide.

I’ve been realizing what I love about Scrum comes from The New New Product Development Game and what I don’t comes from its redefinition.

Continue reading “Getting back to the original Scrum”

How Scrum creates ScrumBut and what to do about it

 

What is ScrumBut?

Scrum org defines “ScrumBut” as “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.”

Continue reading “How Scrum creates ScrumBut and what to do about it”

Why I hate the term ScrumBut

Scrum org defines “ScrumBut” as “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.”

Scrum assumes that people doing Scrum stay within the confines of Scrum’s immutable artifacts, roles, events, and rules. However, when problems arise there are times that they can be solved with methods outside of Scrum. Sometimes, the cost of accommodating them is lower than the cost of fixing them. If you want to be doing Scrum you can’t do the first and Scrum gives no guidance on the second.

Continue reading “Why I hate the term ScrumBut”

Getting to cross-functional teams

Self-organizing, cross-functional teams are good when it is possible and advisable to achieve them.

The question is how do you create them? I tend to look at the edge conditions because I believe that when you learn to handle difficult cases you also learn how to manage and teach the easier cases even better.

Continue reading “Getting to cross-functional teams”

We shouldn’t be surprised by Dark Agile. We should be surprised it works as well as it does

Our Agile at scale methods are often like driving on the wrong side of the road in reverse during a rainstorm. While the driver’s are well intended, and may even appreciate that at least they’re in a car, that are better ways. Here’s a list of things we must do that are usually not done when attempting Agile at scale.

Continue reading “We shouldn’t be surprised by Dark Agile. We should be surprised it works as well as it does”

How Successful Pilots Often Actually Hurt an Organization

Originally posted October 3, 2010

It is seductive to think about scaling Agile up from teams to the enterprise. It seems the correct path to take because you can almost always find a team or two where Agile methods lead to great improvements over Waterfall methods. But what works for a few teams at the local level often obscures the bigger picture: creating enterprise agility. Enterprise agility is the ability of an organization to deliver value quickly when needed. Sadly, I have seen many organizations achieve many successes locally – team agility – and move even further away from enterprise agility.

Continue reading “How Successful Pilots Often Actually Hurt an Organization”

Why we want to focus on Flow while using Lean and Agile

While the Agile community is finally starting to embrace Lean it’s still behind the curve. The real target is flow via business agility – the quick realization of value sustainably, predictably and with high quality.

Even this is no longer cutting edge. Donald Reinertsen’s Principles of Product Development Flow is over a decade old. Agile’s recent adoption of Lean is good but it still is a bottom-up approach. Thinking in terms of flow creates a better context and will put you years ahead of current, common thinking.

Continue reading “Why we want to focus on Flow while using Lean and Agile”

A thought experiment to help you decide on an effective course of action

Consider how your organization is currently developing products and/or services. As a thought experiment, consider how to make things worse. For example, have people work on too many things, don’t have a process where you resolve multiple requests, have product managers create requirements

for the team and just hand them off in written form, have developers and testers be in separate organizations, have managers makeup schedules and then berate developers when they are not met, … You get the idea.

I’m pretty sure you can see that things will get worse. Now, consider where in your organization you are doing some of these ineffective things. Could you stop doing some of them? Even partially? If it became worse when you started doing these wouldn’t it get better if you just stopped doing them? Sometimes improvements are easier to achieve just by stopping doing things incorrectly.

Of course, making these changes is no guarantee of improving your process, but generally, improvement will occur if you do them. As always, you must run any improvement as a hypothesis of it being a better way and validate that it is.

Learn more at Understand Your Options.

If you’re having problems sequencing your work items, this is most likely why

There are several concepts needed to do this:

  1. The items to be sequenced must be both the smallest batch of work that can be realized by the customer. They must also include all the work items required for the realization. Note that epics are too large, MVPs are about discovery of what’s of value and features often do not realize value on their own.
  2. A vision on what we’re trying to achieve that the owners of the work being prioritized can agree one. This has to take place at the leadership level.
  3. A way of comparing two items based on cost-of-delay and time to complete.
  4. Being able to implement the items quickly in the order they are sequenced. This provides motivation for the other two. This requires working on smaller sub-batches of this work. Having 3 months of work will not get us to attend to the delays between teams.

Whenever I see people having problems with prioritization, I know one or more of these items are missing.

What’s obvious or quickly learned as it’s pointed out #3

#developer. When you finish something look for something else to help folks finish. See Manage Work-in-Process (WIP) by Focusing on Finishing

I tag each insight with one or more roles that it will relate to. I will provide a link when more information is available.

You can see the accumulated insights here.

The best way to get these as I add to the list is to subscribe (see upper right of this page).