Wednesday, July 27, 2011
I’ve talked about The Importance of Precise Estimates. In that post, I said,
My advice is to
- measure your progress
- watch the trends
- project the trends tentatively into the future
and relax. It’ll work out the best it can. False precision won’t make it any better.
Now I just read The Virtues of the Imprecisely Measured Self by Alex Knapp at Forbes. He tells the tale of a study in the journal Psychological Science April 2011 that indicates that precision, whether false or not, inhibits success. Alex summarizes,
Precision can actually be the enemy of performance goals. To be sure, feedback is definitely a positive thing. But it appears that if you want to keep yourself motivated, it’s best to get a more generalized, imprecise feedback that lets you know you’re heading in the right direction, rather than the precise coordinates of where you are on the path.
It’s something to think about.
Friday, February 26, 2010
Yesterday was a day of mistakes. Not so much making mistakes, but talking about them. It started with Bret Pettichord’s tweet
Agile requires the courage to make mistakes in front of others and the maturity to admit them when they happen.
Sunday, August 30, 2009
My good friend, Steven M Smith, tweeted
AGILE methods emphasize realizing short-term OBJECTIVES rather than creating long-term objectives and trying to satisfy them.
I completely disagree with this statement. I don’t agree that short terms objectives are the emphasis in Agile methods and I don’t agree that short term objectives are preferred over long-term objectives. I think that Steve’s misunderstanding is rooted in the fact that he has only read about Agile methods, and not practiced them. I think that it is impossible to get a deep understanding of Agile methods by reading without experiencing. Therefore, I’d like to encourage Steve and others talking about Agile methods to try to get some experience before making such statements. I’d also like to offer an explanation that attempts to clear up this particular misunderstanding. (Continued)
Tuesday, August 18, 2009
From time to time, a discussion rattles around the internet about “how can you tell how Agile you are?” Over and over, I see people tout some variant of the Nokia Test as a way to tell if you’re Agile enough. For the most part, I think this is hogwash.
Don’t get me wrong. I’m all in favor of an Agile Team using something like the Nokia Test (or, better, Nationwide’s “Agile Tea Leaves”) as part of a self-examination and retrospection. But any sort of discussion of conformance to practices is way too low-level for the executive team, or even middle management, of an organization. Agile is the tool, not the goal. The goal is to accomplish the things the organization wants to do. Agile is a tool to allow the organization to accomplish its goals more reliably and in a more timely fashion.
With this in mind, I thought about what a high-level manager wants from the organization’s projects and the process used to develop them. How can this manager tell if the development staff is doing a good job, or could be doing better? I came up with this Do-It-Yourself Project and Process Evaluation Kit that such a manager can use, no matter what process the organization uses for development. I think it will also be useful for Project Managers who need to report upwards. Report in these terms, not in the details of the development process.
And here it is: (Continued)
Friday, September 12, 2008
I applied for a new credit card. I wasn’t in the market for a new credit card. I shred credit card offers almost daily. No one sent me an offer that I found too irresistible. No, the funny thing is that my current credit card bank spent money and went to a lot of trouble to convince me to open an account somewhere else.
It sounds very odd, doesn’t it?
Now I happen to know that this particular bank has worked to embrace Agile software development. I know people who have worked with them to do so. And I’m sure that, considering the size of the organization, they’ve made great strides in improving their software development practice. Yet the events that transpired today tell me that they’re missing an important feedback loop–arguably THE important feedback loop–the one that involves the customer.
Here’s what happened: (Continued)
Sunday, July 8, 2007
There’s a thread on the Extremeprogramming yahoogroup attempting to define Agile. John Roth started this thread with a trial balloon of ways to recognize an Agile project from easily observed practices. I have a bit of difficulty with this definition; I think that it’s too prescriptive and, while it could be a useful heuristic, would miss the mark in numerous cases. To my mind, it doesn’t zero in on the heart of Agile practice.
So what is the heart of Agile practice? In the ensuing discussion, Dale Emery posts a message the turns attention to feedback.
The whole team focuses intensely on producing accurate, relevant, timely feedback about product, project, and process.
I’ve written about the importance of feedback, before. Using feedback is not the defining aspect of Agile, of course. Using feedback is the basic mechanism for any control system. (Continued)
Saturday, December 16, 2006
It’s stabilizing feedback that keeps a simple amplifier working as an amplifier, rather than pegging the output at the maximum positive or negative voltage. The feedback mechanism observes the output and applies a small correction to the input to counteract overreactions. Because the feedback is swift, only a small correction is needed. In fact, if the feedback were delayed, the output would tend to swing back and forth, oscillating around the desired value.
In iterative software development, we use feedback to keep the project on task. Feedback from our unit tests lets us know if our code does what we intend. Feedback from our acceptance tests lets us know if our code does what the Customer wants. What could possibly go wrong? (Continued)