Al Shalloway

This article presents a different way of looking at lean software development; one that is independent of lean’s manufacturing heritage. It begins by presenting lean as a collection of a body of knowledge applying lean principles to software development.

If Agile is going to make a difference to an organization, it must accomplish two things. First, it must assist us in being driven by business needs—not the development organization. Second, it must help us with the entire value stream—not merely part of it. Lean-agile practices presents us with an opportunity to reunite the business and software development organizations so our Application Lifecycle Management (ALM) can focus on value, not merely delivered software.

Life used to be simpler. In the early 2000s, if you wanted to go "agile," XP was the route of choice. And then Scrum became popular. And it was not too long before organizations began to hit the limits of these approaches due to their focus on teams. And then it became apparent that lean principles could be applied to software and Lean Software Development and later Kanban were added to the mix. Now, you have a great many choices: Not just about which method to use, but where to start, whether to go top-down or bottom-up, and what should be the scope of your effort.

Product portfolio management has become an essential discipline for all development organizations that want to achieve enterprise agility. The repeated process of selecting, sizing, and prioritizing the work to be done ensures that their development teams are delivering the most valuable products and enhancements for the business’ clients. This is required for both external clients in the case of product companies and for internal clients in the case of IT organizations. However, the subject of this paper is another, possibly even more important, reason: avoiding the overloading of the organization’s development teams which greatly lowers their efficiency.

It is easy for a team to transition to Lean-Agile software development: Pick a good pilot project, get some training, re-arrange the workspace, learn the process, maybe use a coach. It has been done thousands of times. It is easy but all too often, there is no benefit for the organization. The goal is not making teams agile but making the business agile. This is a bit harder. Build your transition plan around the business and everyone—customers, business, and teams—will succeed.

Agile works. Early adopters, working largely by instinct, have seen good success. To go to the next level, instinct alone is not enough. As we face more complex and uncertain environments, as we face the need to scale to the enterprise, we need to apply intelligence and knowledge, guided by experience. Knowledge about why Scrum works.

When attempting to adopt best practices we often can't see the forest for the trees. We can see what we are doing wrong, but how will that help us to see what to do right? In this article, we will discuss a few common Lean Anti-Patterns. Anti-Patterns are commonly recurring practices that are counter productive. We call them "Anti-Patterns" because these anti-patterns result from violating Lean principles. Lean principles form the basis for Scrum practices. Looking at how Lean Anti-Patterns violate lean principles gives us insight into how we need to modify our practices to be more effective.