XP 2010 Open Spaces -- Agile Welcoming Circle

Throughout the conference I was talking to anyone who would give me an ear about a new idea I'd like to pursue: the Agile Welcoming Circle. To get further input on this idea, I held an open space session and invited everyone to come talk. If you have ideas/concerns/comments, please comment on this blog or join the Agile Welcoming Circle discussion group. Pictured right, thanks to Hubert Baumeister, I am describing the Open Spaces session.

60-Second Pitch

The Agile Welcoming Circle is a way to help get people plugged into the Agile community. It provides a landing page, which describes the common basic principles of Agile, and allows people to pay dues ($100/yr?) to join a facilitated discussion group. Their dues give them direct access to a list facilitator, who will get to know newcomers by identifying their interests and then connecting them to an appropriate community--be it a conference, user group, list serve, etc. Once the newcomer shows up at one of these events, as can be vouched for by another community member, they get a Certificate of Completion--meaning they've demonstrated some kind of a commitment to the community. This Certificate is something we'd be happy to see members put on their resumes, because all it really means is that they agree to support the community in some way. So, for example, a newcomer who wanted to learn about TDD would get hooked up with a code camp, and later may return to ask about pair programming.

The first facilitator would be me, but soon it would be run by a committee--and would be supported through Welcoming Circle dues (I think a portion of the proceeds would go to facilitators, and the rest, say 70%, gets dumped back into the program budget, to sponsor more local conferences, speaker travel expenses, etc.). The facilitators would also work on a program to increase retention after the Certificate of Completion, for example, by tracking/logging activity on a new social media channel on the main site (thereby creating an MVP list), or other means. I see this as a way to reach an audience that the Agile Skills Project, with all its overwhelming depth, couldn't reach--the newcomers.

Open Space Ideas

The biggest two concerns I've been hearing about this program are about retention after the initial subscription, and about yet another paper-based certification. Yet this time I think it's different--there will be no easy way for a cottage industry to build up around this, as its revenue is very constrained. By keeping registration costs low, it makes the whole program more democratic-it is a community-based system built to support community learning. Imagine, as Sumeet Moghe proposed (a leader in the Thoughtworks Learning Community), a great river of free information available on the Agile Welcoming Circle's member page--no simple RSS feed--but a Web 2.0 / Enterprise 2.0 flow of information that gets commented on / rated by readers, and then high-rated content comes to the home page. It would become a matter of prestige to get highlighted on the home page--and people who participate in comments or who publish would have to be paying members. The information is free--publishing is not (but rating is free). Editors/facilitators would also be able to promote content to the home page. We could also recognize helpful members through an MVP program.

Background

This discussion initially was focused around my frustration with the slow growth for the Agile Skills Project. I told people like Marc Bless and Cory Foy that I was going to drop out of the project, and they weren't happy with that. So I started talking about what I have energy for--helping the newcomers to our community. The idea is simple enough to try out, but it diverges from the charter of the Agile Skills Project, so I needed something new. I also want to devote more time to this project than I gave to the ASP, and to do that, I need a revenue model. I don't think anyone should make enough money out of this Welcoming Circle to make it a full-time job, but I do think it would be nice if it could pay for one day per month, or even one day per week, for several facilitators, depending on demand.

XP 2010 Session Report -- Catalyzing Lean - Building a Limited WIP Society by David Anderson

Mudi: non-value added

Muri: uneven

Mura: overburdened

