Larger operations typically exist in a massively mediated milieu. Customers are rarely seen and served at headquarters where many decisions are made. Workers are strewn across the globe in various time zones, most never having met each other.

What can we do to retain the immediacy of a small operation yet obtain the power to serve on a larger scale?

As companies scale there are demands for more and diverse talent to address more diverse needs. Drawing talent from a larger pool helps, but introduces a new problem of collaboration over distance. Several solutions are typically tried:

1. Create Satellite offices or branches
2. Establish Audio and Videoconferencing in meeting rooms to extend to those offsite
3. Bring people in to meet and work at headquarters or a conference facility

These all can help, but have their limitations. Satellite offices typically do not contain a fully independent work group, requiring tedious teleconference meetings to stay in sync. Bringing people in disrupts their local lives, burns a lot of fuel and expense, and  is exhausting to most so that when they arrive they are not at their best.

How many of you have watched expensive video conferencing facilities gather dust in the corner of a conference room? Why is this? I think it is because the work does not get done by sitting in a conference room for an appointed time. It is done throughout the day, in front of a large chart or visual project tracker, by a couple folks at someone’s workstation, in a discussion while getting coffee with workmates. That is where the meeting of minds occurs, through courageous personal discussion and casual osmotic communication.

How to make this happen in a distributed situation?

One unexpected solution I’ve come across is a tele-presence robot from AnyBot a Silicon Valley startup. It can exist with the team, go where the team members go, see and hear what they see all while conveying its perspective to an operator who could be clear across the globe or down the street, at home with a twisted ankle. I’ve tried this out and am amazed at the feeling of being there that this conveys. An operator can use a web browser to log in to the robot, see and hear from the robots location, drive it around, speak through it, display their live video feed, and point at things using a green laser. People seem to accept it readily after the ‘Gee Whiz’ factor wears off.

I can see using this when working with clients who are across the country from each other.  After establishing a strong foundation in person for several days, I could leave behind my trusty Anybot and either go to the next client or return home, attending to the team during certain time slots without requiring them to stop what they are doing to file into a conference room. They would be able to ‘show me around’ to the various workgroups, workspaces and visual management tools just as if I were there. What a great way of being in two or more places at nearly the same time! I’ll have an opportunity to trial this soon and will update you on how that works out.

What do you think? Would this solve any distributed team challenges for you? Would you use it for telecommuting? Serving customers better? What would the pitfalls be for you?

In the next installment of this series I will be talking about the structure of organizations for optimum sustainability in Chaordic times, involving attributes such as robustness, agility and variation.

Want to learn how to get your team to make safe and sane tradeoffs between business priority and team estimation effort?

Check out my ‘Fair Tradeoffs’ game!

I’d love to get your feedback on this agile game proposal for  AgileGames2011

You can get more details and give feedback on my game at http://uservoice.com/a/1M5xu

Twitter feed is #AgileGames2011

What if a story is large but very desirable? Do you trade it for 4 smaller, but lower priority stories just to get more features done? What if there are many small stories and 1 large one, but the large one is lower priority? Do you squeeze it in by dropping a small story or split it so the higher priority smaller stories can be delivered? Since stories are not immutable and can be split, opportunities for many tradeoffs exist. But how to manage them? How to visualize those tradeoffs?

Inspired by Steve Bockman’s Team Estimation Game, I added another dimension: Priority, and came up with an effort-priority quadrant for facilitating the difficult tradeoff between effort and priority during sprint planning. I tried this out several times with a complex product and diverse team, gaining quick and lasting agreement on planned work for the sprints.

Since no one can properly estimate what they don’t understand, the team reviews the stories in advance with the product owners to get an idea of what needs to be built and what it might take. Ideas for preliminary tasks or steps are appended to the story description to make it more relatable to the development team. Additional acceptance criteria are added as discovered.

To prepare for the estimation, write or print out the stories on cards or stickies so they can be positioned anywhere on a wall or whiteboard. Write discovered tasks on stickies or labels and append to their stories so the tasks can be moved together as a ‘package’ or moved to another story. You could also just write them on the story cards and rewrite them as needed.

Graphical Instructions are in this slideshow:

At closing, hold a 5 minute meeting review (mini-retrospective) with team or just by ScrumMaster and product owner and tech lead for how things went

Of course, the ScrumMaster needs to represent all stories and tasks in an issue tracker, document repository,story map and/or agile wall to reflect effort estimation and updated priority

I hope this is clear enough for you to adopt this tool to facilitate easier sprint planning. Please let me know what you discover, improvements, advantages and drawbacks.

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.

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…

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)

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