Don’t Tell Stories, Share the Experience

Problem: On many software development teams I’ve been on,  stories don’t get built out the first time to fully meet acceptance criteria even when the stories are clearly written, detailed and exact.
When a business analyst or other customer facing team member submits a story for development, here are some of the things that seem to happen:

• some acceptance criteria is completely ignored
• developers hear about a story, and think, yeah, yeah, I got that, and don’t even really read the acceptance criteria
• developers read and understand the technical details but not the customer or business-facing criteria
• developers read a story that is partially written, build it, then more details are added to the story in the mean time while they have moved on to the next one.
• the story is misunderstood due to language ambiguity but built anyway just to get the points
• a wire-frame is reproduced which does not meet all criteria because it is showing only one of many visual aspects or is out-of-date

Premise: The best way to communicate is not to have to.

Instead: Arrange to share the experience of laying out the feature or story, with everyone participating, contributing, helping form and guide the experience. Form and keep a true cross-functional team including customer/user/customer representative, business or quality analyst, developer, integrator (which can be a quality engineer, technical lead, or developer dedicated to system integration)  You know that people form these ‘tiger’ teams in crisis to get things done quickly, why wait till then?

Technique: Synchronous, multi-sensory, fair and balanced multi-way channels of shared experience

As my colleague, John Ryan put it: “Let the developers share in the design fun!”

Questions and Answers:

Q: At what point do developers need to participate?

A: After the decision on what to build has been made.

Q: But, What if that decision is based on the cost of building?

Q: What about trial features for market/user acceptance testing?

A:  After the market has been identified.

A: After the purpose or goals of the feature have been fixed.

A:  After the market requirements have been gathered

A: After the resources available have been determined ( You have completed a charter, right?)

A: before scope has been determined (estimation) because developers are essential to this.

Shifting focus from software testing and development to ensuring customer satisfaction

Action 1:

    Deliver a newly revised, fully working application with every new feature added. Time delay between features should be measured in a short span of time (days, not weeks) so the code and original purpose and details of the feature is fresh in everyone’s mind. Fully automated build, test and deployment is essential for this turnaround velocity.

Action 2:

     Replace the technical testing role with a single rotating member of the development team, called ‘Story Integrator’ thus bringing ownership of code quality issues into the development team The Story Integrator ensures the regular integration and deployment of stories produced by the team with a focus on keeping a usable build available for end users with the latest possible features at all times. The focus needs to be frequent increments of value-laden capability delivered for demonstration to the customer. Enable the customers to be the ‘testers’.  More on this in an upcoming post.

Action 3:

     Merge the roles of ‘Quality Analyst’ and ‘Business Analyst’ into that of ‘Story Maker’ . The purpose of the Story Maker is to ensure the right software gets built by the team according to the vision of the product owner and the needs and desires of all relevant end users. The person in this role acts as a liaison between the customer team and the dev team. He or she promotes clarity and hard-criteria-based definition of stories for ‘build-ability’ as well as availability of the newly built features to the customers thus increasing the ability of product owners to steer the product according to their stakeholder’s interests. More on this role as well in future posts.

The Atomic Story of the Predictable Future

No, I’m not talking about the Manhattan Project or some comic book superhero. Just the agile distillation of requirements, use cases. scenarios, specifications, and product owner whims into indivisible user stories.

In a world of complex and changing markets, it is easy to drift into the “Project Death by Requirements” trap. I believe this approach to user stories is in the true spirit of the original XP ‘INVEST’ment: Remember?  Independent, Negotiable, Valuable, Estimable, Small, and Testable

What makes up an ‘Atomic’ Story?
A. Five or fewer criteria.
B. Concise, focused, single topic description. Hint: can be described in 250 words or less, including acceptance criteria
C. Addresses only one idea or activity. Hint: doesn’t use the word: ‘and’ or worse: ‘manage’ in the description
D. Can’t be split without building half a feature. Hint: if it constantly refers to another story, perhaps it should be combined with that story.
E. Uses at most a single wireframe representing a single dialog or section of a page

Advantages:
1. Easily compared to other stories of similar size
2. Estimate load and progress based on quantity of story count, not story estimates: Every story is a 1. if one story ends up being harder than another, don’t worry, there will typically be several trivial other ones for balance
3. Easily combine stories into suites or epics to complete a whole and usable feature and in turn combine epics or suites into minimally releable feature sets to get customer feedback early and provide early value to the market, customers,  and/or users
4. Features formerly hidden in 13 point stories get revealed because they have their own story 
5. Prevents missed requirements: Developer says: “Oh, I didn’t know that functionality was part of this 10 criteria story!”

6. For lean aficionados it minimizes batch size and work in progress allowing for incredible flexibility for enhancing throughput

Shared Knowledge Dissolves Fear