David Anderson delivered an excellent keynote on why WIP (work in progress) limits are important. While he knows of some software teams who are applying lean by removing waste, he looks forward to hearing more reports about lean used to improve the value produced by these teams. He initially started with lean because he saw it as a way to more methodically measure the impact of software process improvement efforts (he's the SPIN founder). He also emphasizes that there's no reason we'd need to throw out iterations--they are not inconsistent with lean--XP in fact is a very lean process--but he wants to decouple the cadence of software delivery and iterations. He wants to see work scheduled by the opportunity cost of delay, to see value optimized by offering classes of service on requests, to see risk managed with capacity, and more. He sees plenty of opportunities for better applying lean to software.

XP 2010 Session Report -- Culture and Organisation by Diana Larsen

(note--I'm not sure if I got the title of this track right)

Diana Larsen reported that over 75% of organizational change efforts fail--and by fail she means it hurts so much that it brings down the whole company or causes significant loss in profitability. She talks about culture and its power--it is the glue that holds us together, that distinguishes us from others, and gives us a context for working together. She points out that culture can change, and that if we want to change it, we need to leverage its propensity to change naturally--we need to work with its strengths.

Change happens when a culture is dissatisfied, can envision a better future, can see the first steps to change, and all these together are greater than the resistance. She also spoke about the life cycle of culture (pictured right)--from clan, to hierarchy, to market, to ad-hocracy. Clans are internally focused, they support flexibility and discretion; hierarchies are still internally focused and are concerned about efficiency and structure; markets are externally focused and value results/winning; ad-hocracies are externally focused, interested in tents, not palaces--innovation, flexibility and discretion. Cultures tend to cycle through these categories over and over. While all models are wrong, this model can be useful in finding out how to help the culture change--it's appropriate to use charisma to sell an idea in a clan; it's important to get executive support in a hierarchy, and so forth.

XP 2010 Session Report -- Software Craftsmanship by Cory Foy

Although I have signed the "craftsmanship manifesto" I have misgivings about it. Though I agree that we need to do quality work, I don't think that's necessarily what's holding our teams back from delivering more value to the business, and therefore cannot be the sole focus of our software process improvement initiatives--I think that the real points of pain in the industry are long feedback cycles and inadequate communication. So I went to the Craftsmanship session with a bit of a bias. The delivery of Cory's talk was excellent--he was energetic, well-spoken, enthusiastic, and used his slides very well. He started with storytelling--in fact, a story about a business executive who sat next to him on the plane, complaining about internal software staff who just wouldn't deliver the business value he needed. Instead, this executive was frustrated by all the roadblocks the software teams were mounting (including questioning/challenging projects, technical veto of proposed solutions, and technical debt). He went on to ask whose fault it was that we have so much technical debt... and of course it's us. He said that this movement was kicked off by Robert C Martin's tirade at some conference that we need "quality over crap!". It's the design of our software that we need to focus on. I liked Cory's statement that we need to know what problems to focus on/solve, because there's no shortage of problems--but there is a shortage of time and energy, so prioritization is key. My notes also have a re-write of the agile manifesto stating "delivering value over working software over comprehensive documentation", but I don't know if Cory brought that up--I know it's something Kent Beck mentioned at the recent Lean Startup conference... Unfortunately, the rest of what I see on my notes are criticims of the talk--a complaint that the "craftsmanship" is gender biased, and a complaint that the quality of our code is not why the business is frustrated with us. It was hard for me to wait until the Q&A section of the talk, because I just kept thinking of more and more reasons why a focus on Craftsmanship seems wrong to me. So my question to Cory was something like: if you could go back to that business executive and show him how you'd cleaned up all the code for the software teams he'd been complaining about, do you think he'd be happy? I think not--I think he wants responsiveness and the ability to deliver the right things. I think there needs to be a balance between agility and craft--and in fact, we can have both--but I think it's too seductive to focus on the things we have direct control over. The biggest problems, the biggest benefits, are related to cycle time--and fixing those problems involves the whole company.

Photo credit Hubert Baumeister.

XP 2010 Session Report -- How Do I Measure Up?

In "How Do I Measure Up?", I started by reconfiguring the room into a circle--because I wanted to make it clear I was a facilitator, not a lecturer. Inspired by Peter Block, I really focused on the layout of the room, the lighting, and making the room inviting.

When the audience arrived (4 people), we identified everyone was already familiar with both the project and the self/peer assessment form I'd prepared. Instead of following the plan I had for the day, we talked about the mission/goals of the project and why we get so much interest for the Agile Skills Project but so little retention. It was useful to have a high bandwidth discussion, because in summarizing the primary goals from my perspective, participants could give me quick feedback that this had not been clear from the web site. I admitted it was too complex--but that I had been trying to pivot the project, first from an inventory, to a quest ecosystem, then to a self-assessment tool--all to no dramatic change in user retention. I concluded that the Agile Skills Project has nothing the customers value much, be it at beginning, intermediate, or advanced levels. There are other complicating factors--it was trying to be all things to all people, it was not really doing anything wrong, but not anything terribly right, either. I left the meeting pretty heartbroken, since I've nurtured the project for the last 9 months. Though I'm ready to let go of the project, the one remaining desire--to help the persona "Anna"--still remains. I feel like I was Anna 11 years ago--someone who really wanted to improve agile skills, but couldn't find a mentor or learning path. I worked on my MCSD credentials, read Steve McConnel, and went to grad school at night, and lost 4 years stumbling blindly on my own path of what could have been a much more effective adoption of agile. I've been doing XP to some extent since 1999, but it all clicked in 2005 when I started going to Agile Philly. So I really identify with Anna, and want to provide a low-cost means of welcoming her into the community. Stay tuned--and if you have ideas, let me know. I spent my free time Tuesday and Wednesday talking to people like Cory Foy, Joshua Kerievsky, Phil Brock, Diana Larsen, Sal Freudenberg, Mike Sutton, Marc Bless, Jeff Patton, Yves Hanoulle, Deborah Hartmann Preuss, and anyone else that would give me an ear and advice to build this vision. Find out more at http://groups.google.com/group/agile-welcoming-circle-committee.

XP 2010 Session Report -- User Story Mapping by Jeff Patton

This session was interesting to me for two reasons--I thought Jeff's presentation style was effective, interesting, and sufficiently dynamic to keep the audience engaged. He'd often ask us questions and draw up the responses on a flip chart. He clearly knew the material well and actually had his own answers--yet he was guiding us well enough that the group discovered much of what he had already added on subsequent slides in his presentation.

The content of the presentation was a good fit for me too. Jeff's system of User Story Mapping solves a lot of problems I've seen in the field--problems that I've solved in similar ways. First, he pointed out how user stories are different things to different people--for a business owner it may be a part of a business process, for a user it may represent the repetitive steps of a manual task, for a developer it may pose architectural hurdles. Each of these people would choose different key words to describe the story, as well as different levels of abstraction. So instead of seeking uniform descriptions, Jeff will ask clients to identify all the detail they can in a one day workshop. After capturing a large number of stories, he asks people to sort the stories in approximate workflow order, then to identify themes (epics). He argues that the epics are distinct dimensions of the product and can't meaningfully be prioritized against each other, but within an epic, stories need to be grouped into releases. Read more about this system at http://www.agileproductdesign.com/blog/the_new_backlog.html.

It is thought provoking to consider the pros an cons of his method for displaying all stories and epics on the same story wall for the life of a product (or at least the next three releases). When I worked on a mature product that was releasing much more frequently, this kind of forethought was definitely not necessary. Now that I'm working on new product development, though, it's very helpful to see how new functionality fits in with the big picture. My current team uses an adhesive surface for our story wall, and shows much less information. We add stories that don't fit in any theme and stories that are in the current iteration. We add everything else to an envelope, give it a clear title, and stick that on the wall too. We can move the entire envelopes around the story wall to show which ones are active, and we can remove the envelopes from the wall to throw all the cards on a table when we need to talk about the epic in detail. I think that these discussions would always happen on the story wall in Patton's teams... but it's also possible that we pay for the convenience of carrying one envelope by having less visibility and fewer discussions about inactive epics.

XP 2010 Trondheim

Normally conferences knock me off my routine

so much I don't blog about them, but this time I'm determined to write about what inspired me before much time slips by. XP Trondheim was amazing for me--it was hard yet energizing, and the best thing I got out of it was a chance to talk, directly, with a lot of people who I've met online in discussion forums, or people whose blogs/books I follow. For example, pictured right you can see me chatting with Diana Larsen (co-author of Agile Retrospectives and chair of the Agile Alliance board), on our way to the conference banquet Tuesday evening (photo credit Hubert Baumeister). This rest of this blog will include general comments about the conference as well as links to my session-specific comments.

As I've mentioned here before, I'd never been to a large conference run by the Agile Alliance, all due to cost--though as the years have gone and I've read the post-conference blogs I've been feeling more and more left out of some great discussions. I've succeeded at bringing some of those discussions to my own back yard, by supporting, organizing and speaking at small (free/low-cost) conferences and meetings, but I was really curious to see what else was to be had at the big events. So this year, when I realized I'd get free entrance if I were a speaker, I submitted proposals and got accepted at Agile France and XP 2010 Trondheim. In addition, as soon as I announced my plans to go, my employer graciously picked up travel expenses (thanks, Smartesting)!

While I've proudly stated that user group meetings (like Agile Philly) and Agile Tour can run conferences at 1/10th the price of the big conferences, I should have admitted it was not a fair comparison. Part of the reason I wanted to go to XP 2010 was to see, for myself, what the difference was, and I have concluded both kinds of conferences are necessary. I think that for many practitioners, attending a big international conference like this costs around one month's salary, and if their employer won't cover this expense, it's not affordable. This pay-to-play dynamic is something I want to fight against. On the other hand, this conference attracted so many attendees and speakers from all over the world that we were able to find people who were experts on any particular agile topic. I was able to ask Esther Derby (when I was at Agile France) what she thought about games and simulations in a stable team environment--and was happy to hear that, like me, she doesn't often play games in teams--they're more for conferences. I was able to ask "clarifying questions" of speakers like Cory Foy on the Craftsmanship session (though he later said I was grilling him) and David Anderson (during his talk on lean--I got stage fright as I asked a question in front of the whole conference body so I don't remember what he said--but I think I asked about how to control for side effects of measuring something like wip limits) and Mary Poppendieck on her views of slack (she hasn't seen it work when it's a fixed percent of the week or it's on a dedicated day) and product ownership (POs should only be conveners, and teams should prioritize their work and take responsibility for success of their product). Still, these interactions were not all--I was also able to connect with practitioners who I already know through the online community. It was always flattering when someone came up and said hi because they recognized my name (happened maybe 10 times), and it was really fun to associate names and faces as I did likewise for people I recognized. We were often able to drill deeper into conversations we'd had before, or talk about new things, like bringing an Agile Tour stop to a city near them ;)

The first day was all about workshops, including the one I did on the Agile Skills Project: "How do I measure up?". I arrived at the conference around 10am, tried to check in to the hotel, but no rooms were available yet. So I picked up my registration packet and went to my first official session, User Story Mapping by Jeff Patton.

There was a 30 minute pause after every session--food and discussion--perfect. Though I always had a hard time breaking the ice (and I felt terribly lonely for much of these networking sessions), I wanted to meet new people and so I just kept saying hi to strangers. By the end of the conference every time I stepped into a room I knew a few people. I'm sure that if I had stuck with a smaller group of people the whole time it would have been easier, and maybe I'd have had stronger connections with those folk--but I think that I can follow up later on every connection I made, so I just kept reaching out to new people.

Main conference sessions were organized in an innovative fashion--they had a primary speaker followed by several 10 minute talks about research and experience reports. Unfortunately, these speakers didn't coordinate their talks in advance, and there was a frustrating amount of overlap. I'd like to see them be more organized and to see sessions that are run in more of a pull fashion--I feel like there wasn't enough discussion. Regardless of the lower bandwidth presentation styles, I really got a lot out of Scott Page's keynote an Diana Larsen's talk on Culture and Organization.

The second day of the conference ended with several hours of open sessions - starting around 6pm. I suggested a couple topics near to my heart--but ended up only running one: the Agile Welcoming Circle. There were two other open spaces sessions I really enjoyed--one was on serious games (I liked the game where we stand in a circle, eyes closed, and count to 20 without speaking over one another, and also the game where we all stand in a line and step forward simultaneously). The other session was called Overcoming Fear at the Workplace. Though I don't necessarily agree that fear is something that should be overcome--I know it is a very important topic--and is well summarized by Ralph Miarka here:http://www.miarka.com/2010/07/09/open-space-session-on-overcoming-fear-at-the-workplace-at-xp2010/

On the last day of the conference, Deborah Hartmann Preuss and I ran a workshop called Speak Like a Native. I was happy with the outcome and hope to run the workshop again soon.

Agile France 2010

Bruno Sbille opened Agile france with a keynote on learning channels, with a title that could be translated as "Neuro-linguistic Programming and Agile: eyes, ears, and touch." He explained that while we can all learn in multiple ways, people have one or two channels they prefer. The channels are visual, auditory, and kinetic. While he did practice what he preached, by inviting us to wave, clap, look at, make a noise, or otherwise connect with other people in the room, I was a bit frustrated that it wasn't more interactive.

In the second part of his speech, he presented a model on drama in the workplace, in which he identified the major roles that people play when there is a bout of drama: victim, villain, and hero. He then explained it's our job to recognize this role-playing, and to diffuse it. For example, a victim can refuse help from the hero; a hero can hold back from solving problems.

Oana Juncu led a session with a colleague (not sure of the name) called "How to assess the success of an Agile Project". I was interested in it because I am curious about quantitative metrics that can be used with minimal side effects; instead we discussed intangible factors and qualitative measures. Still, the session was effective and high-bandwidth; we identified success factors as a group that included things like responsiveness to learning, flow of value, reduced turnover, flexible yet stable code, etc.

For the day's first pause, I was busy setting up the room for our talk, so I didn't get to network.

Next Olivier and I presented "Speak Like a Native". We had about 20 people, including Esther Derby who had come, I suppose, in hopes for an English-speaking topic, but that it was not. We set the stage by giving a business context, then explained one user need at a time to each of the 3 teams--their task was to draw a user interface. As soon as they had something that looked potentially useable, Olivier or I would go do a "walk-through" by asking what happens when we click on buttons or select certain fields. It was designed to make people frustrated, and that it did. Then we did a retrospective to see why it was frustrating, what we might have done to make it go better, and we re-ran the activity. As always, we finished with a feedback piece--this time using a Blond ROTI.

At lunch, as I usually do, I introduced myself to someone I don't know and ate with them. We talked a little about where they're from and what they do, but didn't exchange contact info. After lunch I bumped into a few Agile Tour organizers, including Colin Garriga-Salaün and Gabrien le Van, then I wanted to go to Esther Derby's session but it was too full, so I headed out for the airport. It was good to have a little extra time to get there--the subway wasn't too full and I didn't have to rush.

XP 2010 Keynote by Scott Page

Scott Page delivered an impressive talk entitled "Leveraging Diversity in Parallel: Perspective, Heuristics, and Oracles". The mechanics for his talk were excellent--he started with a personal story about his youth, drawing us in to the first point of his talk: how new perspectives can make hard problems easy. He then expanded upon it by showing how multiple heuristics can be more valuable predictors. He noted that this flavor of the wisdom of crowds only works when we have a sufficiently difficult problem and all contributors have a minimal competency to evaluate the problem--but at the same time they must have sufficiently different backgrounds and training that when they're working on a problem they see it from different perspectives. He also spoke about oracles--something used to evaluate whether we've got the right answer or not--and said that wisdom of crowds is most important when there are no oracles. When we have oracles, we learn faster by incorporating their feedback early and often. Thus, multiple perspectives on a team are part of the magic that makes a team greater than the sum of its parts. On a larger scale, the wisdom of crowds increases the intelligence of groups too, when everyone is at least competent enough to make an educated guess and they offer different perspectives on the problem. He noted that some companies are now using a swath of employees/algorithms to more accurately predict markets or elections or even Netflix recommendations. He also explained that experts are often horrible predictors of the future because they work predominantly with a small set of models. These models bias their processing of data, and make them poor "oracles". Scott provided mathematical models for all of his arguments, but I don't buy them. As he said himself, reducing people to one statistic (such as an IQ score) is overly limiting. I think the same can be said of equations as a measure of diversity in a team... it is overly limiting to see what effect that equation will have on the accuracy of predictions on the team. Maybe that wasn't his point--he simply wanted to use math to back up his arguments. In any case, I have to admit that he used a diversity of perspectives to tell his story, and I can appreciate that. It was a very captivating talk, and one that would be worth watching online.