Husand and father of two sets of twins. Passionate software developer and agilista
Galway, Ireland
Joined April 2009
- Tweets1.5K
- Following809
- Followers161
- Likes3.1K
Edwin Goddard retweeted
If you assigned 1 story point to every story, how much slicing would you do before you were confident you could actually complete each story in a day or so? Congratulations! You just discovered #NoEstimates. Stop trying to fit the estimate to the story. Start slicing the stories.
Edwin Goddard retweeted
So many of the comments I hear about estimation boil down to "but we have to plan and meet our goals." That's a deep failure to grasp the concept (of agile ways of working). We plan strategically, and our goals are strategic. The details of what we have to build to meet those strategic goals are discovered incrementally by releasing small bits of valuable software and getting feedback on it. We defer details, in other words, to the last responsible moment. Defining those details too early doesn't really work because the customers themselves won't know what they need until they have something in their hands. The details are invariably wrong. Too-early focus on details also often leads to building things nobody wants or needs.
There are occasional exceptions, of course, in the corners of the program where regulations, or the actual behavior of actual hardware, or necessary algorithms apply, but those bits comprising the entire system are exceedingly rare.
Edwin Goddard retweeted
Maybe instead of #NoEstimates, it should be #WhyBother. We all know they don’t work. Estimates are the worst sort of productivity theater, given that nobody believes that they’re even close to accurate.
Edwin Goddard retweeted
A Sprint is NOT a mini project. You DO NOT commit to finishing some specific bit of work (or be somehow penalized if you don't "finish" on time). It's NOT about completing stories (or, horrors, retiring tickets). That's all nothing but control-focused waterfall management bullying people into working in ineffective ways. A Sprint has a _goal_, not a target. E.g.: "make our customer's life better in this product area" or "help the user do X." Anything you can build that moves the product in the direction of that goal is just fine.
Edwin Goddard retweeted
Estimates are not needed for choosing what work to do. The only thing that matters is customer value. If something is essential to the customer, you cannot choose not to do it. If it’s not essential, don’t work on it at all. Admittedly, they may be useful for cost-of-delay computations, but you don’t need an “estimate” beyond high-medium-low for that.
Edwin Goddard retweeted
Backlogs are a Scrum thing, not an Agile thing. Customer-driven shops that work with agility decide what to do next by doing the current thing (and getting feedback). The decision is driven by strategic planning, but backlogs are entirely tactical.
Edwin Goddard retweeted
Report to boss:
"Reactionary decisions with vague objectives and artificial boundaries executed by ad-hoc groups have led to technical debt and low morale."
Boss:
"How could this be? Quick; Get some of our top people and give them 3 months to solve this!!"
#leadership
Edwin Goddard retweeted
The product owner's job is NOT to tell the team how to do its work or what to work on. They "order the backlog" but it's up to the team as a whole to decide "who does what, when, and how." A PO is ***not*** a manager. They tell nobody what to do. Their job is to understand the market as a whole, to arrange conversations between the team and the customer (they are **not** an intermediary between the two), and to organize the work by value. That's it. What they do is nothing at all like the old Business Analyst job. They are ***a team member*** who specializes in product development.
Edwin Goddard retweeted
Deming said “You can only measure three percent of what matters”. The industry's obsession with metrics does a lot of damage. I'd certainly focus on solving tangible problems, but I find that using metrics as a measure of success (whatever that is) is usually counterproductive.
Edwin Goddard retweeted
The world would be a much better place if every programmer used the Tell-Don't-Ask principle. That means to do this:
quote.extendExpirationBy(days);
Not this:
LocalDateTime dt = quote.getExpirationDateTime();
dt = dt.plusDays(daysToAdd);
quote.setExpirationDateTime(dt);
Edwin Goddard retweeted
"Low performance" is an indicator of bad management, not a bad team. To improve performance, you must change the system within which the team works. Local optimization fixes nothing (unless you're dealing with a bottleneck, but dependencies are themselves a symptom of a bad system.)
Edwin Goddard retweeted
I can think of nothing valuable to do with estimates. They are all about up-front planning. Otherwise, they're a guess. An up-front plan with enough detail to estimate is actively anti-agile, where change is welcomed even during the development process. Instead, focus on moving incrementally towards strategic goals and on delivering something truly valuable (to customers/users) as often as possible.
Edwin Goddard retweeted
The older I get, the more I notice how valuable it is to simply move on from the anchors holding you back.
When someone makes a mistake forgive them. When someone wrongs you, move on. When someone slights you, let it go.
When someone tells you they didn’t mean it, believe them. When someone is holding you back, let them go.
When the story you tell yourself holds you back, change it.
Moving forward helps a lot and doesn’t cost a thing.
Edwin Goddard retweeted
Yes. Work (very) small, release (very) often. Small things that provide customer value that are released often bring in revenue sooner == business value. It's a win win. Large batches create liability in the hope that you'll provide some value weeks (or months) down the line. It's very risky to work that way.
Edwin Goddard retweeted
To all the people who say Google is behind on AI, I say they are just on another level. This is rad.
www-technologyreview-com.cdn…
Edwin Goddard retweeted
Think of software dev exactly as you would an investment. You don't spend millions on an untried company. Instead, you invest a little, evaluate, then make a decision whether to invest more. Same for software. Build very small. Deploy. Assess. Decide whether to invest further and how much. We call this the inspect-and-adapt loop. The key is to work small so that you get fast feedback. Many shops deploy daily. A month is _way_ too long. Big up-front investments aren't a great strategy in either situation because the risk is way too high.
This Post is from an account that no longer exists. Learn more
Edwin Goddard retweeted
#AgileMaxim 1: It is in the doing of the work that we discover the work that we must do. Doing exposes reality.
Edwin Goddard retweeted
Software estimates are one of the oldest lies we tell ourselves.
We all know they don't work, but pretend they mean something and later feel enraged when shit hits the fan.
I focused a big part of my undergrad on software estimation.
After graduating, I wrote plenty about the topic.
Then, I started working for a company where I spent years researching how to make better estimates. We sold multiple millions of dollars of software using the tools I built.
I read everything there's to read. I could recite Steve McConnel's "Software Estimation" book from top to bottom.
Here is the most important lesson I learned:
People can't estimate software. It doesn't matter who they are or how much experience they have.
Estimating software reliably is science fiction.
And the best part:
They will ask you to estimate something. They will tell you they understand it's not exact. They will promise they won't hold you accountable.
And then they will. They always do.
There are two solutions for this. Let's start with my recommendations for those who don't have a choice:
1. Remove "quick," "simple," "straightforward," "easy," and every similar word from your dictionary. Never use them. Don't let others use them when referring to your work.
2. Never volunteer an estimate. Everything you say will be used against you.
3. When forced, estimate work you know you can complete today. Always estimate with a range: "It will take me 2 - 4 hours."
4. Estimate anything you won't do today in days and weeks. Say, "I should finish that feature sometime this week." Do not estimate future work in hours.
But we all know your manager will force you to give an estimate. Here is what you should do:
1. Estimate how long you think it will take you to complete the task.
2. Multiply the number by 3. This will be the lower range of your estimate.
3. Double the lower range of the estimate. This will be the upper range.
Example: If you think something will take you 1 day of work, say "between 3 and 6 days."
Here is the funny part:
It won't take you between 3 - 6 days. This is as much bullshit as any other method you can think of.
The true solution for this problem:
Work for a company that doesn't care about estimates.
ALT A Dilbert comic about software estimates.