I’ve had a long career with estimates in software projects. While it’s been a rocky journey, I now feel that I’ve gotten to the point where I truly understand how to and the value of estimation.
But before I give you the great reveal, let me share some of my history…
Estimate Newbie
I first began my career as a newbie in estimation. I fell into the trap of being as honest as a could be and I found that my estimates were often used against me. For example:
My bosses would often forget the “fine print” around the estimates. Words like – “this is only a guess until I get more formal requirements. Or, I’ve never done this before, so I really don’t know how long it will take” were never remembered. Imagine that?
People who had not a clue would weigh in on my estimates. Bosses, who were under pressure to release quickly, would cut them. And project managers, who were trying to “defend” the project, would pad them. And my developer colleagues, who always had an optimistic spin on things, their estimates would always be lower than my own. Imagine that?
And I always felt that nobody wanted the “truth” in estimates. That they couldn’t handle it. So, it negatively influenced me to pad/cut depending on the situation. But the key point is the inherent dishonesty I felt around all estimate discussions. Early on, it felt like a game of sorts. Where the last one that weighed in on a number…won. And the development team…generally lost. Imagine that?
But as in all things, I grew in my experience and in my career. Soon, around the late 1980’s, I became a “manager”. Which meant that I not only had to estimate for myself but for my group(s) as well. This showed me both sides of the estimation continuum and frankly, I didn’t like it much.
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.
One of my favorite, old-time rock groups is Emerson Lake and Palmer. And their song From the Beginning seemed appropriate for this article.
One of my new favorite voices in our agile community is Sandy Mamoli out of New Zealand. I’ve read oodles and oodles of her work, but I have yet to see her in person. Fingers crossed, I get that chance soon.
One of the more interesting things that Sandy is focusing on is team self-selection when it comes to how to organize around projects and work. Recently Sandy wrote a piece entitled: Giving Teams the Best Start.
In it she emphasizes the work that Ainsley Nies and Diana Larson have done in their book Liftoff, which just released its second edition.
I saw a picture tweeted by Alex Yakima with this picture of the RTE Canvas and it inspired me to talk about this role more.
You can find the tweet here - https://twitter.com/alexyakyma/status/793491699515273216
In the canvas, he highlights five key responsibility areas for the Release Train Engineer. They are:
- People
- Program Increment
- ART Success Indicators
- Improvement Roadmap
- Coaching & Education
To be fair, I’ve been fairly critical of some aspects of the Scaled Agile Framework. And even though I’m a SPC, I still don’t blindly install SAFe in many of my clients. That being said, there are a majority of my clients who are using (or planning on using) SAFe, so I get exposed to it quite often.
While I personally struggle with the agileness of much of SAFe, in the spirit of fairness, I do think there are concepts in the framework that are healthy and useful. So let me share a few of those...
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?
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.
On the surface, this statement appears as if I’ve lost my mind. For one thing, a traditional view to Product Owners is as a Product Manager or customer/business stakeholder-facing role. And the traditional Project Manager is more so a planning and execution focused role. The two are quite far apart and seem to have little synergy.
The other factor is traditional versus agile contexts.
There are no “traditional” Product Owners. Usually a Product Manager is in essentially the role but it’s very outwardly and upwardly facing. Once the requirements are “signed off”, they’re not that interested in collaborating with the team until the end of the project.
Does anybody remember the Cool and the Gang song Celebrate?
I sure hope so.
I want to write a short post about celebrations. For some reason I've encountered quite a few teams lately who are struggling. They're completing sprints and releases without getting much in the way done or meeting expectations.
In other words, they're ending their efforts: sad, depressed, without a sense of accomplishment. In a word, they’ve got no reason to – Celebrate.
Of course there are many reasons for it and I can't possibly explore all of them here. But the examples have made me reflect back on some of my best experiences with teams delivering “the goods”, and I wanted to share an example.
I’m often quite wordy in my blogs. I’ll pose an initial question in the title, throw out a thousand words or so, and then present a conclusion. I’m not going to do that here. Instead I’ll be much more succinct.
Is forecasting evil in agile portfolios?
YES!
The context for this conclusion and subsequent discussion is three-fold:
- Forecasting when you are just building your agile teams OR are in the early stages of an agile transformation;
- And, when you’ve been doing agile for awhile, and you’ve become overconfident with your capacity awareness;
- And forecasting in this sense is anyone determining how large or how long something will take and NOT fully engaging their team in the estimation, planning and forecasting.
