Why Use Time Boxes In Agile Software Development?

I recently made a response to a post about time-boxing in the Agile Coaching group at LinkedIn. As it turns out, the author of the post was well aware of the Parkinson's Law angle, and so are probably most agile team leaders. However, even if you do know about Parkinson's Law, you might be interested in the other reason. It is (in my opinion) more important, but less well understood.

Here is my response to the LinkedIn post:

Two reasons. One is Parkinson's Law:

Work expands so as to fill the time available for its completion.

You can read about it here: http://en.wikipedia.org/wiki/Parkinson%27s_Law

Parkinson's Law isn't scientifically proven. It is just an observation about the results of human behavior.

The other reason is also a law, but a scientifically proven one. Little's Law says that for a stable system:

t = I / T

t = Lead time
I = Number of items
T = Throughput (Items processed per time unit)

Note that if you want to reduce t, as in reduce project lead time, you can do it two ways, by increasing T, or by reducing I. There are plenty of ways to do either.

If we focus on I for a moment, agile methodologies reduce I by using pull processes, like Kanban and Drum-Buffer-Rope, and also by shortening iterations. This happens at many different levels, for example the release cycle level, the project iteration level, the daily stand-up meeting level and the Test-Driven Design cycle level. Not every agile method uses the same cycles, or cycle lengths, and there are of course differences at the team level.

It is also possible to reduce I by decoupling process batch size from transport batch size in order to have transport batches that are smaller than process batches, which is what the Kanbandev people are doing. They refer to it as decoupling input cadence from output cadence.

When I became interested in agile I did computer simulations to figure out for myself how it worked. Here is a link to a page that contains the results of a simulation. Look at the animation in the sidebar to the right:

http://henrik.vrensk.com/main/results

Click on the animation to see a larger version. The only difference between the two simulated projects is the length of their iterations.

100 Ways Out Of the Crisis

This videocast is the first in a new series on modern business leadership, organization, and management.

The first episode focuses on what you can do to quickly turn your company around if it took a nosedive during the financial crisis. Among other things, I present a two-day turnaround schedule.

Is two days to save a company in trouble realistic? Yes! Saving a company can, and often is, a long, hard struggle, but the turnaround can be very quick.

A quick turnaround gives people a bit of fighting spirit. It aligns everyone in the company, and creates opportunities. My experience is that there are almost always opportunities.

Pearls Of Wisdom (or not)

Following a discussion about management in a LinkedIn forum, I got an email with a thank you note, and a very good question:

You have sent me on a quest and given me a useful map, but this journey is going to take some time and have to be scheduled. Are you willing to pass on any pearls of wisdom from your journey?

I do not have a very good answer, I am afraid, but I did my very best. Here is what I wrote:

The following works for me. The important thing is not to do the same things, but to do what works for you:

• Here is what I am doing right now: I study Hoshin Kanri, Lean policy deployment. Toyota is one of very few companies able to execute a strategy well. It is my opinion that Hoshin Kanri and Lean Accounting (or similar practices) are critical success factors when implementing Lean. Also very useful insights if one is interested in Strategic Navigation, or anything else which involves deploying policy.
• When you read a good book, check the references at the back for interesting reading.
• Don't be afraid to ask about things. I sometimes contact authors of books I've read if there is something I cannot get my head around. Most have been very helpful. When I began writing my own book, Tempo!, I contacted some very, very smart people and asked if they would proofread parts of the book. So far, everyone I contacted wanted to help out. The book is better for it, and I have learned a lot that I would never have figured out on my own.
• Find some interesting newsgroups and join. It is amazing what one can learn. Pay close attention when people discuss books they've read. I have got a lot of good tips. (I ruin myself by buying too many books, and I measure my reading backlog with a carpenter's rule, not the number of books. Nothing comes without a price.)
• Cherish the people who disagree with you, because they are the ones who just might teach you something.
• Make notes while you read. My books are full of scribbled margin notes. I don't just mark interesting passages, I write keywords in the margin, and make references to related material in other books.
• Use a mind-mapping tool, FreeMind, to track interesting ideas. (I will admit that my own FreeMind database is always a few steps behind. It is still very useful.)
• I don't drive, ever. I take the bus. Gives me more time to read.
• When you find an idea you like, try to find a book by an author who disagrees, or promotes a different idea. For example, in order to understand The Logical Thinking Process from TOC, I also study general systems thinking, system dynamics, and some interesting approaches that are not based on the idea of systems, but more on patterns and pattern recognition.
• Practice! Apply your knowledge to everyday problems.
• Observe the systems around you. I am fascinated by such things as queues in restaurants. Could the flow be improved if the forks and knives were moved a bit to the left? Can the flow at the salad bar be improved?
• Experiment! I have done the statistical experiment in Goldratt's The Goal, the funnel experiment from Deming's Out Of the Crisis. I sometimes device my own small experiments, including behavioral experiments. You will learn a lot from this. (Be careful with the behavioral experiments. Use willing subjects, or be very, very subtle.)
• Write about what you learn. The act of writing it down makes it stick. If you write a blog, or a book, the feedback will teach you a lot.
• Work only with stuff you are passionate about. This will cost you, but it is also immensely rewarding.
• When you are with your family, really be there! I have a three year old son, and I really want to be present in his life when he grows up. (And he teaches me a lot about human behavior. I use ideas from systems thinking and behavioral science to bring him up. Seems to work.)
• Don't fear failure. It is nature's way of teaching us things.
• Learn from other peoples failures when you can. It is cheaper, more comfortable, and more fun than making your own.
• Make a conscious decision about whether you subscribe to Theory X or Theory Y. Your views of other people have a strong impact on how you interpret information, and manage relationships. Therefore it should be a conscious decision.

I don't know if there are any pearls of wisdom in the list above. It is how I approach learning, but I do not lay claim to having any great wisdom or insights. I do have a lot of fun!

Videocast on Transformation Logic Tree

I just noticed that Bruce Neubauer, Associate Professor at Albany State University, has embedded two of my videocasts on his web page. (You need to scroll down a bit.)

Neubauer has a videocast explaining how to use the Transformation Logic Tree, TLT. TLT is a program for creating all the trees in The Logical Thinking Process (TLTP). TLT is included on a DVD that comes with Bill Dettmer's book The Logical Thinking Process.

Here is Neubauer's videocast: