Agile Otter Blog

In Part V, we examined the relationship between working harder and going faster. I hope that the message you came away with was that we want people to work less hard and long so that they can deliver more, though there are conditions that have to be right if we want work to be more productive for the time invested. Let's pick up there: A: So how can we actually deliver functionality faster? B: Ah, now that is a quality question. How long does it take to deliver a feature now? A: Too long. We need developers to speed up. B: What % of lead time is represented by developers' cycle time? A: Why are you asking about lead time? I'm talking about development. B: Lead time is a measurement of delivery. Development cycle time is only one element of lead time. This part of the conversation illustrates a lack of curiosity about processes. Person A has clearly decided that development is the bottleneck, and isn't really interested in knowing how the rest of the pro...

In Part IV , we talked about the thorny clashes between the reality of promises, and the reality of development. This installment picks up on some truths about working harder and going faster. A: Wait a second... You never actually said we can't go faster. You only said that trying harder and adding people weren't the way. B: That is true. A: So we  could  possibly go faster? B: Certainly. Frankly, we don't know how fast developers might be able to go. I've had friends call and tell me about taking on work that was estimated and doing it in a morning when the code was well-factored, readable, and well-tested. My friend said that "all the functions I needed were already written and easy to find." Robert Martin always said that the speed of today's development work mainly depends on the quality of the code you will be working on. Low-quality code? Low speed. High-quality code? High speed. In addition, we've asked around and found that devel...

In our last installment, part III , we talked about the reality of reality and contrasted that to the made-up-ness of schedules and estimates and promises. Today we take a deeper look into one element of that dichotomy: A: The schedule is a best-guess, but there is a real promise behind it. B: How does that affect the rate at which things can be done? A: Can I put more people on it? B: Maybe, but cf Brook's Law There is a reality to the made-up-ness of schedules, too. In this exchange, person A is reminding person B of the fact. Promises are real. Trust is real. Keeping promises creates, sustains, and promotes trust. Real life organizations run on trust.  Plenty of business leaders (and one agile aquatic mammal) have spoken and written on this at length. One of my favorite authors on the subject is Stephen M. R. Covey (AKA "Covey the Lesser") with his book titled  The Speed Of Trust . Also, see economist  Ronald Coase's work, where he explains the lower ...