Agile Otter Blog

In Part II , we talked about velocity and the (glossed-over) line about making it easier to get work done instead of pushing harder.  A was asking if changing the units used in estimating would help and, of course, it doesn't. We pick up from there this week with a tiny snippet of conversation that touches on some big ideas: A: Then how can I get my 30-point velocity? B: What if there isn't a way? Maybe you need to need less? A: But the schedule....! B: The schedule is made up. How long it takes is real. Software estimates are often wrong. Quite often they're off by over 200% on specific items. There is a very good reason for that, and that is that we aren't given uniform standardized work items and a standardized process. Nor can we be. If the feature the client wants has been written already, we don't write it again. Software developers don't repeat themselves. Each problem and each solution is (a little bit) unique. As such, each estimate i...

See Part 1 , in which we present a deep truth about velocity and story points. A's team has turned in two sprints, with velocity of 19 on the first and 23 on the second. A: Okay, but my next sprint needs to be 30 points. B: What has changed to make a point be 1/30th of a sprint? A: We just need it to be. B: Then improve something significantly so it becomes possible. A: Can we just try harder? B: There is no evidence that works. A: Then story points aren't useful. B: We could have started with that agreement. A: Let's use real hours then! B: Not better. There is a primary truth being described here, and that is that velocity is not a knob that one can turn. I addressed that previously in another blog post, some time ago. Velocity does not raise because people try harder.  If that were so, it would be because people were (until now) withholding their productivity and waiting for you to ask for it. It's unlikely, but if it were so then one would have to ...

A few weeks back, I published a blog about people complaining  in a company.  The article has received a lot of attention and love, and I appreciate all of you who retweeted it and linked to it and Instapaper linked it and recommended it in Pocket. I completely stand by all that I said, and I think it's worth paying attention to. Today I want to talk to you about not complaining . Well, just a bit. Actually, maybe I'm going to talk about how to do it better, since I've been working on learning that bit. There are things we know about human interaction and human memory, and some of them seem pretty crucial to anyone who wants to make a change in their culture (org or otherwise). You see, people remember the way you make them feel. The fundamental rule for any change agent has to be: Don't Be Dreadful You see, part of your memory mechanism involves your amygdala and your hippocampus. These are two parts also very much involved in your emotional experie...

Having had many conversations about velocity (and many blog posts here and at the Industrial Logic Blog) one day I decided to write up an example of the conversation as if it were happening between two characters named A and B. The first question asked by A was the first question about story points that a younger agile otter asked in his first XP project. Most of the questions were asked by my younger self at some point or asked by someone I have worked with. By the same token, the answers came from myself and people I know too. I've internalized these conversations to the point that I'm not sure what questions were mine and which were asked of me, and which answers were original and which came from mentors (managers, coaches, developers, etc). Suffice it to say that I'm represented (at various points in my journey) by both the questions and the answers. As such, the point of the dialog between A and B is not to humiliate or pillory either A or B. The questions ar...

There is a certain theory of agile development which is built on factory thinking, using division and management of labor to accomplish large projects. The Plan You have a big job to do? You are in luck!  We have a perfectly risky-to-unworkable, logical-sounding, emotionally-appealing, naive system for you: Scatter: Divide the project into pieces Resource the project (acquire the right number of "teams") Assign pieces of the project to "teams"  In the "teams", a lead character will divide the pieces into smaller and smaller jobs The small jobs will be assigned to individuals who work for the lead Gather: Individuals complete their small jobs The small jobs are integrated/combined/summed by the lead When small jobs are done, the lead delivers the finished work of the "team" "Teams" who completed the work are released The project office then combines the parts The integrated, completed project is delivered P...