Maintaining the Flow Gates

WIP limits and the idea swarming around completing original commitments ARE compatible with the desire to promote continuous “flow”. Limits help promote focus on planned work (aside from things like hotfixes or emergencies) by setting “gates” to when work can be pulled into a sprint. That focus alleviates bottlenecks, identifies true throughput, and gives a more complete picture to what a team can do.

Maeslantkering - storm surge barrier

For example, Team X was pulling in an average of ~75% scope increase halfway through their sprint. That means that something was either not planned correctly or they just kept pulling in work when devs finished their part. Pulling in work is FINE (because it should be accounted for), especially if the sprint was originally planned within the velocity expectations for the team. BUT a team can’t keep pulling in work if the process is becoming backed up at some point. And, sometimes the new work was even getting done before the originally committed work was getting done!?! There has to be a point where we say “hold up… let’s clean things up before shoveling more on.”

I liken these observations to two things:

• I order one pizza… but my pizza is late because the place decided to give me a free calzone too. And the calzone comes out first, potentially delaying the pizza that I ordered an expected in the first place.

• Or I dug a hole to lay cement near a stream I have dammed-up which will need repaired in a couple of weeks. - I expect a certain amount of water to collect in the hole, and I have only one sump pump available to handle the water. But, my contractors decide it’s time to work on dam repairs - which is next on the list… but more water than my pump can handle rushes into the hole, and this delays the laying of the cement - causing a headache.

Some groups may or may not ever reach this type of a point of hard limits, swarming, etc. in the near future. But, what is important is that key players utilize tools and math (metrics) to drive and expand the conversation - showing that what is worked on is measured in numerous ways. HOW something is worked on, impacts iterative delivery and releases of a team(s). - Having these KPIs visible and complete shows the whole story and helps closely related feature teams level-set (rather than live in silos).

In all, in every framework… it isn’t about the process itself… but, the outcome of the process. A question could be: are we delivering effectively and then inspecting & adapting/adjusting the process to keep doing so?

Usable, timely, quality, and value delivery is what is most important. The process should create a clear and observable superhighway for teams to travel from idea/request to delivery.

Finding The Right Agile Framework

There are 50+ different agile frameworks of varying popularity and many questions about them. Some common questions include: What are the frameworks? Where’d they come from? Which one is best?

Which framework should I use?

Answer: None of them or all of them.

Agile frameworks all seek to define a processes behind delivery of something. They seek to bring order to disorder. They offer varying degrees of insight and contingencies. And in many cases, agile frameworks introduce a lot of extra cost & waste.

The Problem with Agile Frameworks

The problem with pursuing a one-size-fits-all approach to using a define agile framework is complex, but it can be distilled to two main points…

1. Implementing a pre-packaged or defined framework will not expose organizational or process issues. It will AMPLIFY them.

2. Don’t get stuck trying to fit a square peg into a round hole. An organization and its teams are unique. It is important to utilize an agile methodology or framework that is both a “best-fit” and scalable.

Agile frameworks have, in many cases, veered so far from the core tenants of agile delivery — that they’ve become anti-agile. In many cases, work is done, but potentially not shippable… handed off… reviewed. Cycles are spent… new sub-teams are created. Process oriented meetings occur… and so on.

• Does it make sense for a small software startup to use the same agile practices as Toyota? — No.

• Should a highly effective organization go through an agile transformation to a framework like SAFe, just to introduce contingencies such as “release trains” — Absolutely not

I am not saying that all frameworks get it wrong. In fact, some of the frameworks excel in their scaleability! Again, frameworks define a processes behind delivery and seek to bring order to disorder. Frameworks are necessary.

The issue is the starting point… the way of selecting & using the right framework. A “silver bullet” framework does not exist. And, what works for one does not work for all. So, in selecting a framework, it is imperative to fully understand what it means to be “agile”.

What’s Important

Being agile does not mean playing fast & loose. Being agile means focusing on delivering value; even if that means making adjustments. A framework can help facilitate delivery & define the related processes.

The main guiding principles of the “Agile Manifesto” are:

- “Individuals and interactions over processes and tools” - “Working software over comprehensive documentation” - “Customer collaboration over contract negotiation” - “Responding to change over following a plan”

Using a Pre-packaged Framework… or not.

Using the wrong agile framework can be detrimental to success. It is important to consider the following:

• Will the framework help the organization & teams adhere to the meaning of agile?

• Does the framework help promote, or offer outlets for, the analysis of team performance?

• Is the cost of implementation/overhead of a given framework feasible or worth it at this time?

• Will the scalability of the framework positively affect organization or teams over time?

If you answered no to any of the questions above, then you have two options.

• Shop around. If you are intent on using a pre-packaged or pre-defined agile framework, there are plenty to chose from. There are also plenty of accompanying training courses & “certifications” available to take your money.

• Build your own. Why not build your own framework? It could be a small framework, or a large/complex one. It could be totally original, or use parts of other frameworks which make it “best-fit” your organization or teams!