Part 1: Stop starting stuff and start finishing stuff

In this 3-part series, I'll cover how too much work-in-process leads to hidden waste at the individual, release, and enterprise levels.

I've been thinking a lot about Scrum, how lean relates to Scrum, and how to express what I see in such a way that it doesn't sound like I am attacking Scrum.

I have never been trying to attack Scrum. Rather, I've always been talking about how you need Lean, etc., and, unfortunately, some people have interpreted that as an attack. In reviewing some of the work I've done over the last few months, I have seen some companies take on applying Scrum to a few teams with very good success.  At this team level, Scrum works well.

This is not new. I have said this before. But it got me thinking - maybe it's fair to say when you look at Scrum and Lean at the team level, they are very similar. The differences lie more at the enterprise level.  At the team level, I would say Scrum is almost a perfect manifestation of Lean principles if one confines "the whole" to the team and if you ignore that the batching of stories in an iteration is not exactly "perfect flow" (but has other advantages). For example,

• Using iterations is a way of deferring commitment, creating knowledge, delivering fast, and eliminating waste (discovering what not to build thereby avoiding building unecessary things). 
• Iterations follow good queuing theory (limiting work to capacity), minimize work in process and use pull methods in sprint planning. 
• The focus on the team is a way of respecting people - letting them figure out how to get their job done - and management is supposed to help them.
• When you add good engineering practices - Test-Driven Development, proper use of design patterns - as we recommend, you also follow "build quality in." 

So I agree it is not correct to say Scrum is inferior to Lean. I do say that the practices that Scrum puts forth are about how the team works.  Once you want to extend Agile beyond the team one should look at principles that will help guide you.

"Economies of Scale" is a phrase that is often mentioned as a desirable state for growing enterprises. After all, being large enough to drive cost down by sheer purchase volume is a logical progression of successful companies. But what is the price paid for achieving this milestone? This blog post exposes hidden waste that must be controlled when economies of scale take over.  I'll touch on how Lean approaches can prevent and eliminate the wasteful belief systems that clog the flow of product delivery.

 read more »

With the holidays coming on, many of us are heading up to the attic to retrieve the boxes of decorations that have been waiting all year to be called into service again. In my family we put up and decorate a Christmas tree each year, but I suspect Hanukah and Kwanza, etc… have their festive ornaments too, and probably electric lights are involved.

One thing I'll do this year, as I do every year, is to lay out the strings of lights on my coffee table and plug them all in, to see if any of them fails to illuminate.

I’ve been reading “Managing the Design Factory” by Donald Reinertsen.  There is an interesting observation he makes.  In manufacturing, you know all of your requirements up front.  Whereas, when you are doing design, you know very little up front with most of the requirements being known about a third of the way through.  Don’t get hung up on exactly when you know – as long as you agree that in designing a product, you don’t know it all up front.

This weekend was the fitting climax for my having attended and presented at two conferences in the last couple of weeks.  First, was the regional Much Ado About Agile presented by Agile Vancouver.  Second was my favorite conference of the year, SQE's Agile Development Practices.

Much Ado About Agile was a pleasant surprise.  More attendees than I thought and a great group of presenters – including David Anderson, Ken Schwaber, Sanjiv Augustine, Philipe Krutchen, David Hussman, Jim Shore and others. I'm afraid I couldn't attend as many sessions as I would have liked to but I liked what I saw. 

I've been working on some Microsoft Team Foundation Server (tm) (TFS) reports for a team at Microsoft. A report publishes the results of an MDX query. The latest report I have been working on is complex enough to need some VB code. There are lots of examples of how to pass the individual fields from the query to the VB code, but I had to search and interpolate to come up with how to pass the entire Fields set (not technically a collection) to the VB Code.

 Managing Multiple Team Projects in VSTS (audio of the webinar)

Many Agile/Scrum projects have more than one team, but few Microsoft Visual Studio Team System (tm) Process Templates address the issues of managing multiple teams pulling from the same product backlog. The Implementing Agile Development process template provides the data, reporting and team communication features to manage the multiple team project successfully.

On October 16, Rod Claar gave a webinar discussing how to manage multiple team projects using VSTS. He discussed and demonstrated the following features of the IAD process template.  read more »

 Transition Testing - The Cornerstone of Database Agility (audio of the webinar)

Comparing Two Patterns: Adapter and Façade

(Note: if you are unfamiliar with these patterns, you can read about them at our pattern repository)

One reason people often struggle to understand how to get real value from patterns is that sometimes two or more of them can look, at first glance, extremely similar. When I'm teaching patterns, people will very often point out how similar the Strategy and Bridge patterns are, or the Decorator and Chain of Responsibility, or the Factory Method and Abstract Factory, etc…

Usually this is because people often confuse the example of the pattern that's being presented to them with the pattern itself. Patterns are neither UML diagrams nor code examples; they are a higher concept that captures best practices, domain and implementation forces, and the consequences (both benefits and costs) of certain decisions. Diagrams and code are simply representations of the patterns, and are always more specific and narrow than the patterns themselves are.

This misunderstanding is an opportunity, however, because when we compare two patterns that appear similar and determine how they are actually different, we can sometimes dramatically enrich our understanding of them.