I have moved “The Agile Quality” blog to www.agilequality.com

Also there is a shiny new site with lots more info on Agile Quality Consulting and many more posts. See you there!

The Agile Quality Blog

http://agilequality.com

Envisioning a learning environment for agile test automation

Lisa Crispin just started an inspiring discussion on this lively test discussion group . She said “it would be nice to have… [an] app that everyone could install easily and use for demos, training and so on.”

I heartily agree! Here’s my vision for the ultimate test automation training environment:

Simulating the greater process of creating business examples and coding the system under test would be essential to reproducing the reality of highly collaborative agile teamwork. On the requirements side you have an incrementally increasing collection of stories hopefully represented by business tests using something that enables BDD or ATDD. On the development side, you have ongoing bug fixing and refactoring in addition to incrementally added code for each story.

Ideally, I  would have a live cross-functional agile team at the ready for the most realism, but that’s not always affordable.

Essential  would be a fully functional example-based test automation framework tied to a sample application ready to be placed into various states using a simple dashboard.

Learning System States

1. No application, just the BDD/ATDD framework.  The tests should be able to stand alone so that business tests can be written before code is ready. They should run and all fail.

2. An unfinished application where a tier is unfinished, perhaps mocked up. Mocks should be able to be easily turned on and off in lieu of real functionality. Some tests should run. Some will fail. Some will pass but will have false feedback due to the mock.

3. An application where all tiers work but there are seeded errors. Tests should fail around the errors, pass around working functionality.

4. Other versions of the application with gradually added functionality that calls for more test coverage. Tests should be able to be added. Refactoring of tests might be indicated.

Areas of completeness, presence of mocks, and errors would change based on what is being taught using a system dashboard for easier configuration.

Enabled Lessons:

1. writing business examples with specific data and rules
2. coding those examples to interact with the system under test
3. running tests against an incomplete system. Accommodating mocks.
4. managing a suite of tests. Choosing how to group, what to run when,
5. when and how to refactor
6. testing your tests
7. determining coverage
8. optimizing for brevity
9. managing versions, syncing your tests to the right version system under test
10. maintenance, how to keep up with changes

So, do you see the value in this type of learning environment?  Anything you would add or subtract? Does anyone know of anything like this? The discussion participants mentioned Sinatra, GWT, VQWiki, but none of those fit this bill.  Anyone want to start or adapt an open source project for this?

-Dennis

Following the Virtuous Spiral

Bode Miller’s attitude

In regards to my previous post on Belt’s and certifications, Bode Miller’s attitude shows the perspective of the competition with the self being primary, driven only partially by external motivation for awards and certifications. From espn article by Jim Caple  ”The actual gold medal doesn’t mean that much,” Bode said. “If I had won it in a way that I wasn’t excited about or that I wasn’t proud of, I would have resented the gold medal in a way, regardless of what anyone else thinks. … The medals are kind of a distraction as much as anything because they make people think I’m proud of the races because of the medals. But I was proud of the race when I crossed the finish line

The Belt of Meaning

Some Professional Milestones

• Education
• Experience
• Fellowship of Colleagues
• Craftsmanship
• Serving the Community
• Certification

Even though a milestone, I believe that the preparation for the certification is the true value. It’s seems to me a lot like getting a black belt, not that I have one, but I’ve watched as my 13 year old son methodically earned his, pausing through nearly four years only once, for major leg surgery, after which he resumed using the same determination with which he began as a white belt.

A certification means different things depending on the issuing organization, the difficulty of the challenge, it’s scarcity, and to whom you talk.

Consider:

ATA Tae Kwan Do

"If the Songahm style can be thought of as the heart of our Taekwondo, then our over 1,500 independently owned and operated licensed schools and clubs (world-wide) are the life blood. Without them, we could not count over 300,000 men, women, and children among our members! "

Mt. Tamalpais Aikido Dojo

Aikido of Tamalpais held its first class October 22, 1976. Thirty-six students were on the mat that night. Since then, except for Sundays and "sitting down and eating holidays," Tam Dojo has held at least one class every day. Wendy, George, and Richard have continued practicing and now hold godan (fifth-degrees black belt) ranks. The school has graduated some forty yudansha, some of whom have gone on to start their own schools, and has become a way station for visiting masters from Japan and elsewhere who give seminars attended by aikidoka from miles around.

http://www.tam-aikido.org/history.php

George Leonard, in about 20 years at Mt. Tamalpais Aikido Dojo produced only about 40 black belts out of thousands of students. In San Jose, at a single ATA “Black Belt School” of the American Tae Kwan Do Association they churn out that many in a single year!

So what does a black belt mean to the general public? What can be expected of the two black belts? Would the Aikido black belt defeat the ATA black belt? Could 20 ATA black belts beat one Aikido black belt? Which has a greater impact on society? Consider the impact on the individual obtaining the certification! Does this make any sense to compare these very different certifications for something called by the same name?

What is a meaningful certification?

A Social, skills and experience-based grading system: Aikikai Grading System

Consists of minimum amounts of time spent training plus demonstration of specific techniques. At the higher levels, social interaction and publications are required.
http://www.aikikai.or.jp/eng/gradingsystem.htm

So what’s the purpose of certification? To get more clients?

A Sufi Story about consulting:

Two mothers talk about their sons.
One says, “And how is your boy getting on as a guru?”
“Just fine,” replies the second. “He has so many pupils that he can afford to get rid of some of the old ones.”
“That’s great,” says the first. “My son is getting on so well that he can afford NOT to take on everyone who applies to him!”

http://www.katinkahesselink.net/sufi/stories.html

My Certification

My first agile certification was ScrumMaster. Attending the class opened me up to a whole new world of agile practitioners. Before that I was mostly reading books on my own and talking up a storm to my non-agile and mostly baffled and skeptical peers. I doubled my excitement and commitment to learning agile. It also helped me get my first agile gig at HP where I learned by immersion sometimes in hot oil! I didn’t stop there, taking the Concept to Cash Poppendieck’s course to supplement my knowledge of agile with lean transformational practices. The end result was greatly accelerated experience in and understanding of lean and agile principles and practices.

Your Certification?

What’s your story? How did you feel when you got your various certifications? Did it change you how you feel about yourself? Did it win you praise or perhaps better, income? What did you learn on your way to earning it? Was it worth it? If you have no certification, do you feel left out? Has it been a disadvantage? Are you planning on certain certifications?

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…