By Josh Roberts | August 17, 2014 | 0 Comment
This past week we held Kanban training for another part of the organization. We played the Penny Game to illustrate the benefits of smaller batch sizes and limiting Work in Progress (WIP). From Kanban to Scrum, Agile/Lean practices are aimed at bringing greater focus in order to deliver value more frequently.
The game starts with a batch of 20 pennies that represent project requirements. With 5 people, we formed a system workflow modeled after the Systems Development Lifecycle (SDLC). Each person in the system represents an SDLC phase of work: 1) Analysis, 2) Design, 3) Development, 4) Test, and 5) Deploy. Work is performed on the requirements by flipping all 20 pennies, recording the results (heads/tails), and then passing the pennies to the next person/phase.
Mimicking traditional project delivery practices, the game starts by processing the requirements (pennies) as a batch of 20 pennies. Imagine a large project bundled with 20 requirements all to be delivered at once. Typical of most projects, there is a looming deadline and the team is working fast to deliver these requirements. This is where the fun begins…
As each person/phase rushes to process their requirements, pennies are flying all over the table. At times, they are even rolling off the table and onto the floor. Literally, you see requirements falling through the cracks. Through all the chaos, there is uncertainty if all pennies were processed (flipped), let alone that the results were recorded accurately (i.e. with quality).
Traditional project and quality management practices are built to bring order to this chaos. There are elaborate schedules to manage all the work dependencies and Requirements Traceability Matrices (RTM) to ensure that no penny goes missing from phase to phase. Think about all those handoffs. Not to mention all the tooling (PPM software) required to keep everyone aligned and synchronized.
But, what if the chaos didn’t exist? Is it self-imposed? Do these work dependencies really exist and do all features need to be worked simultaneously?
It’s true that we humans tend to overcomplicate things and software delivery is no exception. Most developers have heard of the KISS principle; Keep It Simple Stupid. But, this principle should be applied at all levels of the software delivery organization. Our overly complicated practices/polices are costly to manage and maintain; sustainability requires simplicity.
Over the years, project after project have poured tightly coupled requirements into our systems. Our legacy architectures are a reflection of this behavior, forming the system hairballs that we are seeking to modernize today. We must remember that these hairballs didn’t build themselves, nor was the technology at fault. It was legacy practices that built legacy systems.
“Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” – Conway’s Law
The foundation of Agile/Lean practices is feature-driven development. The goal is to deliver independent features that bring business value. And, the benefits don’t end with more frequent releases of value, but also include:
The list goes on, but perhaps one of the greatest benefits of feature-driven development is that it forces organizations to focus on delivering the things that matter most. When we pile requirements into a project, we often lose track of the original business objectives. We are more focused on managing “The Project” (scope, schedule, resources, budget, etc.) than ensuring that we are delivering valuable features to the business. According to The Standish Group, 45% of the features that we deploy into systems are never used. Can you say… Microsoft Word?
As the IT industry continues to grow in complexity, we must look for opportunities to simplify. A feature focus leads to both sustainable delivery practices and software systems. This simplicity drives down cost and brings organizational agility.
Software delivery frameworks such as the Scaled Agile Framework (SAFe) are based on feature-driven development. The goal of such frameworks is to ensure alignment, synchronization, and communication across an organization. As we continue to evaluate Application Lifecycle Management (ALM) tools, we must also ensure they meet this criteria.