One of the key ways to keep work moving forward is to avoid working on too many things at the same time. Ideally, a person should finish what they’re working on before starting anything else. Similarly, a team should complete the work item or ticket or story (or whatever they call it) they’re working on before picking up the next one. At a larger scale, a software delivery organization should limit the number of projects in flight concurrently, and strive to “stop starting and start finishing,” as David Anderson put it. That’s what portfolio management is for (among other things).
In collecting information for the ebook, Choosing an Agile Scaling Framework: A handbook for decision-makers, I was surprised to notice that the Kanban Method kept bubbling up to the top of the list of choices in nearly every scenario. For every business need except one, it was the best or one of the best choices. (The exception is the case when the organization only intends to pretend to change. For that purpose, less-expensive alternatives are available.)
Why would that be true? I wondered.
It’s a commonplace to say there is no “silver bullet,” and everything we do in the software field has to take context into consideration. In fact, this is quite true. TDD is a useful technique to know. To know TDD well, you must understand why and when it is useful, and how to do it correctly. If you apply TDD for the wrong reasons, in the wrong places, or in the wrong way, then it will not yield any value.
Many of the complaints people raise about TDD and about unit testing in general boil down to a misunderstanding or a misapplication of practices. Some complaints, however, are completely valid. You have to make your own professional judgments about such matters. To be equipped to make such judgments, you need to understand how TDD can add value in your work; and when it will not.
Continue reading Looking at TDD through a lean-agile lens
Many larger organizations are considering adopting an Agile scaling framework to help them extend contemporary practices beyond the proof-of-concept stage. Plenty of people stand ready to help them choose an appropriate framework. Or maybe it’s more accurate to say, to help them choose the framework the helper wants them to choose.
I put together a short ebook that addresses the problem of choosing a framework from the point of view of someone who has no product to sell and doesn’t care whether you use a framework at all. Maybe it will help you and maybe it won’t, but either way it’s cheap, and it doesn’t try to sell you anything. See https://leanpub.com/choosing-an-agile-scaling-framework.
In the movie, Now You See Me, a certain idea was stated multiple times, phrased in various ways: "Look closely, because the closer you think you are, the less you will see." In the past decade, a lot of people have been inching closer and closer to something called "agile," and most of them are pretty sure they can see it.
Things are very different on each side of the "hump" in the diffusion of innovations curve. On the left side, the early side, where the Innovators and Early Majority adopters live, people tend to be forward-looking, open-minded, imaginative, proactive, and willing to take risks. On the right side, the late side, where the Late Majority adopters and Laggards live…well, not so much. Some people are interested in the left side, because that’s where breakthrough ideas are vetted in the proverbial fire of the (possibly over-rated) Real World. Others are interested in the right side, because that’s where methods and practices become scaled, integrated, and institutionalized to support large enterprises. Continue reading The Shimmering
I’m honored to be included on the program of an event that features so many luminaries in the field. My small contribution will be a session entitled Structural Impediments to Lean. The premise is that the conventional organizational structures and basic assumptions regarding roles and procedures tend to present obstacles to the effective use of Lean thinking in companies. It’s a subject I started to explore in earnest a couple of years ago at Lean Kanban Europe 2010 and have continued to explore in my work since then.
Here is the session description from the program.
Lean thinking is based on a model of delivery in which raw materials are progressively developed into a finished product that is consumed by a customer. This linear path is called a value stream. Many in the software community have criticized this model as too simplistic at best, and harmful at worst, as it risks ignoring key stakeholders by focusing on "the" customer.
In real life, a software product has many stakeholders. There may be multiple customers who have different needs and different usage patterns for the software. There may be people involved who are affected by the functionality or quality of the software product who are not, strictly speaking, customers. The process of building and delivering a software product is far more complicated than a simple, linear "stream" of activities. For those reasons and more, some people prefer the term value network to the term value stream. Continue reading Value streams and value networks
In helping organizations achieve their goals for process improvement, I have found the single most prevalent conceptual barrier to be the notion of throughput as opposed to resource utilization. Many, and possibly most organizations hinder their own process improvement efforts when they try to maximize individual resource utilization rather than trying to maximize throughput. Once they are able to move beyond utilization thinking, many other challenges fall away naturally.
Continue reading Utilization thinking vs. throughput thinking
I have learned quite a lot from reading Lean Software Engineering, a website authored by Corey Ladas. Although I am not personally acquainted with him, I have gained a great deal of respect for his thinking and his experiences in applying lean principles to software development.
My growing respect for him may be the reason I was struck by a comment of his that I came across recently while browsing the site. In a response to a reader’s comment dated January 7, 2008, he wrote: “Pair programming is antithetical to Lean” It was just a flat assertion with no explanation.
I was puzzled. Lean software development doesn’t speak to particular development practices, as far as I know. What might cause a practice to be antithetical to lean or, for that matter, to support lean? The only basis I could think of on which to reach such a conclusion was that the practice either hinders or helps us in applying lean principles to software development. Corey did not provide the same level of careful analysis and explanation as he does with most of the useful material on his site, so I decided to reason through the question myself.
Here is a somewhat exaggerated and sanitized description of a situation I encountered on a coaching engagement.
The stated problem was that the software development teams in a certain department were taking too long to deliver and the results tended to have more defects than was deemed acceptable.
Continue reading A strategy for lopsided teams