Agile Otter Blog

"When will it all be completed" is a question that many people can't imagine not asking.  "When will we start making money from this?" is maybe a better question.  "Is this something worth investing more money and time in?" is maybe better. But people are all hung up on software development as "buying a thing" instead of "growing a revenue stream" or "developing an audience of raving fans."  If you're "buying a thing" then "what will it look like and when will it be done" seem like the reasonable questions. It's a mindset thing. It's reinforced by myriad business practices and internal policies which limit the thinking to "buying a finished thing" and this keeps other ideas from taking root.  "If I were buying a car," "if I were paying you to build a deck," etc. So, maybe the brain-stretcher of the day:  What if software development is nothi...

I have seen people who think open spaces rock, and people declaring them “the worst possible layout.” Some people like offices (find them “essential”) and others hate them. I met people who liked their cubicles, while most find them soulless and dehumanizing. Most collocated teams like sitting in “pods” but some don’t. I have a theory rather than a great design.  My theory begins “it depends.” It only becomes interested when we get to “depends on what”. So, there is information in every space. Visual, audible, olfactory, etc.  Some of that space is on your screen when you’re working at the computer. Some is posters, drawings, whiteboards. Some is discussion happening nearby. Some is via information radiators.  If you take away the information, then it’s harder to be both focused and aware. Starved of information, we will be less productive and do less valuable work. Think of being the one remote person trying to keep up on the changes to a ...

In our previous post , we discussed doing smaller units of work, and doing no more of them than we need to fulfill an end-user's needs. This way, we get many things done, we deliver more quickly, and we develop less unneeded code (provided we get frequent feedback from users). Fans of agile software development will recognize this as one of the axiomatic concepts behind agile, derivative of much earlier work on incremental and iterative development .  Without incremental, iterative development and feedback, a process can hardly be said to be agile in any way whatsoever. So we pick up the conversation today at that point: A: ...But I we get 23 points now, and they're as big as the 1/19th sized ones. B: That has two possible explanations. A: What is the first explanation B: That they're assigning more points to same-sized work:  inflation . A: Why would they do that? People in an organization are constantly trying to satisfy their bosses. When organizations put ...

In Part VI we discussed faux bottlenecks and blaming. These are often the result of having expectations that cannot be met, a phenomenon that was discussed in the last installment. Let's pick up the conversation from that point: A: I want a velocity of 30. Quit distracting me and tell me how to get that. B: You know that a 19-point sprint means that one point is 1/19th of a sprint? A: This I remember very well. B: If you want features to be 1/30th of a sprint, make them 1/30th of a sprint in size and scope. Our person A is becoming increasingly impatient. Whereas they have asked what seems to be a very simple question (how to raise the velocity) person B seems to be deflecting by discussing systems and human dynamics and methods of estimation, and the futility of improving speed by changing estimation units. Rather than helping A make the plan and schedule successful, B seems to be hand-waving and declaring the plans and schedules unimportant and unreal. In short, B is...

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 ...