Tag Archives: Agile Software Development

Agile software development is an iterative, evolutionary practice based on a set of values that prize individuals and interactions, working software, customer collaboration, and responding to change.

Coffee and Ethics in Paradise

Posted on by

DSCN0680.JPG sunset at buddha point
It’s my final day on the Big Island after HICCS-42.

Unfortunately, I was a ghost at the conference. I spent most of the week tightly tethered to my East Coast work day. Much sleep deprivation, anxiety and coffee consumption.

I did see the Agile/Lean presentations chaired by Jeff Sutherland and Gabrielle Benefield and participated in the Ethics sessions in which I presented my paper. These were the main reasons I took this very expensive non-vacation and so I’m grateful for how things worked out.

Sounds like there may be an Ethics minitrack again next year. Apparently, this is a relatively unique thing in IT conferences academic or professional and an indication of why HICSS is such an unusual event.

The conversation around my paper may have sparked research interest. My “ask” of the largely academic audience was:

  • Learn more about agile
  • Research dilemmas in an agile context
  • Educate us about the larger concerns
  • Create safe venues for discussing our dilemmas
  • Write about things beyond business value and efficacy

We need all hands on deck. We need to learn from other, more established disciplines. We need better data gathered with greater rigor and without the coda of a sales pitch.

How can we build software with consideration for benefit and harm as well as business value in the interests of society and our users as well as our employers and stakeholders?

How do we evolve from head count to the engineers/craftspeople we need to become?

HICSS-42

Posted on by

DSCN0234.JPG

This week, I’m presenting a paper at the Hawaii International Conference on System Sciences. My goal is to engage academic ethicists in a conversation about agile software development.

Given the year in employment I’ve had in the last year and what’s going on at my current employer this week, it is a gift that I was able to attend and I’m grateful for it.

Agile 2008

Posted on by

toronto_skyline
Steven Doc List and I held a 20 minute presentation and 60 minute open space on software ethics.

I think the format works. Software ethics is not rules or reason, it is navigating essential complexity in building software and in moral choice. Descriptions that “abstract away its complexity often abstract away its essence” (Fred Brooks)

We embrace essential complexity using the values and practices of agile software development.

We can become better software developers using the same tools we use to build better software.

We can learn through practice to recognize and accept responsibility for the intended benefit and unintended harm we create.

We can retrospect on our actions and their consequences, engage in a conversation with our peers, learn from, challenge, and support each other.

Owning uncertainty

Posted on by

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?

Stop calling it an estimate. Stop pretending it’s a commitment.

Posted on by

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.

wall target by janerc on flickrIt’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.