Edwin Goddard

Husand and father of two sets of twins. Passionate software developer and agilista

[NoEstimates @No_Estimates]

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 @heedfull]

@rainbowinverted @allenholub When working collaboratively in a mob or ensemble you can get great focus when everyone is aligned and working together to solve the same problem. All of the experience and perspectives of the team can be brought to bear. From personal experience it's amazing what can be achieved

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

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.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

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 @heedfull]

@Madisonkanna I just stopped doing it and either gave a story a 1 (small enough/right sized) or gave it whatever the biggest number was for too big and needs breaking down IMO that's all you need and then you can focus on flow

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

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 @heedfull]

@antzzzm @allenholub @WoodyZuill Don't you love being taken out of context. The point I was trying to make was to use that investment (the team) the most effective way (building the most valuable thing with the customer) rather than wasting time estimating things, that's a sure why to not deliver and get fired

[Edwin Goddard @heedfull]

@HarryBailey @allenholub I wasn't talking about two teams. In my experience, the best products are built by teams that talk directly with the users and can collaboratively build it piece by piece

[Edwin Goddard @heedfull]

@WoodyZuill @antzzzm @allenholub I like to think of a development team as a fixed cost. How would you like them to invest their time. Give them something to work on and periodically review are they making progress to the goal. Is the thing they're working on still the most valuable, if so keep going if not pivot

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

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 @heedfull]

@alfbarbola @allenholub Which is fantastic because it makes the whole team better!

[Edwin Goddard @heedfull]

@Martien @allenholub Let the people doing the work decide the best way to do that work and to structure themselves "The best architectures, requirements, and designs
emerge from self-organizing teams."

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

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.

[Timeless Maye @Timelessmaye99]

The Legendary Coach Dick.

‘Winning is being better than yesterday, every day.’ 🫡

[Edwin Goddard @heedfull]

Well written blog post. Told me exactly what I needed to know in really succinct and well written way. Thank you @madnan_rafiq
https://t.co/Fe24WrI0nm

[Edwin Goddard @heedfull]

@davefarley77 Build's broken

[Doc Norton @DocOnDev]

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

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

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.