Here are agile software development mistakes that kick my ass whenever I let them:
At Agile 2008, I attended Jeff Patton’s talk on embracing uncertainty and Alan Cooper’s keynote on interaction design.
I am convinced it is the role of product owner or customer that needs the most work in our evolving agile practices.
Sponsors express their desires as feature requests. But, as Alan Cooper argues, there is no linear progression from what people need, what they perceive they need, and how they express that in language.
At the same time, supporting departments, customers and management want a commitment to a scope and schedule. And in response, the team wants methodical decomposition to estimatable stories.
And so product owners dive into story writing, decomposing software into smaller bits in order to grasp the whole from the details. But the resulting release backlog looks only slightly more nimble software requirements specification and only slightly better at describing what customer’s really want.
What if regardless of our initial input from customers, product owners took Jeff Patton’s advice and focused our initial backlogs on specific, desired and attainable end user goals — not on interactions but why they are valuable to users? What if themes were something other than a less granular stories?
Could we retain this focus through release planning by sizing these themes not by committing to a single path and simple decomposition but by a more complex matrix of possible implementations, classifying how effectively those implementations might meet the end user goal?
A product owner describes work. The team estimates it. The product owner sets a delivery target. The team commits to it.
Estimates
People are good at estimating their own ideal effort on well-defined work within their realm of experience.
People are poor at translating ideal effort into calendar days, estimating how long others will take to perform work, and estimating work that is either poorly understood.
Estimation is time consuming with diminishing returns so the effort should be managed to cost, i.e. time-boxed. That is why Agile practices invest more energy and place more value in estimating immediate work than on more speculative work farther out.
All estimates contain uncertainty. Industry research says an upfront estimate can be 25% to 400% of actual performance. The range of uncertainty is deeply dependent on context: how much work is involved, development lifecycle, experience with the particular work, shared experience within the development team and maturity of the management organization.
It is poor practice to “pad an estimate”. Padding doesn’t match the scatter that surrounds upfront estimation. For large scopes of work a developer should express an estimate as a range of uncertainty (i.e. “four to eight months skewing to between six and eight”).
Middle managers should not pad or trim a developer estimate. That is undermining the developer’s authority and making them un-accountable. The estimate is the estimate.
That doesn’t mean that the business doesn’t make planning decisions based on estimates. It means those decisions are separate from, though informed by, the estimate.
Targets
When a product owner or sponsor takes a developer estimate of 4-8 months and sets a release date six months out, they are moving beyond the estimate to set a business target. This is a judgment of what expense and time to market promise sufficient value to justify the work.
The product owner is using the developer’s estimate to inform themselves of the risk they are taking with their investment. An aggressive target within an estimate with high uncertainty is a larger risk than a conservative target on a more certain estimate.
Commitment
Setting an achievable target and owning that decision, communicating the rationale for your decision and having that rationale inform your priorities earns trust and rallies a team to deliver.
It’s the targets, stupid
Don’t set arbitrary targets. Don’t burden yourself with unnecessary risk, demotivate your developers and thoughtlessly constrain the value built into your software.
Do set meaningful targets. Take calculated risks, manage costs, partner with your developers and know what and when you need to deliver to your customers.
It’s not an estimate. The developer cannot assume your risk.
It’s not a commitment. You’ve got to earn that.
At the end of the day, the product owner is responsible for understanding the business climate, understanding the customer, describing and prioritizing the work, and managing the company’s investment to a successful outcome.
Construx has a white paper revisiting Stephen McConnell’s Software Development’s Classic Mistakes.
In it, they list ten mistakes most likely to produce catastrophic or serious consequences.
Half of them speak more to executive and product management than development:
Given my experience of organizations that means projects are marked for failure well before agile methods are even applied.
Under these circumstances, we can hope frequent delivery will either morph the project into something more valuable or cause it to die a quick and merciful death.
A better answer disperses transparency, collaboration and continuous improvement from the team room out to sponsors, stakeholders, support units, suppliers, customers and end users — from development and project management to economies.