Shared Vision

Last night I was at the Santa Cruz New Tech Meetup with Artist Elizabeth McClellan and captured this time-lapse movie of her illuminating drawings of the event as well as some interesting photos. Google showed off Google Earth layers http://earth.google.com/tour.html and mashups, PayPal showed off open and micro payment APIs, http://x.com/ and Digital Media Factory http://www.digitalmediafactory.net/ featured their awesome design and production facility and movie/game/music/art making resources. Wine, Upper Crust Pizza (late but worth it) and lots of networking opportunities made for a high value event.

I just returned from an empowering time at the Agile Roots Conference and saw many fun and useful presentations and workshops. I am an Official Innovation Games® Facilitator, so I was excited to help out with Luke Hohmann’s keynote presentation on Software Powered Innovation Through Collaborative Play.

After a few minutes explaining the value of games in fostering collaboration, Luke began the Innovation Game® Spider Web, where participants (nearly all conference attendees) were given 2 pieces of paper and a set of crayons, instructed to write their name at the center and draw a circle around it, then surrounding this, to draw the names of the people they interact with at work connecting those people’s names to each other and the participant. The more significant the interaction , the thicker the connecting line.  After this, the participants were instructed to use the second paper in a similar way, but instead of putting peoples names, put their roles or titles. This can be useful for discovering the full milieu in which you work, accenting relationships of control and influence.

I was walking around the room making sure everyone had supplies needed and noticed the interesting variety of drawings. (there was no example given purposefully). Some drew a single large circle and put the names on its circumference, others created something that looked exactly like a real spiderweb with many interconnecting lines, others dispensed with the circles and just used text. One individual used dots and initials to represent people efficiently.

That’s the beauty of these games, everyone can work with their own imagination and knowledge in ways that they are comfortable with. In fact I overheard several people commenting on the insight they gained when they re-discovered relationships of influence. and how they were going to work those when returning to work.

Look for more experience reports in upcoming blog entries.

For the last month I’ve been preparing for a workshop entitled: “Using Skits and Storyboards to explore and communicate the product vision” along with my colleagues, social media maven Amy Lightholder and artist Elizabeth McClellan.  We’ve also been preparing to demonstrate the process of illustrating a persona with the purpose of bringing more humanity into the product vision.

I’ve learned how much better and more fun the outcome is when collaborating with others.  The organizers of this conference have been so friendly and have such a light touch to what they do, the preparations and coordinations have been effortless and in a true just-in-time lean manner.

well, flight is leaving now, more later…

While looking for opportunities as an agile coach recently, I found myself bewildered by the huge variety of expectations.

When I heard Pyxis was looking, I checked out their Agile Organizational Coach job requisition and found it to be heavily focused on management experience. “educate managers to the application of Agility to their management style” and “Over 14 years of experience in managing software development teams”.

Rally wanted consulting experience in their top qualifications: “Prior Consulting background– you will be working with multiple clients through on site collaboration and remote support. Experience leading consulting engagements.”

EBay wanted it all:

• Create & deliver Agile training…
• Coach Product Owners, ScrumMasters…
• Influence all levels…
• Evaluate current product design approach…

In order to regain peace of mind (well, not really, just backed off the edge a bit), I have broken down the role of ‘Agile Coach’ into the different styles of practice that I’ve seen along with some living examples. This helps me understand what type of coaching they are looking for as well as know better what I have to offer and where I want to grow next. I’m sure I’ve missed some styles. Please contribute your own:

Agile Expert Advisor/Therapist
Has lots of experience and facility for agile, has read most of the good stuff on the subject, a domain expert, understands and internalizes the principles. Translates that perspective into a shoulder to cry on, a sounding board. Provides advice and pointed questions for the agile naive in transition. (Henrik Kniberg)
User Experience Dude
Translates the vision into a usable solution by working with users for designing UI and interaction. (Jeff Patton)
Product Owner
Agile point of contact or liaison to marketing for the dev team. (Anu Ramaswamy)
Product Marketing Mgr
Assesses and addresses the market, codifies the vision, then shepherds product realization. (Kathy Rott)
Professional Facilitator
Like a referee, makes sure everyone plays nice, understands and controls group behavior promoting innovation or better, quicker decisions. (III and Ainsley Nies)
Professional Mediator
Resolves disruptive conflict through strictly controlled gatherings and patiently persistent personality. (Tom Looy)
Trainertainer
Provides a working vacation for stressed out employees and managers using games, simulations, guest speakers, demonstrations. (Chris Sims)
Master Craftsman
Demonstrates the practices and ways of the agile craft as a member of the team to speed acquisition of skills and agile thought patterns. (Elisabeth Hendrickson)
Medic/Shaman
Arrives in a crisis ready to quickly triage disrupted organizations and gets them on the path to healing and harmony using social psychology. (Matt Gelbwaks)
Certifier
Provides training classes so folks can get a start in a new field or meet requirements of sponsor. (Tobias Mayer)

This blog is about helping people collaboratively build valuable, delightful and compelling  tools, services and experiences for others.

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

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

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.

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.