There’s a famous Mike Tyson quote:
Everyone has a Plan
until they get Punched in the Mouth
It reminds me of the ultimate futility of estimating and planning. Or investing too much in both of those endeavors. Particularly in the area of software product development.
Another related quote is from Eisenhower. It surrounds the value of plans (artifact) vs. planning (activity):
I have always found that in preparing for battle that
Plans are Useless,
but Planning is Invaluable
That is:
- The activity of exploring requirements via user stories and acceptance criteria;
- The activity of minimizing (MVP) the results so as to learn;
- The activity of making estimates as a vehicle to explore size, scope, risk, and design approaches;
- The activity of discussing construction and deployment strategy;
- The activity of delivering work to stakeholders and gaining their feedback.
Are all more valuable than fixed or static plans, which are intolerant of the punches that are inherent in software development - learning and discovery.
Wrapping Up
The next time you find yourself getting “stuck in” your plans or thinking that planning is more important than doing and adjusting, then please remember these two quotes. Also remembering, that Tyson and Eisenhower weren’t practicing agile software development. But they were indeed…agile.
Stay agile my friends,
Bob.
Introduction
This article has been floating around my head for quite a while. It will encompass several themes. The first being, how do we “account for” the time and focus within our agile teams? Second is, how granular do we plan for and monitor the focus of our agile teams? And finally, when planning and forecasting, should we plan at the individual level?
The “we” in these is a bit broad. I would include managers, directors, VP’s, C-level folks, the PMO and Project Managers. Virtually anyone who is tasked with “caring about” a technical team and what, how, and when they do what they do.
The Dinosaur Age
Well in this case, it’s not that long ago, but the analogy feels right to me. In this Dinosaur Age, project managers and “all management” for that matter, cared about people and their time. What are some of the aspects of that?
More than a year ago I wrote an article about how important “capacity management” was in agile teams. To be clearer the point was really…realistic capacity management.
At the time, I’d just come off a coaching roll where I’d encountered quite a few organizations that were pushing their teams too hard. Not slightly over their capacity, but two, three, four or more times their healthy capacity. And this created some distinct side effects:
- Employee satisfaction and morale was down and attrition was up. And they didn’t just loose their average people, they were losing their best people;
- Product quality was usually in a crisis mode and customer trust was continuously eroding;
This is a guest blog post by my colleague: Chris Waggoner. Enjoy!
Estimation of time and effort until you’re done is one of those things that every inquiring manager wants to know. In an effort to provide “accurate” estimates, companies and people spend countless hours generating list of task and debating the duration of each task. When it comes to developing software these estimates are rarely correct and often grossly wrong. The estimates are wrong because in building software that we are often building something that has never been built before. When we find ourselves being pressured to estimate something we’ve never done we tend to SWAG (PMI for Sophisticated Wild Ass Guess) the answer in man-days and/or hours without understanding or knowing all the potential variables in play. Here in lies the problem with traditional software estimation methodologies: within a short amount of time spent there are diminishing returns on effort versus value. That is to say, early in the traditional process the value of spending more time estimating doesn’t provide a higher certainty of when we will be done.
