Stop Abusing Agile

Bob asked, “Is the project on schedule?”

Will said, “We do Agile. We don’t follow a schedule.”Bob was left wondering how he might report this to the governance teams.

Cathy asked, “What scope will be delivered in the next 2 months?”

Joe answered, “We are agile. We do not estimate all work upfront. All I can tell you is that we complete 50 story points each sprint.” Joe had no idea on how much time the remaining work would take and more importantly if all the remaining work was identified.

Maybe you’ve encountered a variation of, “We don’t do ____ since we follow Agile”. Fill in the blank with an ask. As an executive, a project manager, or anyone who’s part of the enterprise governance process, you are left wondering if implementing Agile was the right thing to do. The perception that builds up with these conversations is that Agile does not involve planning and it's "flying by the seat of the pants". Nothing could be further from the truth.

It pains me to see agile butchered and maligned so.

Agile’s Focus on Flow

Agile, Lean, Scrum, DevOps, Theory of Constraints, ConWIP, etc. - call it what you will! At the core, the main purpose of agility, either implicitly or explicitly, is to identify bottlenecks to flow of work so that appropriate actions can be taken to improve delivery times.

The purpose is achieved by breaking down work into small chunks and delivering iteratively or incrementally. Blockers are to be expected. They come in all shapes and sizes. Let’s look at the top 4 key blockers to delivery times.

Defects

This is self-explanatory. Defects mean you have to go back and invest more time to fix issues. For knowledge work and software engineering, there’s experimentation when learning happens. That’s fine. But fixing defects when in production takes time away from delivery of new product features.

As more time is spent fixing bugs, product development lags behind. This causes management to think of creating a separate support team to enable the development team to focus, thereby causing DevOps to fail.

Gold-plating

We are all guilty of this at some point. Adding in extra features that may not be relevant or used immediately is at the expense of increasing cycle time of other product features that are needed.

Wait

If you have worked for any length of time, you’ve encountered this. Either you are waiting for work (clarifications, requirements, people, etc.) or work is waiting in a queue to be picked up.

Long wait times increase delivery times. Are you tracking your team’s queue size or work cycle times? Is there such a metric for performance measurement? Handoffs are a huge part of this problem.

Enterprise structures encourage skill-silos in an attempt to improve utilization. You will find some of the longest wait times in this type of organization structure. While a fully cross-functional self-contained team is the key to eliminating hand-offs, it’s expensive and a balance between effectiveness and utilization needs to be achieved.

Excess work-in-progress (WIP)

The foundation of all agile methodologies or frameworks is the reduction of WIP. Scrum limits WIP in timeboxes. Kanban limits WIP by queue size. Ignoring WIP limits causes context switching - higher WIP means more context switching leading to increased delivery times.

If you’ve never heard of Little’s Law (assuming a statistically stable system), now’s a perfect time to read up on it. Essentially, in the context of IT, Cycle time = Work-in-progress/Average Completion Rate. There are nuances to its application, but if used correctly I find it drives the right behavior.

To reiterate, the intent of all agile methodologies is to unblock the impediments to flow. I’ll use Scrum and kanban examples on how they help unblock since they are the often quoted as the process of choice.

Scrum

Using Scrum, sprints are supposed to control WIP. Teams are expected to take on only so much WIP that they can deliver in a sprint. However, if the scope of deliverables is changed within a sprint, the intent of limiting WIP is not met (swapping one story for another does not count either).

If work is not sized properly, the team either commits to more than it is capable of delivering resulting in unmet sprint goals or under-commits resulting in lost productivity.

By not having cross-trained team members, you run the risk of work waiting on individuals.

Not having a customer (or product owner) review the work at the end of the sprint could potentially result in re-work downstream (both expensive and increases delivery times).

So, if Scrum’s your preferred agile methodology, understanding the intent of its processes, respecting prescribed roles, responsibilities and rituals are important to achieve desired outcomes.

Kanban

The other system whose implementation I’ve seen butchered is Kanban. Kanban is a just-in-time pull system.

Instead of focusing on batch sizes (like Scrum), it focuses on continuous flow. (For the Scrum die-hards, think of Kanban as a one day Scrum).

Kanban is a Japanese word for “signal” and has its roots in Lean manufacturing. Instead of traditional working style, where a schedule drives work (remember Gantt?), in a pull system, availability of resources and individuals to do the work drives work completion. It is important to note that a visual board is just that - a visual board. In order to convert a visual board into a Kanban, three necessary conditions need to be satisfied:

1. The visual board must map the current execution process
2. WIP limits need to be established for each process step
3. WIP policies must be established along with a commitment from each stakeholder group to respect WIP limits and policies.

A visual board that does not map execution process enforces WIP limits and has explicit WIP related policies is NOT a Kanban system. It’s just a visual board.

So Are You Agile?

So what’s Bob and Joe to do? How can they tell if they are being led down the right agile path?

First and foremost, understand that high levels of WIP translates to longer queues and context switching, which leads to increase in delivery times. Long delivery times eats into your organization’s margins. Both the technical and non-technical stakeholders need to understand this simple but critical concept for successful agile adoption. Next, get to a common definition of what an agile mindset means for the organization. Here’s how I define the agile mindset. No matter what system you use, while not exhaustive here are some questions for a quick gut-check on your agile journey:

1. Is the Product Owner prioritizing work based on economics (agile mindset) or does the squeaky wheel get the grease (traditional mindset)?
2. Does the system enable your team to quickly identify impediments to flow and fix them before they become raging fires (agile mindset) or does it take weeks to identify and fix them (traditional mindset)?
3. Are you delivering frequently (ideally between 1 and 3 weeks) into the hands of your customer (agile mindset) or does it take months (traditional mindset)?
4. Are you getting frequent feedback on your deliverables (agile mindset) or do you only get feedback at final delivery (traditional mindset)?
5. Are you increasing predictability on your deliverables based on cycle time (agile mindset) or are you following a schedule (traditional mindset)?
6. Are you meeting deliverable commitments at the expense of another or are you finding that the team’s working overtime to deliver based on a schedule (traditional mindset) or are you using empirical data like cycle time to set delivery expectations (agile mindset)?
7. Is the team responsible for making delivery decisions (agile mindset) or did the project manager create a Gantt that drives decisions (traditional mindset)?
8. Are you noticing a correlation between your queue size and delivery times (agile mindset) or are you blind to queues (traditional mindset)?
9. Are you using agile metrics geared towards promoting the agile mindset or sticking with metrics that drive behavior to reinforce the traditional mindset?

Answering some of the above questions will also solve Bob and Joe’s governance dilemma.

In summary

Agile is not a silver bullet for your delivery woes. While it is a lot of hard work and requires discipline, the rewards are an engaged high performing team eager to take on the next business (or technical) challenge thrown at them.