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

All anger presents as righteous indignation. Have you ever been angry without thinking you had every right to be so? The person you're angry with certainly seems to deserving of the wrath and disdain we feel in the moment.  Maybe being angry makes us too sure, too certain of our view of others, too unquestioning of reaction to others.  Anger almost always seems like righteous indignation -- while you're in it. Righteous indignation is a powerful emotion and an addictive one.  It leads to a lot of victim-blaming.  Surely if those people didn't make us mad, then they wouldn't have to deal with the consequences of making us mad.  Anger justifies acting badly. When we are angry enough we can use force, bullying, pillory, public humiliation, verbal abuse, defamation ... well, that's okay because we are the good guys . It's okay when Batman takes the law into his own hands. It's okay when Superman drops someone's office building on Luthor. It's oka...

For decades now, people are taught a definition of "success": a successful team delivers the full scope on time and under budget. It has been the mantra of project managers and has been taught in books, in magazines, in college classes, and by word-of-mouth for GENERATIONS of managers and workers. Starting in the 80s and 90s we started hearing echoes from the 60s that a successful project is built as a series of small successes with incremental and iterative work. Next, we hear that a project is successful if it meets the client's needs on the day of delivery , rather than the day the contract is signed. And then we hear that successful products are different from projects, and project-thinking may not even be valid. The goal is to build a user base, not a defined content. Now it is about the income (economic engine) that the product represents.  No more thinking about the day of delivery and the payment for delivering the thing; it's a longer view. And t...