I’ve been thinking about leaning a lot lately, and not of the pressed-wood bookshelf nuisance variety. I talk about Lean with my colleague and President of Rally, Ryan Martens. So when I talk about a leaning bookshelf, I’m referring to my interest in Lean in all its forms. I am talking about the books I’ve been reading  that pertain to Lean. And, more specifically, how can I turn my “Leaning bookshelf” into a continuous “learning bookshelf”?  How can I think about my evolution of thought and practice with regard to Agile as influenced by Lean? What could be a good, rewarding goal?

And so, through discussions with Ryan and some of my own quiet thought, I came up with a goal of improving my notion of learning. Yes, for me, that seems to be what I am discovering more and more about Lean:

• How to learn
• How to teach others to learn
• How to encourage organizational learning
• How to avoid/eliminate re-learning

And so in this post, I thought I would share what I am reading, have read, or am about to read, and ask you for your comments and recommendations with regard to my leaning—>learning path. Some of the books may not look directly associated with Lean. I just know that they have been part of my lean learning journey.

The Contents of My Leaning Bookshelf:

1. Getting the Right Thing Done – Pascal Dennis
2. Hitotsubashi on Knowledge Management – Hirotaka Takeuchi and Ikujiro Nonaka
3. Implementing Lean Software Development: from Concept to Cash – Mary and Tom Poppendieck
4. Lean Software Development: An Agile Toolkit – Mary Poppendieck and Tom Poppendieck
5. Lean Thinking – James P. Womack amd Daniel T. Jones
6. Lean Transformation: How to Change Your Business into a Lean Enterprise – Bruce A. Henderson and Jorge L.Larco
7. Learning to See – Mike Rother and John Shook
8. Managing to Learn – John Shook
9. Product Development for the Lean Enterprise – Michael N. Kennedy
10. Ready, Set, Dominate – Michael Kennedy, Kent Harmon, Ed Minnock
11. Scaling Lean and Agile Development – Craig Larman, Bas Vodde
12. Scrumban – Corey Ladas
13. The Knowledge-Creating Company – Ikujiro Nonaka and Hirotaka Takeuchi
14. The Elegant Solution – Matthew E. May
15. The Toyota Way – Jeffrey Liker
16. Thinking Beyond Lean – Michael A. Cusumano and Kentaro Nobeoka
17. The Art of Lean Software Development – Curt Hibbs, Steve Jewett, & Mike Sullivan
18. The Goal – Eliyahu M. Goldratt

Looking at my leaning bookshelf and thinking of my focus on learning, I realize I haven’t included any Senge books or others about organizational learning. That will have to wait for another post.

What books are important to you on your leaning/learning path?

Yesterday, I mentioned a Rally client team I visited that was concerned about the Rally tool’s inability to create individual team member burndown charts.  We swam through that torrent of misperception only to enter a shark-infested tank around all of the overhead involved in adopting Scrum. Wait! Isn’t Agile supposed to cut costs, not add them? Big overhead sounds like cost and waste to me. Where is this overhead? We quickly zeroed in on their overhead: the Sprint Backlog. Specifically, what should be tracked in the Sprint Backlog?

To start the conversation, they told me that they are always 100% allocated. Huh? “What do you mean you assume 100% allocation?” They helped me understand that, in the Sprint Backlog, they assumed that they worked 8 dedicated hours everyday. For them, Sprint Backlog should reflect all of that time.

This was followed up with, “So how do we plan for work that we didn’t know would come up, like production issues?“  Clearly, they hadn’t read Slack by Tom DeMarco or heard of the Theory of Constraints and The Goal by Eliyahu Goldratt and the notion of buffer. So, we had a few things to clarify around this “process overhead”:

• What goes in the Sprint Backlog?
• How do you allocate your time effectively?
• How do you “plan” for unplanned work?

In this first post on the Sprint Backlog and using Agile to cut costs, I’ll concentrate on the first bullet:

What goes into the Sprint Backlog?

The Sprint Backlog emerges from the Sprint Planning meeting as the team:

• Identifies the highest priority value items
• Breaks them into tasks
• Determines the effort necessary to complete the value items
• Commits as a team

We cut costs by only committing to and tracking the highest priority items that deliver value in that timebox.

We cut overhead by not tracking items in the Backlog that do not contribute to the potentially shippable product increment.

So back to our overprocessed team. We opened up the Rally tool and moved to their Iteration Backlog view. I saw over 50 items, at least. And then, I understood.

The team was putting EVERY task they do throughout the timebox into the Sprint Backlog, whether it added value to the product increment or not.

Imagine having to track all of your day’s activities. Imagine having to, 2-4 weeks in advance, absolutely commit to these full days’ worth of activities. So, indeed, here was the overhead. Vacation days were in the Sprint Backlog: they had 8 hours of effort. Holidays were in the Sprint Backlog: again 8 hours of effort. The book club had to be tracked separately for each individual who attended it.

The result was that the overall team’s Sprint Backlog would show effort being completed, backlog items being marked “Completed”, the burndown chart burning down nicely, and yet no work of product value was started or in progress. This was not a tool issue; this was an Agile adoption issue.

What is the lesson in all of this?

Be careful about what you choose to track in your Sprint Backlog.

Ensure that what you commit to in that Backlog reflects the delivery of product value.

Abiding by this simple guideline will not only dramatically reduce process overhead, but it will also ensure that what we DO choose to track, whether through a taskboard or an automated tool, is work that is intended to produce product value by the end of the timebox.

Now about their allocation percentages and how it contributes to overhead. That is fodder for another post.

Further Reading:

• Part 2: How Do You Allocate Your Time Effectively?
• Part 3: How Do you Plan for Unplanned Work?