“One thing completed is worth ten things on hold.” – Dianna Booher

Most of our jobs entail delivering some sort of a widget to a customer. Ideally, we would be able to work on one task at a time. Finish it, then move on to the next task. Unfortunately, very few of us feel we have the luxury to work in this manner.

In our world, we have any number of distractions from bug reports to feature requests that compete for our time. Too often, what gets lost in this mix of pleasing the customer is actually returning value to the customer. It seems obvious, but a customer cannot begin to see value until the product is delivered. Take the following example:

Using single piece flow, you are delivering this set of features 8 days sooner:
Feature 1: 3.2 Days Sooner
Feature 2: 2.4 Days Sooner
Feature 3: 1.6 Days Sooner
Feature 4: 0.8 Days Sooner
Feature 5: Delivered at the same time.

Not only are you delivering your most important feature (presumably the one delivering the most value) three days sooner, you are not delivering any feature later. Overall, the Single Piece Flow yields a 32% increase on a company’s ROI. – if you’re interested in the math, feel free to shoot me an email.

An easy shot to take at the above methodology would be to criticize the efficiency in the hypothetical. Obviously, no shop is 100% efficient. In fact, most research points to a shop running anywhere north of 80% as pretty streamlined. That being said, there would be common waste among both project management techniques. In a single piece flow environment however, you are not nearly as exposed to four wastes that Lean methodologies warn against: Partially Done Work, Task Switching, Waiting, and Motion.

Depending on who you read, with three switches every day the multi-tasking team is losing an additional 10-25% of their efficiency.

Even using the most conservative numbers – 80% efficiency with multi-tasking only costing 10% – you’ll realize over 28% better numbers running tasks through one at a time. The math is pretty easy. If you can increase your company’s top line sales by getting billable features to customers quicker or reduce your costs by having less developers deliver the same work you’ll be in a much better position than you are today.

It’s simple: no product, no value. The quicker the product is delivered, the quicker value can be realized. Like Tom Demarco said, “There are a million ways to lose a work day, but not even a single way to get one back.”

“When you’re finished changing, you’re finished.” – Ben Franklin

Lean software development was actually my introduction to agile through the Poppendiecks’ book, but we brought in an agile coach to refocus our teams on what it means to actually run a lean software shop.

So, as I often do, I dove headfirst into studying.  I read anything I could get my hands on even remotely related to the Toyota Production Systems (TPS) and quickly realized that while TPS concepts have been around since the 1930s (and lean principles much longer than that), lean software development is very much in the early stages of application.  There is really no consensus in the community as to how to run a project, but James Shore wrote a really good article that contained a sketch for a Kanban Planning Board. Below, I’ve modified it to incorporate a non time-boxed retrospective concept that was discussed on the Kanban Development Group and added a couple of team motivation concepts.

At the top of the board is the overall goal of the current project. Having this so prominent should help the developers not get so involved with the trees (Minimal Marketable Features) that they lose sight of the forest (the project).

Along the left hand side, you have the current MMF that the team is working on as well as the backlog. The order of this backlog can be changed at any time by the stakeholders (Corey Ladas has a great article on using perpetual multi-vote to schedule this queue).

In the middle, are the development tasks that are required to satisfy the current MMF as well as Work In Progress (WIP) and an area for Done tasks. James left off the second two areas, but project management is about managing people as much as it is managing projects. People like to mow their lawns because once it is done there is a psychological boost to look over and see what you’ve just  accomplished. In the same way, a “Done” area allows  the developers to see the grass they’ve mowed during the current MMF. In an environment where the team is local, you could do away with the WIP area as the developers would have the cards at their desk, and in a situation where a software based board was being used there could be a current MMF progress bar instead of the done area.

On the right hand side, there is an Urgent  box that allows for an MMF to skip the backlog and focus the developers on an emergency situation, and there is a retrospective queue. Rather than time-boxing retrospectives, this queue allows the retrospective to fit more naturally into a pull system.

While this board is my take on improving what I’ve seen out there, I have high hopes that Kaizen Conference  will help us as a community move to a more standardized approach to managing projects in a lean, efficient way. (update 2014: spoiler, the conference didn’t help out at all)

One of the most contentious and discussed topics on our team was how to actually run an agile project. After a lot of good debate and maybe a few bad arguments, here is a wire frame of how we run agile software projects.

1. Create a backlog for the project.
   1. Get with stakeholders and ask them what they are looking for in the software.
   2. Write high level user stories with the stakeholders. Format like:
      As a (role) I need (something).
2. Discuss user stories with the development team and assign story points to each card.
   1. Story points are assigned to each story using planning poker.
   2. The numbering system used for story points will be a subset of Fibonacci numbers (1, 2, 3, 5, and 8). These points will be assigned where user stories are relative to each other. A story assigned a 2 is twice as complicated as a 1 and 2/3s as complicated as a 3.
3. At the beginning of each one week iteration, user stories are selected by the development team until the total number of story points equal the team’s velocity.
   1. The stories are detailed out further to add “so that (benefit)” to the story where the card now reads: As a (role) I need (something) so that (benefit).
   2. With this additional information, at any developer’s request, the user story can be assigned a new story point value via planning poker.
   3. All cards with a Fibonacci number of 5, or 8 are broken down into multiple user stories until there is nothing with a value assigned to it that is greater than a 1, 2, or 3.
   4. Add acceptance criteria to each card.
   5. The numbers are added up again, and if the number is less than the velocity of the team, additional user stories are added. If the number is greater than the velocity of the team, user stories are taken away.
4. The cards for an iteration are placed on a board and developers grab one when they begin to work on it.
5. Once complete, the developer places the card on the “Complete” board and grabs the next available card.
6. At the end of each one week iteration, a retrospective is held to discuss lessons learned, any new cards added to the project, and any changes to the team’s velocity. The team will show working software to stakeholders and users when applicable for feedback and sign off.
7. Any new stories that were added to the project are assigned a story point value and added to the backlog board.
8. Plan the next week’s iteration (restart at Step 3).

• Acceptance Criteria – Measurable terms of what must be done for a user story to be acceptable to the stakeholders.
• Backlog – Sometimes called a Product Backlog, the Backlog is a collection of user stories and tasks the development team will work on at some point in the future. Initially, this list consists of all obvious functionality, and it is allowed to grow and change as more is learned about the software.
• Iteration – Sometimes called a Sprint, an iteration is a fixed, specific length of time resulting in a small but complete piece of working software. Multiple iterations combined create a fully integrated product.
• Planning Poker – Planning Poker is a consensus-based estimation technique for estimating. Using this methodology, individual user stories are presented for estimation, and after a period of discussion, each developer chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story being discussed. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again. The method has been popularized by Mike Cohn in his book Agile Estimating and Planning, and studies have credited it with less optimistic and more accurate estimations than other methods (K. Molokken-Ostvold and N.C. Haugen)
• Retrospective – A meeting where a development team looks back on the previous iteration so that they can learn from their experience and apply this learning to future projects.
• Stakeholders – Customer representatives from the business who are actively engaged in the project. They prioritize user stories and give real-time feedback throughout iterations.
• Story Points – A measure of magnitude of a paticular user story, and it\’s size relative to the size of other user stories. Story points enable effort to be estimated without trying to estimate how long it will take.
• User Stories – A very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.