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

Technical debt refers to those shortcomings in the design of the software that we accept that we will have to address at a later date. This often comes as a result of running out of time in any given iteration; as we cut corners, quality suffers, and technical debt mounts². Defects, on the other hand, are unintended consequences or misunderstood requirements; that is, they are unforeseen problems with the software that must be addressed immediately. The ratio of the two varies from project to project, but since defects often require immediate consideration, they tend to have a disproportionate effect on the deliverable date.

Of course, the obvious solution is to write bug-free code. That’s what we want to do anyways, right? Admirable, yes, but not practical in the least. It is impossible to write code that is free of defects, as it would at its very base require a product owner and development team that are somehow psychically linked as well as infallible. However, it is possible to reduce the number of defects by following some very simple principles. This list is by no means comprehensive, but it should give you a starting point.

Limit work in progress. Each developer should really not be working on more than one or two tasks simultaneously in most situations. Focus increases reliability.

Reduce “crunch.” It should be obvious at this point to both developers and managers that there is a diminishing return on hours worked. Try to take on realistic commitments for each development iteration and avoid working large amounts of overtime if at all possible.

Pair programming. This is a highly useful tool not only for developers to check each other but also a developer and a quality/business analyst to check each other. Your team will think you’re weird at first for asking for such an odd pairing, but I’ve done this before, and it can be highly valuable to have someone who understands the business and requirements working with the developer up front. This also increases utilization of QA resources that often sit idle until the end of an iteration.

Engage QA earlier. Frequently in agile environments we fall into the trap of doing “mini-waterfall.”³ That is, we do a design and specification phase during sprint planning, then the coders spend a bunch of time doing heads-down work to meet sprint objectives, and then they finally throw their deliverables over the wall to the QA team at the very last minute. If you find this to be a frequent problem, then break your tasks down into even smaller chunks that can be completed and delivered without utilizing the entire sprint for each one.

Inclusive design. Always strive to include the entire team in design and specification meetings. It’s a simple fact that if more people are involved, more problems are likely to be uncovered before development even starts. The team as a whole should have a keen understanding of the entire project, even parts they may not be responsible for. If you find that this inclusiveness is eating up too much time, it’s most likely because your team is too large or your meetings are not staying focused.

Daily updates. The daily status or “stand up” meeting is one of the core principles of Scrum. Even if you’re not practicing Scrum (or any agile methodology for that matter), I highly recommend daily updates. A focused, repeated meeting to keep everyone up-to-date on the team’s progress can help the team be aware of its progress as a whole as well as help identify and address problems mid-stream rather than at the end.

Visibility. Another principle of Scrum, task boards and burn-down charts can also help the team with understanding where it is. Whatever the actual implementation, it should be a highly visible cue into everyone’s projects and the overall health of the project. Increased visibility reduces one of the most frustrating defects—items that we just plain forgot about.

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.

Kanban, Flow and Cadence by Karl Scotland

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