At the Lean/KanBan Conference on Thursday 5/7, Eric Willeke of Inkubook gave a unique, purely visual, well received presentation about Inkubook’s journey to Kanban. They eventually progressed to a mature Kanban approach, with a visual board, strict Work-In-Process (WIP) limits, and short lead times. As a result of a massive layoff, the business analysts were let go and the company size was cut in half. On the positive side his team started to communicate directly with marketing and the now much smaller team was able to swarm, and instinctively keep WIP low, without using the physical Kanban board or setting explicit WIP limits. His talk reminded me of high performing teams of old (I presented on just this topic at the March 3rd Agile Philly Meeting), as such, this blog is about those teams and what we can extrapolate from their experience.
Historical Perspective
In my 25 year professional career, I have seen software teams that have performed at exceptionally high levels by following what I will call a continuous flow approach. For the sake of this blog posting, continuous flow software development can be defined as a software development model where highly collaborative teams work on a small number of tasks at a time, often swarming, to take work from inception to production in very short time frames.
What might be surprising to some, is that some COBOL maintenance teams were early practitioners of this modern approach, many of these teams date back to at least the early 80’s (probably earlier, but I have not personally seen or read about them).
Maintenance teams often had to understand the interaction of thousands of lines of code, just to fix a single bug, and they were frequently under pressure supporting mission critical systems. As such, the best developers were often assigned to maintenance, not to new development!
Typically, team members had many years experience working in one industry, and often for one company. As such they acquired an in depth understanding of the business they supported. They also built close relationships with business peers, meeting on an almost daily basis, often sharing lunch, and frequently meeting outside of work. In short, they were anything but isolationist computer geeks. Since the COBOL language, and the mainframe environments on which they ran, evolved slowly, the programmers were experts with the tools they used, and their many years in the industry allowed them to be experts in the domains and systems they supported.
These teams were small, and they were able to deliver into production with the only requirement being sign-off from their business peers that the system was ready. The team members could do business analysis, design, and systems testing, along with coding, while following a highly agile, continuous flow process. The team members seldom worked in isolation, they pulled in bugs to fix based on input from the business, and they often swarmed on a single bug to quickly complete it.
Practical Applications
From a practical perspective, the historical perspective on high performing teams gives insight that is still valuable today.
It further emphasizes the power of the generalizing specialist concept. A generalizing specialist is a term coined by Scott Ambler, to represent individuals who are a good at many things and a master of a few (as contrasted to a generalist who is not a master of anything). I don’t discount the value of specialist, but having some generalizing specialist on the team can result in significant improvements in productivity by providing flexibility on task assignments and simplifying communications (i.e. multiple team members can speak each others language).
Along a similar vane, it demonstrates that swarming is an effective approach. In general swarming helps improve short term effectiveness by leveraging the skills of specialists and decreasing WIP, and it increases longer term effectiveness by increasing knowledge transfer. This knowledge transfer can over time, result in the generalizing specialist as defined above.
Finally, it provides further clarification that keeping WIP to a minimum, pulling work when the team is ready (instead of having it pushed) and emphasizing fast turn around is a natural and effective way to develop software.
WIP limits are core to Kanban, but they also apply to Scrum. In fact, a story point limit on a Sprint Backlog is a form of a WIP limit on what enters a Sprint. You can go one step further with WIP limits by placing them on features, tasks, or both, to control how work is executed within a Sprint.
As an example, you can set a task limit equal to your team size multiplied by 1.5. Thus if your team has 8 members, you would never allow more than 12 tasks in flight at any one time.
Among other things, WIP limits will decrease the thrashing that is created as individuals start a task, then move to another before it is complete. The WIP limit will also make it easier to track progress within a Sprint as your burndown charts will be more meaningful earlier.
You can start applying the concepts immediately by evaluating current WIP and providing input to the team if the number of in-process features or tasks exceeds a reasonable limit, such as more than 2 open features (obviously dependent on the context of team and feature size) or more than 2 open tasks per team member.
Closing
Much of what is new, is an extension of what has proven to work in the past, so if you are not already applying them, consider the concepts of generalizing specialists, swarming and WIP limits to improve the effectiveness of your teams.
