Monthly Archives: January 2013

Effort Estimation and Story Points Demystified

I recently worked with some teams in India that were obsessed with effort estimation.  It turned out their real problem wasn’t estimation, it was keeping the product in a properly tested, shippable state all the time — the basic requirement of Scrum.  If the product is always shippable, and the user stories are always small, and the Product Owner is always prioritizing, we can always ship a product with the important stuff in it.  If we get some estimates wrong, it just means we’ll omit the less important features.  This isn’t a perfect situation, but it’s much better than what most companies do: ship late, or ship untested.

Agile teams generally use relative estimation approaches such as story points, sometimes a Fibonacci scale, sometimes an exponential scale.  To learn how, watch this example of a Backlog Grooming Meeting.  Note that the Scrum team does not pay much attention to the points during the example Sprint Planning Meeting.  They are mostly to help the Product Owner make forecasts.

 

Playing it SAFe, Can a Large Organization Become Agile Without Changing Anything?

We’ve noticed someone selling a prescriptive approach to large scale Agile that actually appears to be 80% waterfall.  An 80/20 waterfall/agile hybrid approach may be a positive step, but we’re concerned that this scaled agile framework confuses people about what a truly Agile approach to large scale development would be.
Let’s examine some principles from the Agile Manifesto:
  • Business people and developers must work together daily throughout the project.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
On the other hand, the easy, safe prescription for scaling seems to deliberately institutionalize some bad ideas we usually call impediments:
  • A three layer stack with proxy Product Owners in the bottom layer, enmeshed in coding teams.  Somewhere above the pseudo-Product Owners, other silos contain the stuff we usually consider Product Owner work: vision, product management, release management, portfolio management.  In our experience it’s better for self-organizing teams to work directly with the *real* decision makers responsible for the vision as it emerges.  The Scrum Product Owner was never supposed to be an artificially elevated middle manager.  According to Kent Beck, the first known XP project failed because the “Goal Donor” was not the “Gold Owner.” We want regular face to face contact between business decision makers and development teams so all learn from each other.
  • Teams contain “Developers & Testers” but UX, architecture, integration (by the “System Team”), and “release train engineering” occur elsewhere.  In Scrum, these are team responsibilities, so we want truly cross-functional teams, usually with business requirements experts, UI/UX designers, etc. right on the teams.  Scrum encourages a rigorous definition of done.  Teams will be more Agile if they learn to integrate their work with other teams. This will be difficult at scale, but coordination roles only make this worse.
  • Somewhere up in the whipped cream layer of this cake we find czars such as the “Enterprise Architect” working on “Architectural Epics” guaranteed to lead to architectural bloat.  I assume this was created to appease senior technical guys who have grown rusty at everything but PowerPoint.  One place I worked with found their (waterfall era) Architecture Center Of Excellence ivory tower to be such a huge impediment they disbanded it and put the architects right on Scrum development teams, right in the team rooms.  An assigned “architect” role is utterly incompatible with the Agile principle “The best architectures, requirements, and designs emerge from self-organizing teams.”  Scrum teams are responsible for the design of the software they build.  If we must use multiple teams on one product/portfolio and we believe in team self organization, ScrumMasters must create environments that encourage teams to coordinate with each other through communities of practice, not implementation czars.
The 20% of this that’s Agile is the stuff that’s relatively easy to change in an organization: putting testers on the teams (except not integration testers evidently), working in iterations, acknowledging that architecture will evolve, and co-opting (occasionally abusing) Agile jargon.  Maybe a couple steps forward for some orgs, but far from ideal.  I think it will appeal to companies that are concerned with keeping cozy spots for everyone, avoiding the uncomfortable ambiguity and uncertainty where real breakthroughs occur.