Ways of expressing estimates
The way we express our estimates color both the way we think about the thing being estimated and the way our estimates are heard. Read More
Category: Individuals and Interactions
Pair Programming Lessons from Improv
Thanks to Tim Ottinger for reminding me of Arlo Belshee’s post, “Is Pair Programming for Me?” Go read Arlo’s post, as it’s insightful and has more useful content than most articles on pairing. I’m just going to springboard off of one skill that Arlo mentioned being important to learn.
How to avoid “paragraphing” when talking. Learning to speak in half-sentences, leaving room for the other to take the idea in an unexpected direction.
A few years back, I took a course in “Beginning Improv Acting.” Read More
Another Two Sides to Estimation
There are many ways to look at the issue of estimation. Everyone in the business of software development has had experience with wanting estimates, being asked for estimates, or both. That experience frames how they look at the issue. A considerable share of those experiences have been painful. I dare say that everyone in the business has had some painful experiences around estimation, and the painful ones seem to stick in our memory more vividly than the benign ones.
What makes these experiences so painful? Again, the causes are legion. One frequent contributor is well illustrated by a story my older brother taught me as a child.
Definition of Ready
Many time, in the middle of developing a user story, the programmer discovers a question about how it’s intended to work. Or the tester, when looking at the functionality that’s been developed, questions if it’s really supposed to work that way. I once worked with a team that too-often found that, when the programmer picked up the card, there were questions that hadn’t been thought out. The team created a new column on the sprint board, “Needs Analysis,” to the left of “Ready for Development,” for these cards that had been planned without being well understood. Read More
Tracking velocity
It’s very common for organizations to track the velocity of the Agile teams over time. This is quite a reasonable datapoint to plot. Combined with other data, it might give you some insights when you look back, and insights based on data are typically more useful than insights based on opinion. Remember, though, to keep in mind what the data is, and what it is not. Read More
Getting so much better all the time!
I’ve got to admit it’s getting better (Better)
It’s a little better all the time (It can’t get no worse)
— Beatles
Why do we expect productivity to increase? This goal seems to be a common expectation for management-driven Agile adoptions. Productivity is like motherhood and apple pie; who wouldn’t want more? Read More
How easy is it for your programmers to fix problems?
A programmer, writing some new code, looks into some existing code that she needs to use. Something doesn’t look quite right. In fact, there’s a bug. Whether no one’s triggered it, or they have but their complaints haven’t reached anyone who will do something about it, is hard to say. Can she fix this code now and keep working? Or does something prevent that?
In such a situation, I would prefer to write a new test illustrating the bug, fix it, and check both the test and the fix into source control. This might take five minutes or an hour. It’s a small detour, but I feel better knowing that the code is now safer for the future.
Maybe, however, there are policies, either explicit or tacit, that prevent such quick resolution. Read More
Accomplishing Organizational Transformation
Scaling Agile across the Enterprise attracts a lot of attention these days. There are a number of models suggesting ways to organize Agile development inside a sizable organization with a lot of teams. I suspect that all of these models share the same basic flaw—that you can do something the same way across a large enterprise. Even if your policy manual says exactly how to do something, people are people and there will be variations in understanding and execution. And how does a team self-organize in a prescribed manner?
Beyond that, there’s the problem of getting from current state to a future state that resembles the model. It does not work to “install” a new way of working across a large system composed of people and their interactions. Some people suggest starting the transformation with management, as that’s the “highest leverage point” and the “system’s major influencers.” Others suggest starting with the teams, because without competence at building reliable software (or other systems) in short cycles of small steps, you’re not going to get the benefits of Agile Software Development. I don’t think that either of these starting points work.
“When we try to pick out anything by itself, we find it hitched to everything else in the Universe” — John Muir Read More
When Estimates Go Wrong
I forgot to announce that ProjectManagement.com published my article, When Estimates Go Wrong, a couple weeks ago.
What is the Right Length for a Project?
I’ve seen many comments on the topic of estimation in the past year, and I’m starting to notice some trends and assumptions in them. One of the common assumptions is that, given a particular team and amount of resources, there is a correct length to a project. A twin to this one is that there is a correct estimate that contains the same end date as the subsequent actual project performance. Read More