Heather McLean

“Waste”—it’s an ominous word by itself, and in the world of Lean principles, it’s the one thing you’re striving to eliminate. Waste can be defined as that which adds no value to a project; i.e., those things that you are spending time and money doing, but they don’t move the project forward. Software projects are often full of waste, and in such an imprecise discipline, it can be difficult to identify the sources of waste. In fact, a lot of times we end up running in circles, attempting to clean up the symptoms rather than the causes.

In my experience, the one largest source of waste that can be eliminated or reduced to add immediate benefit to a project is rework¹. Rework falls into two major categories:

• Technical debt
• Defects

Read the rest of this entry »

A coworker recently turned me on to the Google Tech Talks Channel on YouTube. There is a wealth of good information on many different topics. In particular, I found this presentation about leadership from Mary Poppendieck especially insightful this morning:

It seems that no matter what aspect of software development in which you’re involved, someone is always starting a holy war.

I found David Anderson’s post, Trashing Scrum or Reflecting Reality?, amusing. Not because it was humorous, but because it’s in response to the same sort of war we see time and time again. This time, it’s the Lean radicals versus the Scrum purists.

One thing I can’t stand is people who have a myopic view of things that they consider “correct.” Yes, I agree that Scrum is a wonderful tool for helping teams succeed. Relative to the waterfall way of doing things, Scrum can provide visibility and productivity increases that are almost undeniable for most teams. However, like everything, it is not the end of the journey.

In order to truly appreciate Scrum, one cannot assume that it is sacred. Scrum is about adaptability above all else, so the idea that Scrum cannot be improved, extended, or even superceded is absolutely ludicrous. One of the very reasons I created this blog was to examine agile and lean methodologies to get the most out of them, and if that means “trashing” a particular ideal, then so be it. Personally, I would rather trash Scrum than assume it is perfect.

Also be sure to read Alan Shalloway’s article, Is Scrum Failing Us?, linked from Mr. Anderson’s blog. I agree wholeheartedly with his observations and have witnessed several of them first-hand.

I just wanted to post this link in addition to my earlier post, because it’s informative:

Kanban, Flow and Cadence by Karl Scotland

It seems that now we have agile processes in place, we’re starting to look at lean as well. The topic of lean software development within the Scrum framework came up at a meeting earlier this week at my office and sparked a lot of discussion. Oddly enough, the topic also came up on David J Anderson’s blog this morning as well.

In particular, some of our Scrum Masters were talking about possibly adapting and adopting Scrum-ban¹, which uses the principles of the kanban² lean production process to implement a pull methodology in Scrum. This looks very interesting on the surface as it affords greater flexibility for inidividual tasks that are under development, but I have some reservations as well.

There are some advantages here that I see as appealing. One of the problems we sometimes run into with Scrum (and perhaps a symptom of our particualr implementation of it) is that occassionaly some team members will be over-allocated and others under-allocated. When we do our sprint planning, we assign stories to particular team members at that time, which obviously has the flaw of not really knowing (especially at this stage of maturity) how well each team member is actually utilized or if they’re going to get distracted with administrative or support tasks during the sprint. Scrum-ban emphasizes only assigning a minimum amount of work-in-progress to get started, then as tasks are completed, team members can pull a new task off the “ready” list. In this way, Scrum-ban seems to be even more “agile” than regular Scrum.

On the other hand, there’s a couple big stickers for me on Scrum-ban. First, it seems to throw iterations out the window on a surface level. As team members constantly pull tasks from the “ready” list, it seems that there is no well-defined start or end to ongoing work without artificially halting the process at some point. This could create a situation where some team members are idle while waiting for others to catch up with the end of the iteration.

Another one is that it seems to move in the opposite direction as Scrum regarding “individuals and interactions over processes and tools.”³ In level 2 Scrum-ban, the process divides up the task queue into several chunks: backlog, ready, specifiy, complete, and done.² (Some of my colleagues proposed additional classifictions, but I will only address the ones described in the article.) I’ll admit I’m just looking at this from an academic standpoint rather than the experience of actual practice, but it appears that this adds more administrative overhead. First, someone has to define what things like “ready,” “specify,” “complete,” and “done” really mean in the particular domain. Second, someone has to be constantly monitoring the ready queue to make sure it has a suitable amount of tasks classified as “ready” available to the team. Third, team members have to do two iterations of each task, first specifying and then completing the actual work. I would argue that specification should have been done before the task was classified as “ready,” though this admittedly depends on your definitions of “ready” and “specify.” Lastly, someone must confirm that “done” items are really done pertaining to the established definition. I think that Scrum-ban at this level is making Scrum more complicated than it really should be.

I’m going to take some time in the near future to analyze Scrum-ban in depth. I think I might be able to use the Scrum/kanban hybrid approach effectively, but it will need to be different than what Scrum-ban proposes to address my particular needs. I’ll post more on that later.

Additional reading:
Managing Change Requests Using Lean Methods and a Kanban Board
KanbanCon