A Map of Lean Agile Accelerators I Use

When ever the Deloitte LEAN crew helps our clients delivery business applications we typically reach out for a familiar set of practices, principles and thinking tools.

As a first step towards explaining how Deloitte LEAN approaches delivery I mapped out some of the concepts we tend to fall back on.

Explaining why Limiting WIP is so important

According to Kanban limiting Work In Progress is a foundational component that enables knowledge workers to engage in continuous improvement. But why? And how do I explain the need to limit WIP to execs and other decision makers that need to be convinced?

Here's the arguments I've been presenting..



Limiting WIP leads to a virtuous cycle of improvement. Multi tasking goes down, feedback goes up, errors are easier to catch, work becomes easier to break up into smaller prices, which makes it easier to limit WIP, which mean multi tasking goes down, etc, etc,etc



Limiting WIP is extremely important to ensuring maximum throughput in any systems that face variability. This has been proven in relatively stable systems like manufacturing assembly lines. It's exponentially more true in dynamic systems like software delivery and integration. Think of a highway, when WIP is to high you get a traffic jam, at the same time ifthe highway is empty you get no throughput, there is an optimization at play here. But this is a bell curve, 100 full WIP is never the answer


Limiting WIP exposes bottlenecks in your process, when inventory is low, and a particular process becomes blocked or produces defective work, it causes downstream processes to become starved of work. This is a good thing, it's a signal to fix your system of work. Yes, work will be delayed in the short term, but only long enough to improve the system of work, which will accelerate throughput over time.

The Three Feedback Loops of eXtreme Programming

With all my talk about Kanban, people might think thats all I use to help clients be successful.

Nothing could be farther from the truth, whenever I run delivery projects I whip out the technical practices in full force.

eXtreme Programming becomes my reference in these cases. I certainly dont think I'm doing anything to move eXtreme programming into new places, but thought Id share some visuals I use to communicate XP to unfamiliar audiences (yes they do exist).

The Three Feedback Loops of eXtreme Programming

For me eXtreme Programming is all about feedback. When done well, everyone on an XP team knows when something is broken, and they can immediately fix it.





Pair Programming
Feedback loop one is accommodated by pair programming, and by switching pairs. As a team lead I've never had more confidence of good technical quality then when I saw my entire team using this practice, its just so much easier to keep the style of the code consistent, the metaphors aligned, and to spot code cruft.

As a program lead, I am much more comfortable leaving daily decisions to teams that use this practice, I know my product is getting the benefit of the wisdom of the crowd. Critics point out that Pair Programming takes longer. I tried it for myself three years back. I conducted an experiment where The Observer had to ring a bell every time the Observer helped the Doer overcome a hurdle or make a decision faster than the Doer could have done on his own. The Observer was ringing the bell every 10 - 30 seconds. while not exactly science, it convinced me.

Test Driven Development

TDD is another agile practice that took me years to appreciate. While I started my agile journey with agile tools like JUnit and Cruise Control way back in 2001, I really was not following the TDD mantra.

I built lots of tests, after I coded, I often abandoned the tests half way through the project, and then started agian on the next project hoping to do better.

It took me years to evolve from Plain Old Unit Testing (POUT) to appreciating Test Driven Development (TDD). Once I got immersed I could never imagine going back



What makes TDD not just another test automation approach is a few key innovations:

1. Write the Tests first, they are your design spec and fine grained requirements all in one
2. They work because they are small, and match the design of well factored code, in fact TDD demands it or you wont keep up with your tests
3. You need to code, good tests demand SOLID OO engineering, not WYSIWG generated tests
4. Test, Code, then Design. TDD backed code is truly faster to redesign than most up front design work, code becomes like clay in the hands of a good TDDer.

TDD works becaus the majority of testing effort is applied at the micro level. Like all good architecture, reuse is enabled by creating fined grained tests that test fined grained code. When something breaks, you know what and where.

While high level tests have a purpose, they should be thought of as extra insurance, most errors are caught well before a macro test could fail.


Higher level tests can take advantage of Behaviour Driven Development, and extension to TDD that focuses on expressing requirements in a testable and automatable format.


Continuous Integration


Continuous Integrations helps synchronize across team members. Provided that TDD is working well, CI ensures that when code is checked in it is tested against the entire code base, packaged, deployed,etc. Any errors are sent to interested parties so that the team can swarm on the issue and fix it right away. Setting this up can take some doing, but i have always found it to be worth the effort.


In order to be successful with things like TDD and CI i found it necessary to focus on a parallel testing and build architecture. One that focuses on what tools to use, what level of tests will be built, how mocking and stubbing will occur, where automated runs occur, and other critical details. A good testing architecture is one that promotes the building of fine grained tests that can be executed quickly.