Recently a large project was nearing its last phase and I had a lot of worries and near panic about its viability. I raised the alarm and said we have to tell management what’s going on and make sure there are mitigations of risk and contingency plans so they can see where they are at, early enough to take action. I had an earlier discussion with coworkers about my tendency to be alarmist and yet not have impact and they said it’s because I don’t ‘bring people with me’. I said: ”So I should go gathers some facts and make a case?” and they said: “No, that’s just gathering ammunition. Tell people why you are concerned. Sit down with them until they understand, then see where that takes you and the team. ” .

So I examined the different areas of risk and we outlined them in a strategic planning report. In an effort to verify some facts I spent some time researching the documentation available. I found and read all the test plans, training plans, data conversion plans, and discovered that there were plans in all the areas I was concerned with and yes there were real risks, but at least they were aware of them. We discusssed these with some of the management and they agreed. Even though the risks are still there, I feel much more calm and informed and capable of responding to those risks as well as trusting the team and management to deal properly with them.

Incurring technical debt is just like swimming with sharks

 

http://www.latimes.com/news/local/la-me-shark26apr26-pg,0,3211266.photogallery
http://www.latimes.com/media/photo/2008-04/38208068.jpg

In early summer 2008, a swimmer was attacked by a shark while swimming in open waters off the San Diego coast.
“Martin had apparently separated from the rest of his group when he was attacked about 150 yards from shore, he said.”

Incurring technical debt is like swimming into deep waters: you don’t know what’s under there. Why would someone want to swim out there alone?? In order to go faster, be undisturbed, feel important, I presume. The same reason people go for more features, more quickly and solo coding sprees.

It doesn’t matter how ‘fit’ you are: “a dedicated triathlete” or an ace programmer:  Reality strikes! The only difference is that no one dies, just money and time and hope is lost.

Report on Agile Open California

Locale
The venue was extraordinary, right on the marina – every view had
water, There was the clinking masts from the harbor, the cry of the
seagulls, the rich nautical fragrance adding to the milieu, reminding
all of the burgeoning presence of life beyond the sterile technical
realm. The fact that the site, Fort Mason, had long-ago been converted
from a military base to a peaceful non-profit community center
provided a pleasant parallel to our intent to transition companies
from rigid, command and control, plan and execute, fail and blame
regimens, to flexible, inspect and adapt, collaborative,
customer-pleasing journeys.

People
Humble, open to new things, tired of typical wasteful software development life/death cycles.
Eager to learn new ways of working together.

Organizers
A diverse collection of personalities ranging from wake-you-up Zen
master, to earth mother, to grandfatherly guide, to web tech, to
enthusiastic early adopters. Just the mix that was needed: self-selected
and self-organized. I do believe we maximized the amount of work not
done while leaving nothing important undone. I’m hoping to join them to produce another event sometime.

More to come…

Agile Open California Update

As an organizer of the Agile Open California Open Space Seminar coming up Monday and Tuesday, I am please to report that the preparations are going smoothly and we have a stellar list of attendees. The theme is :
AO California Theme – Sustainable Agility: Thriving in the Mainstream

I’m hoping to participate in quite a few discussions hashing out some difficult challenges uncovered in transitioning large and small organizations to agile.
An excerpt from the seminars topic incubator indicating some intriguing and lively discussions are imminent:

The whole certification question. Can someone be called “certified” after 2 days of training? Does that dilute the value of Agile?

Servant leadership in a command & control world

Weaning teams from waterfall into a lean, sustainable flow of value

Developer productivity and noise. Who needs quiet time and how much? Does pairing help with noise?

How to handle micro-management

Productivity through simplicity: Ruby on Rails / JRuby

Space design for productivity: Responding to facility impediments

Training Simulations: Sharpening the tools with realistic team improvisations

Google is hosting the lunches both days while Agitar is hosting a reception Monday night, 7pm, so the eating should be as enjoyable as the debate.
Registration is still open if you wish to participate.
I’ll try and blog some updates while at the conference since we’ll have wifi.
Full Disclosure: My employer, Tacit Knowledge, happens to be a Platinum Sponsor of this non-profit event, although I was an AgileOpenCA organizer before I came onboard this agile-minded, San Francisco-based, software consulting firm.

Return of the Blogger

Ok, Ok, I know I haven’t used this blog since my first entry a year ago, so, on its anniversary I pledge now to set a blistering pace of at least one entry per year.
Actually I do have something worthwhile to talk about. I’m helping organize an agile event called Agile Open California/ at Ft Mason in San Francisco, October 22-23. It is an open space happening with the theme of Sustainable Agility. Lots of interesting folks from the local agile community will be putting their minds together to share experiences and synergetically create new expressions of team and organizational agility in an attempt to transform the sorry state of the U.S. software industry and employment into something more humane and valuable to society.
I hope to blog throughout the planning and during the event itself. Stay tuned, really!

What is Agile?

This blog will cover my experiences with agile and lean practices, thoughts on the agile quality of software development, business, and life in general. I will cover what I believe agile means, what it gets you, even how it feels. I will cover obstacles to agile, concrete walls of obstruction to agile practices as found in large Fortune 100 companies as well as chaotic Silicon Valley startups.