Dhondt Says It's Agile

Conflict Resolution Styles

2012-01-14T08:19:00.000-08:00

In Lyssa Adkins' book Coaching Agile Teams she talks about conflict resolution styles, because constructive disagreement is key to working as a team. She refers specifically to the Thomas Kilmann Instrumet (TKI), so I decided to take an online exam to see what my style is (take yours at http://peace.mennolink.org/cgi-bin/conflictstyle/inventory.cgi). Since this is a free version I wonder if a paid version would give more analysis; I also had a hard time separating individual conflict with what I do when helping team members deal with conflict amongst themselves... but overall I think these results match my strategy.

Preference: Collaborative Conflict Resolution
Normally I engage others when I see conflict by attempting to collaborate, to find win-win solutions, but if that makes tempers flare, I'll back off, and address the issues one-on-one in private (as represented below in the storm column). Also, when there's conflict, after my attempts to bring attention to it in a non-violent way, if I am clearly hurting someone else, I'll back off and try again later in another way--but my predominant style is to collaborate. Another thing I see in these scores is a strong preference when people are calm, but when that doesn't work, I don't have a strong preference--it shows I'm trying lots of different things to get us to a winning decision, or to avoid causing more harm.

*Test results thanks to MennoLink.org

Calm
(First preference)

Storm
(Preference when issues worsen)

Score	Style
12	Collaborating
11	Accommodating
9	Compromising
8	Forcing
6	Avoiding

Score	Style
7	Avoiding
6	Compromising
5	Accommodating
4	Collaborating
4	Forcing

Read more about these five Styles of Conflict Management

Personality Style
While I was in the mood to take online exams, I decided to follow the advice of Patrick Lencioni in The Five Dysfunctions of a Team--to take a Myers-Briggs personality test. I've been talking about how my preference for introversion is getting weaker in favor of extroversion--but hadn't measured it in over a decade. With this exam (http://www.humanmetrics.com/cgi-win/JTypes2.asp), I found out I'm still more introverted than extroverted, but only moderately so. I'm still an INTJ, which is "Introverted, Intuitive, Thinking, Judging"; I also found out I've become less judging, more emotionally in tune, and more spontaneous. This transition probably arose because I've been working on being more empathetic--I find that trying harder to see other people's perspectives makes me a better team player and a better coach. When I set aside my own preferences, in favor of trying to see what other people see, my MBTI profile has changed in a measurable way too.

Conflict Style: There is No Hierarchy
After everyone in your team has taken the test and identified their conflict resolution style, it's probably best not to judge whether any of these conflict resolution styles is better than another. Instead we'd like to just know that's a person's preference, and knowing that can help us understand what's going on when suddenly someone storms out of the room or starts yelling--it's a sign they're perceiving conflict and their style is Avoiding or Forcing, respectively. Another sign of stress could be a team member giving in too easily--showing that he or she is being Accommodating or Compromising because of the stress.

Judging aside, I think that conflict avoidance works in the fewest situations--and so it surprised me that it was my preference in stressful situations. Let me explain a bit more. Often I associate avoidance with passive aggression or depression of one's own needs--but there's another way to look at it. When I'm facilitating a meeting and tempers flare, I often predict it won't end productively, so I focus on de-escalation. The idea is to stop the damaging remarks, and wait until everyone is cool & collected enough to listen to others' perspectives. At home we use this technique with our kids, learned from the years when our children were going through their "terrible twos"; our keyword to trigger this behavior is "disengage!" It's simple and effective, because we're no longer feeding into the meltdown.

Conflict Style Selection is Situational

While collaboration is most often the conflict style we seek in a self-organizing team, sometimes it's just not fitting. Imagine a medical emergency--we don't want our team to stop and brainstorm about what response would be appropriate-we need someone who is competent to jump into command-and-control lingo and force one person to tend to the injured, delegate the 911 call to someone else, etc. Or even consider a team where a particular technology is only known well by one team member--we'd probably want that person to accommodate the rest of the team's ideas, but to have the final say in any key decisions. By knowing your preferred conflict style, and knowing when it's appropriate and when it's not, you'll be more likely to make the choice consciously the next time you find yourself in a stressful situation!

Agile NYC version of the Multi-Sensory Kanban talk

2011-12-17T06:59:00.000-08:00

Why do companies like Toyota and Zappos open up their shop floors for tours? It's because they know visitors won't be able to replicate their culture, yet Toyota/Zappos may learn something from a visitor's questions. So these companies actually have something to gain--and little to lose. Their culture of continuous improvement is almost impossible to replicate--which is exactly what Ravindar and I have witnessed in multiple environments that are implementing Kanban. As a result, we've come up with a series of tactics to help teams develop a learning culture--nothing that would surprise you in a healthy Kanban system--but signals that aren't written about elsewhere.

This week I was invited to talk about Multi-Sensory Kanban for Agile NYC, so I've decided to share the slides here. In a nutshell, this is a talk about how to keep a kanban system healthy. We find that a focus on work-in-progress and flow blinds people to the whole system; our minds tend to lock in to either in a synthetic (whole-system) or analytic (subsystem) mode, and we need regular reminders to switch between the two. Since Kanban is normally a visual control system, and therefore the visual channel is already saturated, we encourage teams to use signals from our other senses, most notably the auditory channel and kinetic channels.

These slides have few speaker notes; if you'd like to learn more please invite us to speak! It's easy to get in touch with me-- write to andre -a-t- dhondt-teams-gel -d-o-t- com.

vote Dan Mezick for the Scrum Alliance Board

2011-12-07T13:38:00.000-08:00

If you care about the Scrum Alliance, or have benefited from its work, please vote for Dan now!

Why? Dan Mezick will make the SA stronger by encouraging discussions on ethics and promoting service over profit. Read more about him at http://newtechusa.net/agile/scrum-alliance-bod-election/
In Agile Boston, he’s led a team of organizers to live by these values: http://newtechusa.net/user-groups/ma/visionmissionvalues/

Who else is running?
If you Google the other candidates, Stephen Forte and George Gosiski, you'll see they haven't had the same reach or impact as Dan. Their qualifications show they are definitely strong Agile team members--but I'd much rather depend on someone that's a great organizer to bring the Scrum Alliance to the next level. That's Dan!

Who is Dan? Dan is an accomplished Agile coach, speaker, and mentor, has come to Agile Philly to speak, and knows his stuff. He's long been a community organizer for technology professionals, and cares about delivering value to both the community and his clients. Vote for Dan today! – it’s just two-clicks to vote! I know Dan personally and fully endorse his candidacy!

When? The elections will close in the next 10 days. Vote for Dan today!

Announcing a new PMI-ACP course with coaching

2011-11-27T18:09:00.000-08:00

Are you in the Philadelphia region (<50 miles from center city)? Want to take the PMI-ACP exam, but need help getting ready for it? I'm offering a 21-PDU, 3 full day (or 5 half-day) course. Read more at my corporate site: http://www.dhondt-teams-gel.com/services/pmi_acp_course

Why take the course from me? You'll get two half-day coaching sessions included in the price of your team's classes (for every 5 paid participants). It's hard to apply all this knowledge--so why not take advantage of a local coach that can help you implement what you've just learned?

toward more effective communication

2011-11-20T17:57:00.000-08:00

Over the past year I've gone to at least 4 workshops on more effective communication, and I'd like to comment on my take-home messages from each, rather than a summary of what happened. When possible I've linked to online summaries of the session content or an explanation of the ideas.

Powerful Questions presented by Carton Nettleton -- summarized by Sam Laing.
Assuming we have established a trusting relationship, it's much more effective to ask open-ended questions, or even questions that help others analyze a situation. Listed from more powerful to less, we've got:

Why
How
What
Who/when/where
Which/yes-no questions

The questions at the top help people process the information themselves.

Refactoring Conversation Smells by Gil Broza & Luiz Claudio Parzianello
deletion - generalization - distortion; deletion is summarized by Esther Derby.
Just as in Weinberg, Seashore & Seashore's "What did you say? The art of giving & receiving feedback", it's often very useful to extract comments from their emotional wrapping (distortion). Or, to follow up with a person for more specific information (generalization), or to ask for missing information (deletion).

Wendy Thompson's presentation of the Four Horsemen that kill teamwork
stonewalling - contempt - criticism - defensiveness
These are red flags in a team environment. When you see them, dig further to find out what's going on.

Pat Arcady's Open Space (slow download) session on Navigating Conflict with IntegrityIt was interesting to see Pat in action--she's a skilled mediator/facilitator, and she taught me to hold back more so that people around me can show their smarts when they discover what a workshop is designed to help them discover.

Failing Fast slides

2011-11-13T19:49:00.000-08:00

For Agile Day NYC, I was invited to give a Pecha Kucha talk, so I decided to cover Failing Fast. It's hard to capture a PK talk online, but the short version is: failing fast is all about learning. To foster learning in our own work environments, we invite our colleagues to be curious, to ask how we can find out sooner, and to use set-based design. Failing fast breaks the monotony of failing slowly, and makes work fun. Read more in the linked slide deck!

Freedom in Meeting slides

2011-11-06T14:40:00.000-08:00

In September at Agile Boston I ran an open space session called Freedom in Meeting (this link to the slides includes speaker notes). The short version of this talk is: when we bring open-space ideas into our daily meetings, they become more effective, are shorter, are more interesting, and have better participation from everyone.

Agile Coaching Ethics

2011-10-26T15:33:00.000-07:00

Recently Dan Mezick (of Agile Boston and Agile Connecticut) has been writing about Agile Coaching Ethics. I welcome this conversation, and agree that a coach cannot be embedded to be effective. This is something I've come to learn the hard way--and was greatly inspired by comments at Rachel Davie's Grumpy Old Coaches panel at XP 2011 (Madrid). Currently I have to admit that I do both contract work and coaching--but I have been clear with my clients that there is a difference and that I want to focus on the coaching. I've always measured my success by how well a team does after I've left--but I'm learning better and better ways to do this. My mantra, these days, is "I do nothing, I own nothing". When I follow this mantra well, the teams I work with do better too--they become Leaderful Teams.
So let's work together as a community to make expectations clear about what a coach does, and doesn't do. Here's my stab: An Agile Coach helps a team shift its perspective, thereby allowing the team solve its own problems. I also second George Dinwiddie's definition:

[A coach] build[s] the capability of the existing team. Rather than making choices for the team, the coach provides guidance about the choices available, perhaps making recommendations, and encouraging them to consider the options and choose their actions. The coach teaches the team about techniques or tools that increase their available choices. The coach offers observations about the team’s activities, and helps the team make it’s own observations and reflect on them. The coach helps the team articulate the results it wants, and generate courses of action to achieve those results. The coach partners with the team on the coaching process, but allows the team to exercise its own judgement about the software development practice. The coach does not become a member of the team, but endeavors to wean the team off of the need to consult with the coach on a regular basis.

With this kind of definition of Agile Coaching, I believe that clients will benefit even more from coaches-since there's the expectation that the coach isn't always there, and for that reason will be more likely to bring ideas in to the team from other environments. Another slant to this is that to me, a key responsibility of a coach is to go out and learn as much as possible that can be applied to the teams being coached.

What Dhondt Teams Gel is all about

2011-10-23T18:28:00.000-07:00

Too busy fighting bugs and doing rush jobs? For less than the cost of getting your team certified, contact us to coach your team to more effective, higher quality software (if you're in the greater Philadelphia region)! Dhondt Teams Gel is staffed by yours truly as well as an associate or two when we need a second opinion--all for the same, low monthly subscription. Subscription rates vary, but are approximately the same price as a one or two-day training course. Basically, you don't pay until our coaching delivers real value to your organization--and even then, we are so confident that our results work in the long haul that payment for our services is made in a two-year annuity.

Pay for Results, Not Hours
Many coaches charge by the day or by the hour--regardless of the outcome of their work. Some offer satisfaction guaranteed--but still charge before the results are realized. If we're working on cutting the cycle time of your dev team by 50%, you don't pay anything more than a flat subscription fee until you're seeing working software sooner! Our Coach on Retainer product is only profitable when we deliver results for you!

Training Plus Coaching
We also offer training workshops and soon we'll offer classes for a certification program (no official announcement yet). Since I believe that training and certifications are just the beginning of an intentional learning journey, I also include two "refresher" visits in the price of any class with 5 or more participants from the same company. It's the long-term relationships where we provide the most value, and that's why we want to visit course participants again and again.

Communication About Design Workshop Series

2011-10-16T13:41:00.000-07:00

Since a client of mine asked for help on communication skills in the team environment, I've been doing a short series of workshops on the topic (60 minutes each). For the first workshop, we did the [spoiler warning]: Marshmallow Challenge. Many participants enjoyed the workshop and saw how some of the teams had worked together while others had participants that checked out entirely. We talked about what it would take to work together better, to make a higher tower, and whether they've seen similar performance problems in the work environment. Normally I have everyone start this workshop at the same time, but in this instance we had some latecomers who began after they saw the final result of the other team's towers. The first two teams had built towers at 0 inches tall (it was unstable) and basically one spaghetti stick tall--and the latecomers were determined to win--so they focused on a design that would get them two sticks tall, and prevailed. Of note is that the teams that worked together by talking through and adapting their design ideas, succeeded at building something stable, while the team that had some people check out were unable to adapt their vision to something more stable.
For the second workshop, I adapted a game invented by Olivier Albiez and I--a brainstorming activity designed to show ineffective communication. We had 4 local participants and two remote (through a teleconference bridge). To make things more dysfunctional, I randomly gave each participant a 'vice card', with one of the following captions:

ignore it
criticize it
be defensive
say it's too simple
support it
rephrase it in your own words and ask if that's right
ask clarifying questions

We tell participants they'll be brainstorming, and that no matter what anyone else says, they're to follow the instructions on the vice card in their response about the idea. The same vice cards can go to more than one person; they're actually just a tool to save face for anyone that has a strong personality.
We set the stage by saying we're designing a fire safety kit to be used in office buildings, which includes instructions and basic fire safety essentials. All the participants are asked to do is to list what should be in the kit and/or on the instructions. As the moderator, my job was to write down any idea I heard as the group made suggestions. As you can imagine, hilarity ensued. People argued about every idea, and they repeatedly had me change the words I'd recorded. We ran this session for 7 minutes, followed by 5 minutes of observations like:

we didn't get very many ideas
almost every idea was from the two most vocal participants
people on the teleconference bridge couldn't get a word in edgewise
few people were listening or building upon others' ideas

We did one more round, this time without the vice cards, and people were more respectful of the phone participants--but the list was basically as short as before. Why no additional creativity? Here's what we came up with:

the product goal wasn't clear--was there a market for what we were building?
participants who were now listening said they didn't understand their colleague's ideas, and so asking questions slowed them down from coming up with new ideas

For the third round we said we'd pick what goes in the tool bag for a long bicycle ride. In the first 90 seconds one person seemed to misunderstand the task, an argument ensued and the confused person never spoke again. We discussed this in the observations step, but offending party didn't accept the feedback--saying that person's ideas were off-target and so were rightly rejected. Based on this, I think I'd need to do yet another round, or to change the topics for each brainstorming session so people would be more likely to learn what it takes to brainstorm effectively. Has anyone here played a similar game?
Overall, I'd say I'm happy with this workshop--I was hoping to create a situation where communication broke down, and we could get people to talk openly about it. I wish we could have gotten there quicker--and so that's what I'll work on the next time I run it.

The third workshop is yet to happen, but I'd like to get this team comfortable identifying "criticism, contempt, defensiveness, and stonewalling" during their planning sessions. I'd also like to set clear ground rules that prevent arguments, allow only simple explanations, and focus on moving forward (and even capitalizing on misunderstanding).

For the fourth workshop, I'll have the team quickly draw our real system architecture in 60-seconds, then ask what we'd have to change to support a real backlog item. There are two objectives in this workshop--to learn to manipulate our system architecture quickly and easily, and to learn to talk openly about new ideas. I don't know if we'll be ready for this by the fourth workshop, but I'll report back here!

3 Questions Considered Harmful

2011-10-09T14:21:00.000-07:00

Since I've been reading a lot of pre-agile books, Dykstra's GOTO Considered Harmful seemed fitting here. I think that the standard three questions for Daily Scrums (what did I do yesterday, what am I doing today, any blocks) should be considered harmful, because these questions force people to focus on themselves--and we want people to focus on the team! So for years I've been experimenting a lot with the Daily Scrum, by changing the format with hot potato, pull, and synchronization points, and by changing the questions:

are we on target to finish this iteration on time?
what's important?
anyone want a second opinion on something they're working on?
any decisions to be made by the group?
what's left to finish the iteration?
what can we deploy next?
open-ended questions about stories that are active
any topics for the parking lot?
any ripple effects? [that is, for something I just changed or am about to change, who needs to know and what effect with it have?]

It would be great if we had a stable list of questions, but I find it more effective to use two or 3 from the list above for a month, then to use a new set--it keeps people on their toes, and this thinking creates better communication.

To help clients and conference attendees see what I'm talking about, I've also prepared a slide deck entitled Freedom In Meeting.

Technically Philly Groups

2011-10-01T10:58:00.000-07:00

Learning and Networking
Have you ever wanted to talk to other people using your favorite new development language--but just didn't know where to go? Have you ever wanted ideas on how to improve your teamwork or software development life cycle? Or do you just want to network--trying to find a job or trying to find good recruits? Imagine a place you could go meet talented and passionate software team members--and you only had to wait for the right day of the week, since we've got events booked every week for the foreseeable future! Welcome to Technically Philly Groups, a consortium of existing technical user groups in the greater Philadelphia region and an incubator for your favorite topic!

Values

Technically Philly Groups is founded on the following principles:

Serve Others: we all do better when we share what we've got. Sometimes all we have to share is curiosity; other ways we can serve are to: teach; sponsor food for an event; bring a friend to an event. We believe in, and live by the principles of, a gift economy.
Create Relationships: we care about the long-term sustainability; we seek win-win opportunities by getting to know one another well enough that we can treat others the way they'd like to be treated.
Increase Learning: the more we learn, apply what we learn, and validate that it's useful, the better we'll be at our jobs (whether we're in a start-up environment, academic institution, public service, or established business). The purpose of our meeting together is to learn from one another, and to accelerate our ability to deliver results in our software/technical environments. We also believe that learning is maximized when we're having fun--and joy at our events is closely tied to supporting autonomy, mastery, and purpose in the way we structure discussions.

We expect Technically Philly Groups events to be a hub of innovation, communication, and learning. We know that by uniting together we'll help build a more common language for talking about technology, ideas will spread faster, and we'll be able to show what topics we value.

History & How to Join
On June 15, 2011, organizers from 21 user groups founded Technically Philly Groups. Since then we've helped promote one another's events, attracted another 10 groups, held co-located events, and have shared sponsor money to feed our attendees for free. If your group would like to join, contact us at http://groups.google.com/group/tech-philly-organizers.

loneliness and conference assimilation

2011-10-01T10:20:00.000-07:00

Recently, I've been saying that conferences leave me feeling lonely--ironic, since I typically meet 20 people per day and have interesting, deep conversations with at least 5. I know from conversations on the topic that I'm not alone in this experience, yet I also know I'm contributing to the problem. How do I contribute? It's this game I play--at every conference meal, I sit with strangers, so I can get to know more people. Sometimes we hit it off, sometimes our conversation is forced and dull. By never returning to eat with the same people, though, I'm implicitly saying that none of those new connections are important. In other words, if I don't show that "I like you" by finding you again, it implies that I don't. That's not an accurate conclusion--I'm just trying to meet more people--but the more people I meet, the more people I leave feeling lonely. With lots of people playing either this game, or sticking with the people they already know well, odds are that many of us aren't feeling the love. Within three days at these conferences, I typically have talked to 100 people or more, and I can always find someone I know to talk to during a break... but by this point I feel utterly vulnerable and lonely.

Loneliness is not just for Conferences
How do you feel, commuting to work? Watching TV? Reading a book? At the end of these activities, are you satiated? While these activities can be unavoidable, cathartic, or intellectually rewarding, respectively, they're not as emotionally rewarding as a long dinner conversation with good friends. Humans are hard-wired to seek, and to crave, emotional connection. In Community: The Structure of Belonging, Peter Block talks a lot about loneliness, and how to break the cycle by creating things together. Conference organizers, and even speakers, often feel connected to each other and to the community, due to the fact that they've worked together (in small groups) making the conference. Attendees, however, have an entirely different experience until they connect to a small group.

Self-Improvement / Specialization also causes Loneliness (and myopia too)
Since I'm so passionate about software process and teamwork, I spend most of my spare time (at least non-family spare time) reading blogs and books in the lean/agile domain. Unfortunately, all this reading is lonely work--I'd love to talk about what I'm reading with my family, friends or colleagues in the office, and often mention it--but few other people are interested. So not only does this specialization make me lonely while I'm reading, but also when I try to chat at work. All this makes events at Agile Philly and conferences more important to me.
Even worse, specialization doesn't even give us the mastery we seek. We've learned from the wisdom of crowds that experts and specialists are less likely to have the "right" answer predicting the future of complex situations than a crowd of competent generalists. Why? For any non-trivial subject, specialists must focus so much on one aspect of a problem that they miss the forest for the trees--and can't make holistic evaluations. So what good is it to isolate oneself, to focus on a topic to the point of mastery, if we'd simply be more wise if we spend time with other people?

Building Relationships
How do we break out of this loneliness? We build something together! In my next post I'll talk about Technically Philly Groups, a community built to promote networking and learning in the greater Philadelphia region.

Conference Format Can Help Too
As David Rock says, people go to conferences for a couple of main reasons--to soak up new information, and to meet new people. Rock argues that in this age of going online for our information, maybe the priorities of these two goals are backwards for most conferences. I agree. I don't want to sit in a room with 100 other people, staring at a speaker for 90 minutes, without a chance to speak up myself. If that was my goal, I would sit all by myself at home and listen to podcasts or watch conference videos. Rock breaks the mold of multi-track big conferences by imposing some interactive structure onto all conference speakers--something he calls DEAQ (at least every 30 minutes, stop for digestion, application, exercises, or questions). I don't think he goes far enough, and prefer Pecha Kucha Pull (3-5 minutes of oration designed to provoke questions, followed by Q&A, then repeat) or repetitive exercise-then-debrief. I really expect more conference organizers to focus on session format. Last year at XP2010 the organizers had a great variety in session formats, but not this year for XP2011 nor LSSC11. I'd even be happy to see more Bar Camp or Open Space style sessions... though I love Open Space, speakers rarely show up prepared to the same extent they would for a planned talk. Let's be agile about our conference talks--come with a deck of slides, prepared to talk about a variety of subjects, advertise those ideas, then let the audience 'pull' the information out of you!

Unconferences Don't work For Newbies
This past week at Agile Day Boston and Agile Day NYC, I applaud the organizers (especially Dan Mezick and Joe Krebs) for combining planned talks and open spaces in a one-day event. Even keynotes were limited to 20 minutes in Boston--letting us whet our appetites on ideas from many different speakers. Following the planned talks, we had afternoon open space sessions that attracted a huge number of topics and participants--as well as a sense of belonging!

Conference Season is Coming

2011-03-16T17:33:00.000-07:00

Soon I'll be presenting, with my colleague Ravindar Gujral, at the following two conferences:

LSSC 2011, Long Beach, California, 1st week in May: Multi-sensory Kanban
XP 2011, Madrid, 2nd week in May: You Get What You Measure

Work on these presentations over the last few months has kept me quiet on my blog.

If you'd like to see these at Agile 2011 in Salt Lake, please click on the session names above and add a public comment!

magic

2011-02-28T17:25:00.000-08:00

Magic--Beware?
As Jurgen Apelo shows, people don't trust magic. Oracles, witches, magicians, and even mad scientists have long lived on the fringes of society. A colleague of mine considers the word 'magic' a sign of incompetence or an over-reliance on luck. For Jurgen, magic is the art of illusion. Rather, he prefers the scientific method--repeatable, and rational: "When determining whether something exists or not, rely on the words of the scientists, not the hands of the magicians." But is there nothing good in magic? I recently went to a re-creation of a medieval warlock's workshop--and was captivated by the wonder and excitement he inspired in my children. As a person who focused on chemistry in undergraduate school, none of this show was new to me--I could picture the chemicals he'd chosen, explain the colors, smoke and fire, and remember working with some of these materials myself. Was the warlock's work all an illusion, all unreal? I do see that his storytelling was not an explanation of the chemistry, but what is his purpose in the show? Can we dismiss it because it is not serious? What about learning through play, the agile trend to play serious games, and multi-sensory learning in today's schools?
What is more likely to create a a desire to learn more about science--a magic show, or a dry lecture? I think that the test for what is real is misguided--why limit ourselves to what is real right now? To an extreme: is the wonder and excitement our children feel after hearing fairy tales an illusion? No! Their hope, their hearts full of wishes, drives them to play, to experiment, to try new things. Magic unleashes our imaginations, it is the key difference between humans and machines, it is the ability to act irrationally against a set of known laws and scenarios. Instead of mistrusting magic, let's use it to our benefit.

What is Magic?

To me, magic is using uncommon knowledge to produce dramatic change. Another key element of magic is the artistry--the holistic view, as opposed to the scientific analysis. Science brings us understanding, reproducibility; magic brings us inspiration and discovery. It is that which gets our feet tapping to good music, it is the way good food makes us want to share it with others, it is the power a good story or show has over our emotions. Magic is that which gives us life energy, the contagious, social power that makes us human--simply, it is passion for the work we do, it is love. Magic is what makes work fun!

How do we bring magic to work? It's hardly prescriptive. Magic may use science, timing, charisma, skill, or craft, but is more than any of these--it is an art. Just as jokes go stale, magic only mystifies when it's fresh. Furthermore, a true magician has rehearsed and knows how to handle an unexpected turn of events. We show people things they can't make sense of. We support the irrational, and we bring magic into work by staying current, by keeping healthy amounts of slack, and by practicing in a playful manner, both at work and after work.

Magic--Making Ideas Real

In a lab environment, a scientist is trying to control for variables and principles that are not yet fully understood. Science makes history repeat itself--but magic is the key to creating something new: invention is 99% perspiration and 1% inspiration. This environment makes inspiration more likely, but only rarely does one make a breakthrough to a great, new idea. All of this makes me believe that we need more magic in the software development world, just as Beck has urged us to "embrace change", and as Ghandi encourages, "be the change you wish to see in the world". It is not more control, more repeatability we need in this world--that's why we hand off the most boring tasks to machines. What we need more of is magic/inspiration. Rather than asking if something is real, let's imagine the possibilities brought to us by magic--the suspension of disbelief--the creativity lurking behind our self-imposed barriers.

hot-potato daily Scrums

2011-02-17T17:24:00.000-08:00

There's a client I'm working with that always uses a teleconference bridge to include remote team members and stakeholders in the daily scrums. Though I have done remote scrums in the past, I've always had a hard time hearing some people on the other end of the call, and I also found it to be exceedingly boring--something about the remote/virtual team puts pressure on people to talk a lot while they've got everyone's attention on the phone. A couple months ago we changed our Daily Scrums to be more self-organizing: at the first second of our 9:30am call, every developer present chimes in by announcing her/his name. The last one to 'arrive' shares what needs to be said, and calls the next developer. This forces everyone to at least remember who's on the call, and who has spoken--and it also helps people pay attention to one another better. Yet we noticed it wasn't helping the chickens much--so someone suggested yet another modification. Now, after the chime-in by developers, chickens chime in too--then it's a chicken who calls the next developer. Well, it's been great fun passing around the 'hot potato' as well as catching the chickens that aren't paying attention!

Do you have any phone-conference Daily Scrum tips to share?

fighting inbox clutter

2011-01-21T06:15:00.000-08:00

For my current client, I'm spending an inordinate amount of time reading e-mail just to keep up with what's going on in the project--inordinate, I think, because I've never gotten this much mail in any other work environment. This e-mail comes from a culture of copying everyone on the most trivial messages; another is the habit to send e-mails instead of stopping by someone's desk, calling, or sending an IM--all of which are superior in most contexts because they're synchronous. As I've mentioned on Twitter (@adhondt), I've tried sending no messages--but there are definitely situations that e-mail and its asynchronous communication is better--for example, for sending and accepting meeting invites. Yet whenever I respond to an e-mail, I find it spawns more e-mail--someone inevitably responds to my message--so I've decided the most effective way to fight inbox clutter is to send fewer notes. It's been hard for me to remember, sometimes, not to reply to messages someone sends me--so I've configured some Outlook macros to remind me. I also added a line to my signature:

* Fight inbox clutter. The total number of messages I sent today (instead of closing the loop with a visit, a phone call, or an IM) is indicated at the end of the subject line as (sent / quota).

My quota, admittedly a constant in the code, is 10 messages/invites per day--and though there are days I exceed it, I think it's my average. I've also made this a public quest, explaining to people each time I follow up synchronously to an e-mail, that I'm stopping by because I think a conversation is a quicker way to resolve the issue than to respond with another e-mail.
We're using Outlook 2007, so I set up this VBA macro to remind me about my quotas. Tell me if you use it!

'About: D. André Dhondt, dhondtsayitsagile.blogspot.com

Dim WithEvents loadedMail As MailItem

Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)

Cancel = canAvoidEmail()

End Sub

Private Function canAvoidEmail() As Boolean

Dim areYouSure As String

areYouSure = "You've already sent " & countSentMessages() & " messages today. " & _

"Are you sure a visit, a call, or an IM wouldn't resolve this? Click OK to send."

canAvoidEmail = (MsgBox(areYouSure, vbOKCancel) = vbCancel)

End Function

Private Function countSentMessages() As Integer

Dim sent As Outlook.MAPIFolder

Set sent = GetNamespace("MAPI").GetDefaultFolder(olFolderSentMail)

countSentMessages = sent.Items.Restrict("[SentOn] > '" & Format(Date, "ddddd h:nn AMPM") & "'").Count

End Function

Private Sub Application_ItemLoad(ByVal Item As Object)

If TypeName(Item) = "MailItem" Then

Set loadedMail = Item

End If

End Sub

Private Sub loadedMail_Open(Cancel As Boolean)

If loadedMail.sent = False Then

loadedMail.Subject = loadedMail.Subject & " (" & 1 + countSentMessages & "/10)*"

End If

End Sub

staying current

2010-12-08T03:05:00.000-08:00

For the last few years I've been on a quest to find out what other Agile/Lean practitioners are doing, saying, and thinking about, so I can learn more myself--and to do so I've accumulated quite a daily reading list: I'm on 15+ mailing lists, 23 blog feeds, and follow 30 people on twitter, not to mention the books I read. I really try to minimize this reading list, but I also have this unquenchable thirst to find something I've missed--something that will help me work smarter, to improve, to do better. I've often said that as a professional and practitioner, it's my job to study outside of the workplace--to learn about how other people are solving similar problems in different contexts. I think that all this reading gives me a lot of ideas in the workplace of how to approach problems, so I keep reading more.

Yet reading isn't enough. I need feedback--I need to hear how others perceive my words, and to see how they respond. So I also write, here and on twitter, but primarily on mailing lists. I post whenever I have an opinion that hasn't already been stated by someone else on the list. This helps me learn when other people argue in favor of or against what I've written. Here are my favorite mailing lists:

International:
http://groups.yahoo.com/group/extremeprogramming/
http://groups.google.com/group/lean-startup-circle
http://groups.google.com/group/agiletour

http://groups.yahoo.com/group/agileprojectmanagement/

http://groups.yahoo.com/group/leanagile/

http://groups.yahoo.com/group/leandevelopment/

http://groups.yahoo.com/group/AgileBusiness/

http://groups.yahoo.com/group/Agile-ANN/

http://groups.yahoo.com/group/agile-jobs/
Extreme Programming (LinkedIn)
Agile (LinkedIn)
Agile Alliance (LinkedIn)
Agile CMMI (LinkedIn)
Agile Philly (LinkedIn)
Agile Tour (LinkedIn)

Philadelphia:

http://groups.yahoo.com/group/agilephilly/

http://groups.google.com/group/leanstartupphilly

http://groups.yahoo.com/group/phillyaltnet/

http://groups.yahoo.com/group/phillyjug/

Other Regional:
http://groups.yahoo.com/group/software_dev_in_free-county/
http://groups.yahoo.com/group/Agile-Belgium/
http://groups.yahoo.com/group/xp-france/
http://groups.yahoo.com/group/xp-forum/

Writing isn't enough either. I need face-to-face, peer interactions. So I go to user group meetings and conferences whenever they're local, and a few that are remote, as often as possible. This always poses work/life balance problems for me--I'd love to go to even more events--but I also really enjoy time at home with my kids... Still, these face-to-face events are a great way for me to talk about work outside of work, to get other people's opinions on how I might apply my learnings more directly, and to practice my skills in a 'sandbox'.

User groups/conferences aren't enough either. I need a place to apply my craft on a daily basis. I need an environment where I can apply all these ideas I'm absorbing, then to watch to see how the seeds I planted will grow. I've been very particular over the years about what kind of environment I'll work in--and it's given me a good base to practice and learn even more.

What are you doing to stay current? Do you have ways to stay current that I've missed?

mavens and The Tipping Point

2010-12-01T17:44:00.000-08:00

There's a great quote from Malcolm Gladwell's The Tipping Point that just has my mind reeling. I can only paraphrase it right now: in an age of information overload, we rely on word of mouth to deal with complexity. The word of mouth we rely on, this primitive communication, all comes from specialists in our network. These specialists, who Gladwell calls mavens, can provide the best kind of product referrals, distilled information, and advice because they're simply obsessed with data in one or more niches. He says that it's a certain kind of person--but I'm inclined to believe we're all vessels of trivia in some category or another. This becomes important when we think about how to promote learning / competency / agile skills / decision making / etc. If we could use a networking tool and nominate our friends as mavens on one category or another, we might benefit better from our networks... is there something that already does this?

From Weak Links to Better Answers

2010-11-10T03:23:00.000-08:00

Some of the implicit questions driving me for the last couple years in the work I did for the Agile Skills Project were: how do we know who to trust, who has good advice, and who should we hire? The answer to these questions have a lot of value, as proven by the market demand for CSMs and other tech certificates, as well as for the hefty price recruiters get for matchmaking services. Yet when these matches depend on keywords in a resume, or on a recruiter's personal network, we hit one of two limits: keywords don't convey trust, and humans have a neurological limit of about 150 trusting relationships. So how do we broaden our searches for advice and/or recruits beyond 150 people? It's easy for clear-cut, objective answers--we can depend on the wisdom of crowds using things like Google's page rank algorithm, which represents the crowd's endorsement for certain advice. For more subjective questions, though, it is much more complicated.

Yesterday I read about weak links / weak ties in Enterprise 2.0 by Andrew McAfee--it reminds me of the fabric Peter Block identifies as social capital--and apparently the research about exploiting our personal networks was published relatively recently, in 2004 or 2005. McAfee suggests that the next way we'll be able to benefit from platforms like LinkedIn, Twitter, and FaceBook will be in referring our colleagues to our FAQ pages. This strikes me as really powerful for objective questions, but misguided for subjective questions. It's not the answers that my network of friends are useful for--it's the diversity of approaches they offer that is important. Since it's a subjective question, it is the analysis of factors, values or forces that will help guide me. I don't know of any scalable resource that connects people for subjective questions in this way. Do you?

There are technologies that connect people by the questions they ask--take the Stack Exchange engine for example. Yet they specifically close subjective discussions:

...questions that are not answerable — discussions, debates, opinions — should be closed as subjective. It seems simple enough: Fact good; opinion and discussion bad. But why?

Most forums and chat rooms have a scale problem. As in, they don’t. The more people that join the discussion, the more noise each of those connections bring. So the forums get progressively noisier and noisier, and suddenly one day … you stop learning.

This seems to leave a gap. Subjective questions often produce conflicting advice on list serves. How do we sort through the answers? I don't see any of these social media platforms helping me decide who to trust. What if we built a community of questions and analyses--no answers permitted, just a catalog of the values, forces, etc. that go into making a decision. Anyone want to help me out? The first place I might begin is at Stack Exchange--but we'll need about 250 committed users to go live. Let's work out some of the details first--post your questions/comments here. One thing I will have to work out near the end is the name--should it be DevIntent, Philly Tech Points, Agile Welcoming Circle, or something else?

Would you such a site useful? Would it help you answer your questions? Would you participate in it?

Agile Tour Philadelphia 2010

2010-11-07T12:56:00.000-08:00

This year, Sebastian Hermida, Bonnie Aumann, David Bulkin, Ravindar Gujral and I tried out a new conference format--and it worked out splendidly (photo album). Essentially, we wanted this to be a conference for local practitioners, by local practitioners. We sought to encourage networking and group discussions, so we divided up our 4-hour conference into a keynote by Jon Kern followed by 4 x 45 minute-long sessions and a little time for breaks. Each of the organizers invited a friend to do a talk, and we got a great lineup including:

Bonnie Aumann (The Flow Game)
Aman King and Prashant Srivastava (Agile Buzzwords in Action)
Sebastian Hermida (9 simple rules for code design)
Prem Chandrasekaran (Automated Functional Testing: Getting it Right)
Burkhard Duemler (An Incremental Move to Continuous Integration)
Ravindar Gujral (You Get What You Measure)
Audrey Troutt (How Agile is like Yoga: this $h!t is really hard but it feels good)
Daryl Richter (Don't Replace That Old Application, Re-upholster It!)
Andre Dhondt (Working with Difficult Customers)
Brian Donahue (Software Craftmanship: Building a Solid Foundation)
Darian Rashid (Personality Types)

At the beginning of each session, all 70 or so attendees met in the middle of one large conference room, and speakers each had a chance to do a 60-second lightning talk to catch the interest of attendees, and to announce where they'd be doing their talk. Within ten minutes everyone had shuffled over to their chosen sessions, which lasted 25 minutes before a 10-minute break and then another round of lightning talks. This format gave people a lot of time to meet one another and explore topics of their own interest--which kept energy high and made it really fun. As an organizer I felt responsible for making things flow--so I couldn't fully participate in any of the sessions, but I did act like a butterfly and go listen in on at least a couple minutes of every talk I could.

the Philly Agile community

2010-11-07T11:32:00.000-08:00

In the 9 weeks since I've been back to Philly, I've been able to attend about 8 events (hosted by Agile Philly, Philly SPIN, and Lean Startup Philly, and I missed one I wanted to go to--Philly ALT.NET). It's such a vibrant community! For the past couple years I've been trying to blog about every event I attend--but I'm having a hard time keeping up this time. So this entry will try to capture some of the highlights.

Lean Startup Philly is reading a book together: Steven Blank's The Four Steps to the Epiphany. We meet at lunchtime weekly to talk about the book and then how to apply its principles to the startups each of us are involved in.

Philly SPIN had a packed house for Jim Schiel's Sept 22 talk on "Quality and Productivity Metrics in Agile Development". Since I'm a big skeptic of any kind of productivity measurements, I was really curious to see what this meeting would be about. I asked a lot of questions to see how Lean/Kanban principles were being applied in the context of his clients--and basically, I get the opinion that the Scrum community seems very straight-laced. It's interesting to me because the XP community has stayed very open to changes, doesn't seem to claim intellectual property over its ideas, and often incorporates new things. Jim began his talk with a couple of really great questions--if we don't have big, up-front design documents and estimates in projects, then how can we tell if we come in ahead of schedule? How can we tell how productive we're being? I'd love to have an answer to this--though I don't know if there really is one. Software development can't be about efficiency, it's got to be about effectiveness. So then Jim continued on to talk about how high quality is a necessity for being productive, as well as being able to incorporate change into the plan, how we need to avoid overworking the team, and that we need to be cautious about what we measure. He proposes using the following measurements, not as a way to gauge productivity, not as a way to compare teams, but as indicators that there may be a problem, or even that things may be improving:

change in velocity
change in defects
number of completed stories

Agile Philly has had two Code Kata nights. At the August 24th event we tried some Architectural Kata, by working from the dry erase board. Though we didn't actually use our computers this time, it was a great chance to work on collaborative design, and I learned a new technique from Sebastian Hermida, who will be presenting it next week at Bar Camp Philly. On his teams, they wanted to get everyone involved in all the architectural decisions, so at daily sprints they'd try to sell their implementation strategy--and team mates could buy or not. If not, that triggered further discussions. Later, after coding a story card complete, the pair will again try to sell the card--to make sure everyone is on board. It sounds like a fun and innovative way to encourage team ownership of the design of all the code.
At the next Coding Kata event on Nov 4, Audrey Troutt led us in 10-minute pair rotations for the bowling game using Jeff Bay's 9 rules for "Object Calisthenics". It was really intense, really fun, and felt great to think about how we write code. We paused half way through and talked about what was happening, then spoke again at the end about what we might want to do differently.

Agile Philly also hosted an Agile Tour stop this year. I'll write about that separately.

just got banned from a list serve

2010-10-27T03:45:00.000-07:00

Here's my first post since I re-located from France. My new job has been so time consuming I haven't yet found the time to write--but I just got really worked up about a list serve I've been on for years, and so I decided to skip my run and make a stand. I'd really like to keep this from getting personal against the moderators, so I'm not going to say who did this--but here's how I see the sequence of events leading to me getting banned:

the list, as I understood it, was created primarily as a forum for users to discuss ideas and experience reports, as well as get periodic updates to the products
about weekly, the list owners sent announcements
a relatively new member of the list asked if the quantity of 'product update' messages could be reduced

This resulted in a really defensive note saying that the product updates were not spam, followed shortly by a lot of disagreement from various members of the list. Rather than acknowledging the disagreement, the moderators came out with the following statements:

Premise - This mailing list is the Official <X> group.

The <X> Team moderates and organizes this group.

We had a serious look at whether we should continue the group’s activity.

...The fact remains that this is the Official group of <X> and the <X> Team must be free to put forth any message it wishes; whether it be relating to events, courses or products. It may also decide to not send this sort of message at all.

But considering that this list is run and organized by the <X> Team the final decision lays with the <X> Team and not the members on the list.

If the participants in the group do not appreciate the messages that are being issued or the policies chosen for sending the messages, they have two choices;

(1) show their disapproval by sending an email to the group’s moderator or

(2) leave the group.

These are the group’s rules.

Any behaviour contrary to the rules means that the person will be automatically removed from the group. <X> are the moderators of this list and we will ensure the rules set out by this group are obeyed.

If you partecipate in this group you know you will receive messages about news, events, courses, products related to the <X>. (As is clearly stated in this group’s welcome message)

Should you for any reason consider our rules and policies to be spam, just leave this group. We are obviously incompatible.

Do you think this group should be different? Create one yourselves.

Should you wish to create your own non-official <X> group, you will nevertheless still have our help.

...We consider this issue closed, any off-topic message must from this point on be sent to one of the moderators following the group’s rules.

Keep in mind that the spam doesn't bother me enough to leave the group... so I stayed. Yet the hierarchical, dogmatic attitude above does bother me. So I wrote to the moderators, off-list, saying that I think the quantity of spam notes (20 this month) is hurting the list.

Then I started wondering what would happen if they tore the list down, so I sent the following, which seems to have gotten me banned:

<X>To avoid more spam we are considering closing this group...

Hi all, if they do close this list serve, please move your discussion over to http://groups.google.com/group/<X>

If you sign up now, it will make a strong statement that _this_ list serve is owned by us, not by a company.

Now I'm waiting for them to respond by linking to the user group from their web site. I'm not holding my breath, though.

Make all your Obstacles into Opportunity

2010-08-03T14:38:00.000-07:00

The other day we lost power at work--and realized it was not just our building, but an entire zone of the city. So we took advantage of the time and played a team-building game I had prepared in advance, with no pre-conception of when, or if, we'd be able to use it (thanks to Aurelien for pointing me Tom Wujec's Marshmallow Challenge):

We first did the challenge according to the rules. The tower that Christophe and Julien built empirically, bit-by-bit, won. The over-engineered version didn't reach completion.

Christophe and Julien, Victors!

Couldn't quite finish...

We did a de-brief, but I don't want to write a spoiler. Try the game yourself... the person who reads all the instructions at www.marshmallowchallenge.com will lose out on the experiential learning, but will still have fun.

Then we played a bit more, without time constraints. We all wanted to know a bit more about what was possible with string, spaghetti, and marshmallows. This time the most structurally sound design won:

Franck and Christophe with wobbly sphaghetti

Sylvain and Olivier, Grand Designers

Addiction, Totems, and Giving

2010-07-29T00:59:00.000-07:00

Addiction
This is my technical blog, so I'll try to avoid getting too theological--but when I'm talking about what's closest to my heart, my true passion, it really does border on incoherence, spirituality, and insanity. That's probably as it should be, because it's our creative minds that see what's beyond our current perception of the universe. Without this borderline insanity, how would we be able to change the is to the could be? So please bear with me, and leave comments to help me see where my ramblings aren't clear.

Recently I made the difficult decision to return (with my family) to my home in Philadelphia, after a 2-year adventure working in France. So, I've got big changes ahead--an international move and a new job. It's making me nostalgic, question my values, and reflect on what I've done. An essay by Paul Graham recently triggered even more reflection on my values: he talked about Addiction. It really made me wonder whether I'm addicted to anything. The most likely candidate for me is the internet--but as I read from Wikipedia:

The American Society of Addiction Medicine has this definition for Addiction: Addiction is a primary, chronic disease of brain reward, motivation, memory and related circuitry. Dysfunction in these circuits leads to characteristic biological, psychological, social and spiritual manifestations. This is reflected in the individual pursuing reward and/or relief by substance use and other behaviors. Addiction is characterized by impairment in behavioral control, craving, inability to consistently abstain, and diminished recognition of significant problems with one’s behaviors and interpersonal relationships. Like other chronic diseases, addiction involves cycles of relapse and remission. Without treatment or engagement in recovery activities, addiction is progressive and can result in disability or premature death.

Furthermore, addicts often are in denial--saying they choose, and like, the activity, to the extent that even when something catastrophic happens they still insist they want it--but in reality they have no control. I find this definition problematic, because if clinicians can't diagnose addiction until something bad happens, it doesn't do us a lot of good in preventing these accidents.

Totems

So if addiction is the point at which a person can no longer heal oneself, and as Graham argues, we live in an environment that is getting more and more addictive, we need warning signs that work better than what we had in the past. He says that traditional, cultural, and social means for controlling addictive behavior are insufficient. For me, this is where Totems come in.

A Totem, in pre-historic times, was an animal with a spiritual connection to an individual. When that person was in trouble, the totem often showed up to help. Many cultures have used totems or icons of human form in various ways, leaving traces behind in the form of statues, idols, and carvings in temples, churches, roadways, and homes. Imagine traveling by foot for hours, coming around a corner and seeing a huge statue or relic like this, pictured right. It is inspiring, centering, and powerful. Even today many people use descendants of totems in the form of physical charms, to keep them centered. Take, for example, Jerry Weinberg's consultant's kit--a box full of simple tools to remind him what to do when he has a problem.

As you may have noticed, though, the prevailing use of totems has evolved from the mystical to the symbolic. Consider how in ancient times people considered that the animals would come to us, then there were statues that happened to be along our route, and now there are charms we bring with us or place lovingly at an alter in our homes or places of worship. All are powerful, but there's something especially magical about the kind that show up before we know we need them, instead of when we turn to them. That kind of magic, I believe, is real, and can still be integrated into our lives today. It may be easier to explain this as the subconscious telling us to notice when something isn't right. Or if you're inclined to have fun with the mystical explanation--let me tell you I actually have a totem. I didn't pick it--but sometimes when things are out of balance in my life, I start seeing spiders. It's scary to admit it--I think it's a bit crazy even--but I'll be getting ready for work one morning, and there will be a spider in the shower. Then there will be one at the badge swipe at the front door of my office. Then one will drop down from the ceiling over my desk. Of course it could be chance--but when this happens all in one day--I get a bit freaked out. Don't get me wrong--I love the beauty of spider webs, the way they trap nuisance bugs, the metaphor of web-weaving and the internet--but I am also irrationally scared of spider bites. Or maybe I could say I have a healthy respect for spiders. This makes them a great totem for me. Maybe there's nothing supernatural going on here--maybe a neurologist could explain these sightings as a desperate attempt of my subconscious mind to be creative when I'm overly focussed on a project--and maybe that is why I notice spiders more when my life is out of balance.

Regardless of any logical, mystical, or even insane explanation of totems--when I see spiders, it's a wake-up call. Maybe I forget most sightings, because nothing in particular is going wrong. Yet when I'm starting to head into potentially addictive territory, and a spider crosses my path, it helps me get back in balance. So in response to Graham's search for early warning signs of addiction, I think we need to capitalize on totems. At my office in Philly, I put a big 5-foot round Halloween spider web in the window; in my garage I keep a web-shaped wind chime. Whenever I see a web or a spider, I step around it in respect for the work it's done--and I also ask myself if I'm in balance. So I have to admit that I like a combined approach--a belief in the kinds of totems that come to me, and the integration of physical charms into my daily environment.

Giving
Another kind of totem that works for me is mantra:

Give 'til it hurts.
Anything with value is hard to do.
Too much of anything is a bad thing.

OK, so why am I writing about Addiction, Totems, and Giving on my technical blog? It's because this blog is part of my internet life--a part of my life where I wonder if I'm addicted. I think all the nights and weekends I spend reading/writing/e-mailing could cause a catastrophe some day. I try to stay in balance by running regularly, spending time with my family, volunteering for the Agile Community (e.g. Agile Tour, Agile Philly, and other projects), and coaching/managing software development teams--but it's hard to stay in balance. Something always suffers. Yet if I look back at the mantras above, it's OK that it's not perfectly balanced--because too much balance is a bad thing.

This blog is part of the way I try to give until it hurts. I try to find something that's on my mind each week to write about--it challenges me to keep reflecting on the work I'm doing, it forces me to have some discipline.

There's something more important about giving though. It's personal, really. One who gives, gets. When I write here, people comment, or e-mail me, or mention it at a conference. People give back to me. They help me see my shortcomings, they center me. They help balance my perspective.

Hmmm. Addiction comes from overuse of one activity or substance. Wake-up calls, in the form of totems or gifts, re-center us, put us in balance.

So go to your local user group meetings. Participate in the online community. Give 'til it hurts. It will help you more than you put into it.

Target Customer Characterization

2010-07-20T08:00:00.000-07:00

Recently I've been interviewing all the sales, pre-sales, and professional services staff in my company to build a profile of our customers and prospects, in order to better focus our development, marketing, and sales efforts. This is the template I made (inspired by Geoffrey Moore's book). I use it to guide my interview process, and try to fill it in under 15 minutes. Lots of times I only use the initial table to get context about the work environment, but can't fill it in; I rarely get to the "after" scenarios, but I'm posting this to get feedback--what would you change in the template?

So far the whole process has been quite illuminating. It takes a while to digest all the information I get, though, so I can't do more than a few clients a day.

Target Customer Characterization

Client Name: Industry: Interviewed:

	Geography	Department	Job Title
User
Technical Buyer
Economic Buyer

Before purchase, a day in the life of (find consequences for economic buyer):

Scene or point of frustration:

Desired outcome:

Attempted approach / Alternative Products / Competition :

Interfering factors:

Economic consequences:

After purchase, a day in the life of:

New approach:

Effectiveness of approach:

Economic benefit:

pull stand-up sessions

2010-07-08T23:49:00.000-07:00

Though I haven't (yet) succeeded at this, I'd really like stand-up sessions to go more efficiently by replacing the standard stand-up and report tradition to a stand-up and ask questions. We'd organize the discussions around the active story cards, addressing each card one by one. Someone who is not working on the selected card will ask--"what's left to move this to the done pile?" followed by any clarifying questions necessary. Answers will be short and to the point. If questioning goes on too long, we'd just take it offline and move to the next card.

What's my motivation? I'm always torn between listening to what people around the circle are saying and trying to summarize my status... and as a result I get less out of the other people's summaries. I learn more by asking questions, by pulling information--and I wonder if other people would too.

Favorite lines from Crossing the Chasm by Geoffrey Moore

2010-07-02T13:02:00.000-07:00

There's a reason this book has been a best-seller--it's full of great insight, it's well-written, accessible, and Moore's arguments are backed up by clear logic. It was initially published in 1991 but I read the revised version, published in 2002. Here are some of the ideas I found most inspiring.

Chrossing the Chasm is all about "marketing and selling disruptive products to mainstream customers". This line, direct from the cover, means so much more to me after reading the book--for example, the fact that growing a business based on a technology product is not soley dependent on the value proposition and execution--but is equally dependent upon the sales channels and relationships we build in a target market. I learned why our salespeople do so much networking, and why my personal network is so valuable.

So let's begin with Moore's first principles; a high-tech market is:

"a set of actual or potential customers, for a given set of products or services, who have a common set of needs or wants, and who reference each other when making a buying decision". So there it is--what we already knew before--that word-of-mouth marketing is the most effective form of marketing. What is new to me, though, is the premise that word-of-mouth marketing is effectively the ONLY way to reach the mainstream market. We may reach our first clients (innovators and early adopters) directly, but to fuel sustained growth, to cross the chasm, we need to become the referent solution in a market segment - that is, word-of-mouth should mention our product any time the problem comes up. How do we ensure this? Attack a very focused market segment--and become the market leader. Yet crossing the chasm is dangerous for a company, too, because mainstream customers will not pay the margins that early adopters will--and so we cannot offer them the same level of service or customizations. The innovative developers and visionary sales staff of a pre-chasm organization are not the same kinds of people that are required for managing a post-chasm business--the post-chasm folk are experts at fitting the existing product into a customer's environment without tailoring--and the post-chasm developers are making the product easier and easier to support / use. This brings up a good point about how to reward founders (pioneers) and settlers. Pioneers should be paid highly for initial conquest/development work, and then they're likely to move on to new challenges; settlers should be given equity and share in the long-term growth of the company. Often compensation models are quite the opposite.

Moore breaks down market adoption into the following phases: innovators (technophiles), early adopters (visionaries), early majority (pragmatists), late majority (conservatives), and laggards (skeptics). Many companies get stuck after finding their first innovators, or get stuck after their early adopters... but there's a chasm between each phase. He says many companies fail to leverage the conservative market--but because it's so large, it can be a great source of profit for technology that is no longer under active development. Conservatives want COTS (commercial off the shelf software)--everything in a box. This brings up another important concept--the whole product. In crossing the chasm, the innovators must discover the full suite of services, features, and support required for successful implementation of the product, and add that to the product during the early adopter and early majority phases (since late majority users won't pay for support). Also of note--Moore considers himself a late majority adopter. To help pull them along, without hurting sales for the early majority, we need to provide easy upgrade paths and continued support of old products--thereby showing a commitment to the stability expected by conservatives.

"The consequences of being sales-driven during the chasm period are, to put it simply, fatal". The chasm period isn't about sales--it is about conquest. To cross the chasm, we need word of mouth references--we need buzz--we need everyone to be thinking about us in a particular market segment. The smaller it is, the easier it is to conquer. So sales outside of that segment are distractions that hinder our market penetration. It's fine to do another segment later--and successful conquest of several segments in a row will generate its own buzz--but stay focused! Mainstream market customers like easy buying decisions--and if you're the referent solution, they're happy, and willing to pay a small premium (30 percent) for the best of breed solution. Be the big fish in a small pond, over and over and over.

How do we pick the right market segment? Find one that you already have contacts in (you have their confidence), and go for the prospect with the most pain--something you can really help them with. If you have no strong contacts, grow some, and fix someone's pain with your product. Take note that crossing the chasm with an identifiable product is much easier than a product platform--e.g., smartcard-enabled credit card payments, since platforms need to be deployed ubiquitously before they're of much value. For more help in identifying segments or in categorizing clients, Moore uses a customer profiling technique he calls "scenarios". This profile is detailed starting on page 95 of the book, but captures elements like the point of frustration, the user, technical buyer, and economic buyer, the customer's goal, the current approach, the problems, and the economic consequences. Often you won't have enough knowledge to fill everything in--but "informed intuition" is OK too. The objective of mapping out user scenarios is to be able to target one, build it, and sell it. The targeting process will include a round-table discussion (with field reps) to rate each scenario against the following: "target customer, compelling reason to buy, whole product, partners and allies, distribution, pricing, competition, positioning, next target customer". With a compelling reason to buy, we can drive sales in shorter than 3-month cycles, and saturate the market in a year. With a market alternative, or product alternative, the customer can look at the existing budget for the product, and knows what it's worth--otherwise we have to wait for them to maybe budget for us next year. If you can't identify a market alternative, you may need a product analog--a methaphor that explains in a pithy phrase what this product is. Oh, and if you "have trouble finding a single, clear, market alternative" to attack and replace, then you won't be able to cross the chasm--people won't have a budget for you.

Product positioning is the pinnacle of marketing--but it's also tricky. People hold an image of a product in their minds--and don't like anyone else to manipulate that. So instead of trying to define it, find ways to make the product easier to buy. "Think about it. Most people resist selling but enjoy buying". Positioning is the attempt to get people to decide "best buy for this type of situation". Make sure your pitch passes the elevator test--because it has to be spread by word of mouth, and without this sort of focus, the development team will be fraught with too much complexity, marketing messages will be wildly different from one another, and potential partners/allies/investors will shy away since they do not know what you stand for.

Geoffrey Moore also talks about sales channels. We may use direct sales, systems integrators, retail sales, value-added resellers, or the internet. Of these, he prefers direct sales for an early stage startup because we need to provide a lot of hand holding to get customers off the ground, with a gradual transition to a less resource-intensive sales approach as we approach a mainstream market. Although integrators and resellers may reach a larger audience than we can alone, they who are in contact with the paying customer get the main profit.

The hockey stick sales growth of crossing the chasm is largely a myth. Moore says most sales patterns are like staircases. We discover and conquer a market, step up, and are stagnant again for a while while we invest in another market. He says some "vulture capitalists" take advantage of these stagnant periods to strip founders of their equity in the company.

These are just some of my favorite lines from the book--if you're part of a startup, I highly recommend reading the whole thing yourself!

XP 2010 physically agile makes us lean

2010-07-02T05:50:00.000-07:00

This is my last post on XP 2010. I decided to host a "pre-conference session" every day--by going on a morning run--and a few people signed up for it on the LinkedIn group. It got harder and harder to get out the door at 6am every day, but I had a great time so it was worth it--and Xiaofeng Wang came along every day. We runners took a different path each time, and did about 45 minutes on the road at a conversational pace. It was great to do session re-caps and get a chance to get some exercise, too--I find it helps me focus for the rest of the day. Here's a couple shots from our last run:

XP 2010 Session Report -- Speak Like a Native by Yours Truly co-starring Deborah Hartmann Preuss

2010-07-01T03:40:00.000-07:00

This workshop gave people the chance to work, in teams, on a real-life design problem with a customer who doesn't "talk tech". Thanks to Deborah Hartmann Preuss for helping me run this installment--we each played the role of an annoying customer. We ran two iterations of paper-based design through acceptance testing, followed by a de-brief to share what works and what doesn't.

In this second installment of Speak Like a Native, we had a much smaller audience than I've worked with in the past... but everyone seemed to get something out of it and we decided the low turnout was actually a marketing problem. We decided it would be better to call this session "dealing with annoying customers", and to discard the Speak Like a Native analogy--it doesn't really add much to the session. We generated some great ideas for improving other session mechanics--a big visible timer, timebox warnings, and an overview of all envisioned system requirements before working on the first release. We also confirmed my previous findings--that building a toolbelt is not an important part of this workshop--but talking about tools as part of the first debrief is useful. Here are the slides we used: Speak like a Native.

XP 2010 Open Spaces -- Agile Welcoming Circle

2010-06-14T07:32:00.000-07:00

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

2010-06-14T07:25:00.000-07:00

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

2010-06-14T07:06:00.000-07:00

(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

2010-06-13T06:42:00.000-07:00

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?

2010-06-09T23:12:00.000-07:00

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

2010-06-09T22:58:00.000-07:00

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

2010-06-09T22:56:00.001-07:00

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

2010-06-05T02:57:00.000-07:00

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

2010-06-02T01:10:00.000-07:00

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.

conference season

2010-05-27T04:15:00.000-07:00

It's the season to learn, get energized, and inspired by other conference attendees... Over the next 3 weeks I'll be giving talks in Paris, Trondheim, and Munich (luckily they're all in the same time zone):

May 31: Agile France, Speak Like a Native

June 1-4: XP 2010, Speak Like a Native and How do I Measure Up?

June 17: TAV 30, Testing before development is done: Agile thanks to MBT

Besides doing talks, I'm also helping ramp up this year's version of the Agile Tour. We recently sent a call to nominate cities for the 2010 edition, and we're having twice-weekly conference calls for the board. We have over 40 candidate cities so far! It's a conference that has enjoyed exponential growth--starting in 2008 in France only, we've marketed it across international borders (and yours truly did the English-speaking marketing), resulting in 6 new countries last year (3 of which came through the English-speaking channels), and even more this year.

Stay tuned for blogs about the cutting-edge developments announced at next week's conferences...

favorite lines from More Secrets of Consulting by Gerald Weinberg

2010-05-20T04:05:00.000-07:00

Sometimes I wonder whether these kinds of posts annoy my readers or not--but since this blog is equally for the author as for readers, I opt to include it. I like to attribute ideas to their sources whenever possible, and every once in a while I want to look things up that I've forgotten. I often can do a keyword search on this blog, and turn up the title of the book and even a bit more context--it may be enough to jar my memory, or from this I can more readily locate the correct section in the book itself, since I've dog-eared and underlined the same things I mention here.

First off, I have to say that I find Weinberg's Secrets of Consulting books thought-provoking yet too informal. He's a story teller, and gives crazy names to all his secrets--this is probably one of his undocumented secrets, in fact, since names like the "law of raspberry jam" have left a visual image in my brain that quickly brings up his lesson. I like easy to read books, but I like them to be more direct. On the other hand, if it weren't for all these stories, it's possible I'd learn less from what he wrote.

This second book builds upon the memory tricks by recommending we build a "consultant's kit" that includes over a dozen physical objects that will help us remember what to do when we have a problem:

the golden key: we have the power to unlock more doors for us than anyone else / "when you stop learning, it's time to move on" / "there are many ways to put people to sleep with words" so sometimes the best thing to do is stop talking, or listen beyond lullaby words / you've never tried X, or don't know anything about X "up until now"
the courage stick: when we're afraid, find something we're even more afraid of to get us moving / "the key moment in a relationship occurs when one or both [people] feel there's something that can't be talked about" and then he pictures what happened to people that didn't talk about the taboo subject / "whatever the client is doing, advise something else" / Loftus' Law: "some people manage by the book, even though they don't know who wrote the book or even which book it is"
the wishing wand: it's best to let people around us know exactly what we want, because then there's a chance they can give it to us; don't filter--leave that for negotiations later
the detective hat / magnifying glass: we need to see the data ourselves, not just the conclusions our customers have made / don't be mesmerized by the first problem you find / the closer you get to the culprit, the less likely you are to get the answer / use their questions as information
the yes/no medallion: it's important to be able to say no if it's not a good deal for you / sometimes we can say no by thanking people for their invitation, then saying it's not the right fit at this time
the heart: "if someone requires you to die trying to help them, you don't want to help them" / if you get involved in projects that require your mercy to succeed, they're not likely to succeed anyway
the mirror: why am I here? / how do I feel about that? / what do I want to happen? / feedback is a reminder, not a reproach (everyone is always trying to be helpful)
the telescope: zooms in on how other people are doing / center yourself; empathize; pivot
the fish-eye lens: look at the context / "the fish is always the last to see the water" / listen to the music, rather than the client's words
the gyroscope: "if you want to stay single, look for the perfect mate" / you can't be perfectly rational, congruent, or consistent! / trust your body, then your brain / "a professional is someone who does a good job even when he doesn't feel like it"--but excellence only comes when we're really on / Qualified-but-Quiet Quandry: the more you ask for help, the less you'll get stuck--but it's hard to ask for help when people think you're the expert!
the egg: we can always grow & try new things
the carabiner: find ways to make safe experiments, where failure is OK, and even expected as a sign of creativity and growth
the feather: keep it light! being too serious inhibits our creativity. play! don't make such a big deal of things, because in the grand scheme of things, the universe doesn't really change
the hourglass: why do we never have the time to do it right, but enough time to do it over?
the oxygen mask: competence can lead to burnout / this is about breathing and vitality--energy--a balanced and energetic life

fan of Jurgen Apelo

2010-05-11T09:29:00.000-07:00

Since Jurgen Apelo invited agilists to contribute to his new Management 3.0 blog, I decided I'd support his project by writing something myself. I called the article Estimation Causes Waste, Slack Creates Value. I'm a big fan of Jurgen's blogging, and look forward to his upcoming book.

on the job market

2010-05-04T09:48:00.000-07:00

Do you know anyone looking for a director-level software development manager? I'm on the market, aiming to find a position for September in Philadelphia or the region.

I'm looking to be a manager of software development, preferably at the director-level, responsible for a team of maybe 3-5 intermediate managers. What I'd like to do at my next position is build long-lived teams who get to know the business well and can pivot the product line towards ever-increasing opportunity and profit. I'd be happy to work for a business that has demonstrated profitability or for a lean startup. I know the difference between leadership and management, and have done both.

I used to be driven by software and technology hurdles, but over the years I've refocused on people issues--moving from managing small teams to coaching, and even trying out product ownership. For more information, browse my blog archives, my achievements, see my resume or recommendations. Please note that for my most recent position, I've been working in a French-speaking environment, and so I asked for reviews in French. If you want a translation, you can ask me or use Google translate.

Conference Talk on Focus and the Pomodoro Technique

2010-04-29T04:47:00.000-07:00

A colleague and I (thanks, Olivier!) presented the following talk on the Pomodoro Technique. Attendees were intrigued by the content, but the exercises needed some work. Olivier presented it again later in the month and it went much better... our experiments with small focus groups didn't scale out well to 10-15 people per team. The second time around, he increased pressure and scope creep by doing the following.

5-minute challenge: brainstorm as many tips as possible across all categories below. Make sure you get about the same number of words in each category. One person holds a dry-erase marker and notes ideas; no duplication allowed within lists.

fire prevention
road/driving safety
professional hazards

5-minute debrief: count how many ideas were generated for each category. Ask how things went, and what was noteworthy.

5-minute challenge: same as challenge above, except we work one category at a time until there are about 20 ideas, then move to the next category.

flu-prevention
household child safety
names of TV shows

5-minute debrief: was one strategy more effective than the other?

10-minutes: Introduction to the pomodoro technique.

15-minutes: how we tailor the technique to a team environment and meetings, Q&A

the cost of team-building

2010-04-29T04:31:00.000-07:00

Part of what makes team-building so hard is its cost. There are personal costs, political costs, and organizational costs--plus the cost of time. Yet people who've been on a performing team often want to get back on one, and managers are often hoping to create them. I think that listing some of the costs may help us understand the resistance to team-building / gelling:

cost	benefit
loss of independence	we accomplish more than we'd do alone
increased visibility of mistakes	our team is there to help us when we fall
increased visibility of weaknesses	" " "
with more trust in teammates comes more vulnerability that they'll let you down	more connection and support
full presence requires more energy	we relish more in our success
decreased recognition from management for individual contributions	much more constructive feedback and learning opportunities from peers
organizations lose some control when a group has gelled--a self-organizing team does what it chooses, rather than always doing what the organization has requested	unprecedented levels of productivity and value

polyglot list serves

2010-04-26T12:15:00.000-07:00

On the Agile Tour organizer's list this year we adopted a list serve culture I haven't seen elsewhere--members are invited to type in their native tongue, and liaisons (like me) translate the text to English. Everyone has decent reading comprehension of English, but may find it hard to write in it. This makes participation in the list easier for almost everyone... Have you participated in a list like this? What kinds of language- or process-related problems have you encountered?

fan-out release planning

2010-04-12T23:57:00.000-07:00

What is Fan-out Release Planning?

Fan-out release planning integrates set-based design, weekly intermediate deliverables (and validated learning), sustainable pace, top-down budgeting, risk management, and deliberate prioritization to deliver a valuable product in sync with business, marketing, and sales plans. We do this from a Product Owner's perspective by selecting epics for the release, establishing a budget for each topic based on the business value, reality-checking the expectations with the development team (and trimming scope as necessary), and then scheduling the work strictly in order of priority, stopping development when we've run out of time.

The differences between fan-out planning and traditional XP planning are:

an emphasis on exploration, especially during the beginning of an iteration/release
top-down scheduling
an explicit allowance for functional debt until the end of the release. (Functional debt, for example, is present in a new file editor that allows us to create and save documents, but not yet load them. We could address creating and saving first because the team identified these functions as the most risky, and identified a fail-safe plan of using a plain-text editor to display the files if we don't get a chance to work on loading/rendering issues. This gives us more time to focus on the core value provided by our editor, for example, auto-completion.)
an emphasis on slack time, both creative and buffer slack

We use fan-out planning at an iteration level for cards that we can't readily estimate (because the solution or need is vague). Instead of doing pre-work on a card in an iteration before a story has been slated, we'll schedule it without an estimate, and let the team say what is feasible during the week. What does this do to a week's commitment? It makes it more fluid--people do the work that they can. The goal is to find the essence--the core value of a card--and do something that will yield feedback (validated learning). Normally an un-estimated card only produces a spike or more cards with estimates, but if the developers who took it find the work easy and relatively small (less than a day), they'll often move it to Done-Done. In any case, we have something to show for the work, that can be validated with a client, and we've left the production code in a healthy state (often by using options that hide new features).

Why Change the Planning Game?

Traditional XP release planning leaves little room for slack, and as a result, I think it doesn't get as creative. We also see cycle-time waste when we're doing analysis for story cards that aren't going to be picked for an iteration or more. So instead of nailing things down enough for estimation, we just 'take it offline' and talk when the card has been picked. This can be risky, because bottom-up scheduling and estimation protect a team's sustainable pace. We counter-balance this risk with adequate slack.

Another benefit of fan-out planning, counter-intuitive as it may be, is the increased predictability it gives us. It may be a bit premature to say it, but we've been doing fan-out planning for about 15 iterations, including one major release, and we find we are more capable of responding to changes in the market place, more capable of finishing strategic plans, and more predictable. By always focusing on the absolute minimal feature set, we gave ourselves enough slack to become predictable.

When we're beginning a new release, we need to provide some visibility to our marketing, sales, and support teams about what's coming with the next version of the product (we make internal releases each one-week iteration, and sometimes deploy those intermediate deliverables to a new client, but most existing clients only upgrade our product every 3-12 months). There's a lot of risk involved in promising a fixed scope with a fixed delivery date--so instead we commit to a delivery date and a vague set of release goals/epics/themes. By using fan-out planning, we attack several candidate solutions, show them to our stakeholders, and wait until later in the release plan to commit to a particular solution.

Does this sound familiar?

Fan-out release planning is, as far as I know, unique to my team (but inspired by XP, Scrum, and Lean ideas)--and I'd be happy to hear about other teams that are doing something similar, or about any resources/books that describe it, or of any concerns you might have about the process!

favorite lines from Slack by Tom DeMarco

2010-04-12T07:55:00.000-07:00

DeMarco's book is not only about Slack--but if you want to read about it see:

Slack: We're not slacking off!

When to slack + what it gives us

Pressure

"People under time pressure don't think faster"--Tim Lister

DeMarco discusses at length the popular management idea that people under pressure work harder. Sorry--pressure only helps for physical labor. So what are managers supposed to do if they're not turning the screws? They're supposed to protect the focus in the work environment; to build relationships between individuals; to delegate and keep hands out of the "dirty work"; and to fight against aggressive schedules, overtime, a culture of fear, and litigation. Managers are avoid command-and-control behavior, and need to learn to lead by extending trust before it is earned: "you acquire trust by giving trust".

Change

There is no managing of change. No one knows what's going to happen. As Weinberg says, he goes in, shakes things up a little, and waits for concerned employees to come asking for his opinion. DeMarco adds: "in times of change, the reward has to come first". It's hard to change--it can be embarrassing for an expert to learn a new skill and be reduced to the same level as junior colleagues. Anyone who is learning, trying things out, taking risks, is likely to be afraid--but if they're not in a safe environment--they may get ridiculed--and that can kill their motivation to change. Furthermore, change has to be introduced when things are going smoothly! If things aren't going smoothly, and you still need to change--add a lot of slack.

Best Practices

DeMarco says that a focus on process comes from Taylorist thinking. From an observer's perspective, the physical process followed by stellar employees may be the same as the average employee--but that's because knowledge work depends on relationships or abstractions, not physical steps.

It's more important to be effective than efficient; that is, do the right things, before working on doing them the right way. As soon as we streamline our process, it becomes inflexible.

Managing

This couldn't be more simply put: "the skills [of management] are inherently difficult to master". Often managers are promoted from technical disciplines without proper training. This produces all kinds of common side effects... for example, the stereotypical weekly status meeting. These meetings may be nothing other than an opportunity for the 'boss' to demonstrate some sort of control over the project. What a manager needs to learn is to extend trust in a qualified context--and to give people the chance to fail. Ultimately this gives people the chance to learn and improve. Instead of second-guessing all the small decisions, the 'boss' can focus on the big picture with risk management. Appropriate risk management means we've planned for many failures along the way to ultimate success.

He Came to Bury Agile: Long Live Agile

2010-04-12T00:55:00.000-07:00

It's Time for Agile 200x to Cede to the Smaller Conferences

Last year's keynote speech by Alistair Cockburn at the annual Agile Alliance conference was called "I Come to Bury Agile, Not to Praise It". I too am here to bury the Agile so many of us know, the Agile paid for by hollow certifications and expensive conferences and phony marketing. I'd argue that the term "Agile" itself was a phrase coined for marketing purposes--but that's another story(*). This story is about how we need to reach out in support of the whole community, rather than spending our attention/resources on a select few. What do I mean by a select few? Well, there are over 50k CSMs, and only around 2k attendees at the Agile Alliance conference every year. That's 4% of CSMs (and less if you count the rest of the Agile community). Less than 4% is a select few. Why don't more people go? I'm not sure--but for most of the colleagues I've worked with, it's simple--they can't afford to "pay to play". Me neither--if I pay early-bird rates, get super-cheap airline tickets, pay for my hotel and food, this sums to a month's-worth of my take-home pay (I'm working for European wages). A full month. What about corporate expense accounts? Not for this--all my colleagues and I have worked for small companies that can't afford it either. It's time to find an affordable way for the typical developer to participate in Agile conferences.... and that's through small, free/low-cost, local conferences, like the XP Day series, the Simple Design and Test Conference, Bar Camp, Agile Tour, etc.

Where I'm Coming From

Throughout my 10 years of agile software development, I've been getting more and more into the Agile community. I love this community because it is so open-minded, so willing to apply ideas from other arenas, and so ready to share knowledge without claiming intellectual property rights. We've built strong local user groups, e-mail lists, open space conferences, code camps, and have given legitimacy to the idea of sustainable pace--all without spending much money out-of-pocket. This is the Agile I know.

Yet, there's a part of the community I don't know, a part maybe I don't even want to know: the big, expensive conferences and training classes. It seems like all my role models are a part of this, so I figure it's worth trying, at least. Yet, how do I pay for it? This year I was happy to discover that the Agile Alliance offers speaker compensation packages that cover registration fees, hotel, and a stipend big enough to cover food and taxi from the airport, leaving only the international flight for me to cover myself. I thought this was a comparably affordable way for me to go to a conference. So I decide to prepare a submission. A couple years ago one of my role models, Yves Hanoulle, said he only goes to sessions that are prepared by a pair of presenters. OK, so I find a co-presenter. It's bound to make my submission better. So I begin the submission process, and find out right away that the speaker compensation policies for Agile 2010 and XP 2010 only reward the 'first speaker'. What? Aren't we, in Agile, supposed to believe in rewarding the team, not individuals? Well, I promised my co-presenter that I'd split the booty equally. Hmmm... now I'm down a couple hotel nights, stipend money, and worst of all, half of the conference registration fee. Well, I can fix that--I'll do two talks. I find another topic, another co-presenter, and away we go. Time goes on, a few people make good recommendations, we improve our proposals. I start reviewing other people's sessions, and see a lot of good ones. I'm not feeling all that confident, having never been to a big conference before, so I do one more submission. It's so much work to write a submission, I decide I may as well post it for several conferences... and soon get accepted for XP 2010 and Agile France. Woo-hoo! Maybe people do think I have something interesting to say....

With all my submissions made, I start appreciating the peer-review functionality of the Agile 2010 system. I start reading and commenting on other people's submissions--and find that this system is the best I've ever participated in. Here's the real Agile community I was looking for--people collaborating, seeking the best in others, and supporting one another. I ended up leaving comments on 130 proposals--hoping to give back what I had gotten so far from the process. I know stage producers had to do a lot more, but I think I can appreciate what they have done during the selection process. Ultimately, none of my talks were picked for this year at Agile 2010. Still, I noticed that the submissions from people that had established reputations in the field got 5 times as many comments as newcomers. I really wondered how people that hadn't participated much in the community would get mentored if they weren't getting equal support through the comment system. As a result, I think the review process needs to go double-blind.

The Revolution is Afoot

Maybe the rejection from Agile 2010 is clouding my judgement right now. Or maybe it's making it so I see more clearly. I did get in to other conferences, and all along I've been frustrated with the costs of doing a presentation. In any case, this big up-front selection process, in which a few volunteers meet to judge which talks are best suited for the conference, is simply not Agile. It's too cold, it's too Taylorist, it's too micro-optimized. It's not consistent with the relational vision of the Agile Community. There are already several disruptive changes in our midst that will outreach this top-down model of a conference. One, for example, is the Agile Tour, which had more conference attendees last year than the Agile 2009 event, and which cost an order of magnitude less. It gave a stage to practically anyone who wanted to talk, and attendees voted with their feet, during the day, to show what was most valuable to them. Another sea change is the growth of groups like the Agile Skills Project, which has reached over 800 members in less than a year, and the Diversity In Agile Project, which shows that we are recognizing the problems that come from undervaluing the full community.

The Agile 200x series of conferences has struggled for years with their selection process. Why not give up, and go with the Agile Tour model? Keep the peer reviews, keep collaborative improvement of session proposals, and get rid of the high-cost of flying everyone in the world to one city. Send invited keynote speakers on a short tour, and let everyone else in the door for free. Corporations can sponsor the venue and food, and the events could happen twice or more per year.

(*) Note the company names of the best-known consultants in the field--do they have 'agile' in the title? No! Because the word Agile is a marketing gimmick.

When To Slack + What it Gives Us

2010-04-09T04:50:00.001-07:00

This is the second in a series of posts, beginning with Slack--we're Not Slacking Off!

We need slack in order to be creative, to maintain a sustainable pace, and to improve. So when should we slack? To answer this, we need to understand the costs and benefits of slack.

What is its cost?

Zero. Apparently, on Ilja Preuss' team, they schedule a full day of slack once per month, and they see no drop in velocity for that week. Our team aims for a full day per week of slack, and I'd say we get an increase in velocity for that. Based on this statistically insignificant sample size, I have to say that slack is free or value-producing. So last week in retrospective we decided to call slack our default activity and label card work a side-job. We said this was to emphasize the "research" part of our R&D group, to make sure everyone knows they're supposed to be coming up with innovative, even disruptive, ideas. I admit the idea of full-time slack is a bit extreme, so let's keep holding on to the one-day-per-week goal, 50% of the time.

What are the benefits of slack?

Beck, in XP Explained 2nd ed, talks about slack as a way of making sure we meet our commitments--it is about transparency and building trust.
Slack gives the Product Owners perspective on the health of the code and of innovation. If all developers do during slack time is refactor, we can ask if they're taking on too much work (and creating technical debt). If they're tweaking functionality they worked in the past, we may need to look at functional debt. If they're creating entirely new prototypes, then we only need to monitor the feedback cycle on these ideas to be sure the value is qualified before much is invested. Near the end of the iteration when I see people hovering around the story wall looking for something useful to do, I know they're not overworked--and when I see them starting prototypes, I know the iteration buffer is big enough.
When the team reaches slack before the end of an iteration, they can share in success together--maybe they were lucky, or maybe they worked together well, but in either case, it's a success. The value is two-fold: the iteration work is Done-Done (and hopefully deployed and generating business value), and the team bonds are stronger.
DeMarco says slack is a way to give employees control. Dan Pink talks about why control is important--motivation comes from autonomy, purpose, and mastery. So giving employees control is a way to keep them happy, motivated, and productive.
Retaining our employees, as the Toyoda family and DeMarco have noted, is the most significant means of avoiding huge drops in productivity.
DeMarco talks about being too busy, the myth of total efficiency, the impact that no slack has on change... we are not cogs in a machine, we can't be interchanged and we can't task switch without penalty. If we don't invest in slack, we will end up being overly bureaucratic, rigid, and conservative.

So when should we slack?

Whenever there are no more cards to work on
Towards the middle of the week (because people are tired Friday and Monday)
When the whole team agrees there is no useful/effective/efficient way to divide up the remaining work any further. If some people are in slack while the rest of the team is pulling in the iteration, it can deteriorate team spirit.

One team I worked with ended iterations Tuesday night--it gave a beautiful cadence to an iteration... we finished Tuesday, slacked Wednesday + had a planning game Wed afternoon, started the iteration Thursday & Friday; by Monday we came in and asked "are we at least half way through? ", then hustled our way to the end of Tuesday again. It was nice to have a weekend break in the midst of an iteration--the distance from the work gave us new insights.

Slack: we’re not slacking off!

2010-04-01T14:20:00.001-07:00

In a technical climbing technique known as lead climbing, a rock climber, the lead, takes a calculated risk by climbing above any anchors, in order to climb higher. This kind of climbing requires precise coordination between the lead and the second, for without slack, the lead cannot advance at all; with too much slack, a fall is more dangerous; and with too little slack the lead can be thrown off balance and fall. (Photo Credit)

Note that it is physically impossible to climb without slack. When it comes to software, however, I’ve too often become obsessed with productivity, moving cards, increasing velocity, process improvement, and delivering business value, to the point I optimized out all slack. It’s not that I’m the only one to get lured by the “myth of total efficiency”—it is a common problem in agile and non-agile environments. Slack is covered authoritatively in Tom DeMarco’s Slack, included in the core XP Practices in Beck’s Extreme Programming Explained, 2nd edition, institutionalized by the Pomodoro Technique, and championed by Deming and the lean school of thought using pull scheduling. Yet on a recent discussion on the Extreme Programming yahoo list, I got the impression that my understanding of slack is a bit unique.

Buffer Slack and Creative Slack

Back to rock climbing—a good second will always give the lead at least some slack until the lead starts descending—triggered either by a fall or the lead calling “belay!”. There are two kinds of slack on the cliff—the constant foot or so of buffer slack that allows the lead to move freely in the same spot. The second kind of slack is the excess rope that the second liberates only when the lead is climbing higher. This creative slack is given when the lead requests it explicitly, by yelling “slack!”. This call signals that the second must stay vigilant, because it means the lead’s life now depends on correct belaying.

Just as in rock climbing, I see two kinds of slack for a software team. The first is buffer slack—it is the down time between official work, be that work related to story cards, administration, or meetings. It is work that happens when we’re waiting on someone else or we’re not yet ready to take on new work. Buffer slack is what gives us time to reflect and to consider the larger context of what we’re working on. We might fix a bug, or refactor some code that was out of scope of our last story, but that we just happened to notice. It doesn’t require communication with the team because it won’t impact them or the goal of the iteration.

Creative slack is analogous to climbing higher on the rock face—it requires a bit of forethought, a consideration of the feasibility and impact of the next few moves. Creative slack requires a significant investment and focus before one can start advancing. It allows us to improve our current technology, to build prototypes of potential new features, and to consider strategic moves for the product. I’m not giving license here for YAGNI or BDUF. It’s just that we can’t make significant gains without some forethought. Creative slack happens when the team explicitly schedules it; on my current team it’s the time between iterations, and it is typically 15% of our work week.

It’s funny that I didn’t discover the second kind of slack in the software realm until I came to France. Buffer slack happens naturally, unless we over-optimize our process. So when I intentionally left some room for it on my team in Philly, I thought I had slack—and I did—buffer slack. Yet our retrospectives in Philly identified a problem—a lack of innovation—that we weren’t sure how to fix. Our product owner insisted that any time he heard a good idea, he wrote it up on a card and scheduled work on it when he saw fit, so he denied that innovation was suffering. What I didn’t realize is that we needed to schedule creative slack for the whole team. When I joined my team in France, with the standard 7-weeks vacation, 35-hour work week, 2-hour long lunch breaks, there was a lot more natural buffer slack. So when we started nailing iterations early, all the buffer activities were already done. I noticed that the end-of-iteration slack was creative in ways that simply was not possible in buffer slack. It was a new kind of slack: creative slack. I’m not the only one to have learned about Slack from the French culture of working to live instead of living to work. Though he is a native Pennsylvanian, DeMarco studied here in France, at the University of Paris. Maybe that’s why he knows so much about slack.

Note: Though important for recharging, non-work activity (returning a personal phone call, lunch break, evenings and weekends), is not slack in my opinion. Slack is not the same as slacking off.

The Published Discourse on Slack

One of the main reasons I was attracted to Extreme Programming, when I first read about it in 1999, was the idea that we can do good work without overtime. In Beck’s Extreme Programming Explained, 2nd ed., he explains that slack is about building trust—about keeping our iteration commitments. This is obviously buffer slack. James Shore builds upon the buffer concept by saying that it's the variability in problems that determine how much slack we need. In the Pomodoro technique, we learn to pause every 25 minutes. Why? Partly to make sure we're doing what's important. In my opinion, this is buffer slack too—it is still focused on the tasks at hand, rather than uncharted territory.

Though not specifically labeled creative slack, DeMarco’s work touches upon the idea, by identifying that if you don't have slack, you can't take risk, because there's no room for recovery from failure. He also says that the more optimized you are, the less slack you have, and the less you're able to change. Both risk-taking and change are likely to lead us into new territory, and is therefore, what I’d call, creative slack.

Unanswered Questions

I have a lot of questions about what to do with creative slack. Apparently Google requires that employees demonstrate a proof of concept before they are allowed to invest significant amounts of slack time in a project. My team is not doing that—all our creative slack is purely free and unmanaged. This doesn’t seem quite right to me because some of those projects have no value to me as a Product Owner—but I do not interfere because I think the energy these projects generate gives enough of a velocity boost that it’s justifiable. I also don’t want to kill good ideas that I just don’t understand yet.

What do you think about the following?

Can you manage slack (like Google does, without diminishing the energy generation of slack)?
Can you suggest items for exploration (without impacting the restorative power of autonomy)?
Should slack be unconditional?
Should it be a reward?
Does discussion forum/tech news/book reading/technical exploration count as buffer slack or creative slack? Or is self-improvement slack a category that should be explained here?
How do we balance individual needs for slack with team needs?
Is creative slack part of your job?

Agile Besançon--March

2010-03-09T21:16:00.001-08:00

This month at our Agile Besançon meeting (meeting announcements at http://groups.yahoo.com/group/software_dev_in_free-county/), we did a Cowboy Coding Contest. Six people came, which is definitelyenough to have fun, and we set up one laptop with a projector so everyone could see what Ludovic and I were up to. Initially we thought we’d do multiple attempts at the same algorithm (implementing a Decimal to Roman Numerals converter), but we wanted something new for the second try, so we did a binary search instead. We spent just over 30 minutes for each programming task, followed by a review of our approach. Anyone who wanted could share their code, their algorithm, or speak more generally if preferred. Since people were allowed to code in any language, we ended up seeing implementations in Java, Python, and C++! I would have gone faster if I’d picked Java, but I don’t want to lose everything I know about Python, so I practice it when I get a chance…

As usual, we ended our meeting with a quick feedback cycle… people enjoyed coming out to do code, but thought the algorithms could have been laid out more clearly (bduf?). They also thought algorithm implementation isn’t good practice for object-oriented programming.

Point Synchro with a timebox

2010-03-04T04:12:00.000-08:00

Some of our synch points have been too long recently, so we decided to timebox them. When the music plays, we meet around the story board and start a 5-minute timer. We look at the story board, focused on what it will take to move the stories along--and whoever is closest to the board asks people questions, using the stories as the focal point, instead of going around the circle to give everyone a chance to speak. At noon the meeting is slightly longer, because we make sure everyone has a chance to speak--but the rest of the time the objective is just to find out who should be talking to who.

favorite lines from Peopleware

2010-03-02T04:23:00.000-08:00

Peopleware, Productive Projects and Teams, by Tom DeMarco and Timothy Lister, is a classic software project management book for good reason. They discuss problems that have existed for a long, long time, and are not going away any time soon--the High-Tech illusion: "the major problems of our work are not so much technological as sociological in nature".

Counter-productive Managers
Much of the management culture that has been exercised for millennia is simply counter-productive:

Rather than scolding employees for making mistakes, pro-actively ask them "what dead-end roads they've been down" recently. If none, then they're not being creative enough, not taking enough risks, and not going to provide the value we expect of them.
On average, they claim that salaried workers spend only 5% of their time on "planning, investigating new methods, training, reading books, estimating, budgeting, scheduling, and allocating personnel". Without a curious/reflective attitude, how will the workers improve?
There's no such thing as overtime. "The best workers have been through it all before... they take their compensatory undertime when they can, and end up putting in forty real hours of work each week". Instead, managers need to identify workaholics, and encourage them to pay attention to their personal lives, because otherwise, ultimately, they'll burn out.
We cannot increase productivity in knowledge work by turning up the pressure. Any short-term gains in productivity have to be weighed against future loss of employees.
Cutting corners on quality is no way to increase productivity. Just as the lean folk say today, DeMarco and Lister said 25 years ago that "the trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted". They add "Quality... is a means to higher productivity", yet "Quality is free... to those who are willing to pay heavily for it". That is, we must pay heavily for quality but the returns justify the investment.
Parkinson's Law: "work expands to fill the time allocated for it". The authors say this is a destructive myth.
Coding Wars: the authors collected data from various environments and compared time-to-completion for correct implementations of sample programming tasks. They found a 10:1 ratio between best-to-worst, and better half being 2:1 as fast as the wore-performing half of programmers. What was more interesting, though, is there was a 10:1 ratio between best-to-worst organizations. If you work in a noisy, disruptive office, well, everyone is affected. If no one can can get any work done "between 9 and 5", work on it.
Disrupting the flow of concentration may require "fifteen minutes or more" to get productive again. Many environments are so disruptive, no one gets into flow enough to get anything done. When applied to an agile context, I think that flow is different. The authors concede that people doing similar work in the same room aren't often disrupted by the hum of their coworkers, and the general consensus on the XP list is that we're trying to optimize the flow of the team, not of individuals in a team environment. That means interruptions related to the current activities on the team are OK, a change in direction and distractions are not (hence the Scrum rule prohibiting changes to the sprint's cards?) Answering the phone--is obviously disruptive. The authors advise against electronic interruptions of any sort.
Cornell University's findings on the effect of music--workers were less creative!
"Professional means unsurprising". An organization is constantly becoming more uniform, more rigid, more standardized. This reduces "the potential to generate energy or do work".
Aptitude testing doesn't work for making hiring decisions--but it does help employees do self-assessments, to motivate them to improve and to work hard. What we need is autonomy, purpose, and mastery, according to Dan Pink.

Supporting Teamwork
They say that "someone who can help make a project jell is worth two people who just do work".

In Alexander's A Pattern Language, he writes "without communal eating, no human group can hold together...we found this worked most beautifully when we took it in turns to cook the lunch"
"The business we're in is more sociological than technological, more dependent on workers' abilities to communicate with each other than their abilities to communicate with machines"--and so recruiting should include an evaluation of a person's communication skills and sociological aptitude.
Change the culture of turnover. Encourage employees to sign-on permanently.
"Voluminous documentation is part of the problem, not part of the solution". And so the Agile manifesto wasn't first to publish this idea. They even touch upon the idea of complex rules-->simple behavior; simple rules-->complex behavior explained in Complex Adaptive System theory, and talk about "malicious compliance" where employees can follow the letter of the law while going entirely contrary to the spirit of it.
This is the book that coined the term "jell" to refer to a cohesive, interdependent group of individuals whose production of the team is greater than the sum of its parts.
On a jelled team, managers don't need to provide motivation--it's already there. The people find the work more enjoyable than it should be--just because of the team. The goal could be arbitrary--but everyone has agreed to help achieve it.
Much of our work is still independent--the team serves to make sure everyone's pulling in the same direction.
"You can't make teams gel"
Autonomy only exists when managers give their employees room to make mistakes.
Managers who support teams aren't doing the work of the team--they're focused on healthy relationships
Promote excellent quality
Make (even fabricate) milestones, so people can see progress and feel done
"Promote eliteness"
"Encourage heterogeneity"
"Preserve and protect the team"
"Provide strategic but not tactical direction"

What is a jelled team?

they have a strong sense of identity (shared jokes, shared lingo)
they've got a sense of eliteness
joint sense of ownership
individuals seek peer review
interactions are fun, easy, healthy, warm, confident
loyalties within the team are stronger than to the company

One example, Black Team (at IBM?), was particularly impressive--they formed a culture that stuck even when individuals eventually moved on; their effectiveness improved dramatically over time, and the company considered them a great success.

we need stories from more lean companies

2010-02-25T00:29:00.001-08:00

From what I understand of the mass recalls from Toyota, the company lost its culture of quality first. Apparently some managers chose to prioritize growing the company, which caused a conflict of interest any time a problem was discovered--and managers didn't invest the resources to dig to the root cause of the problem. I think this story doesn't kill the credibility of the Toyota Production System, but I do think that it shows that even a 50-year-old culture can be compromised if a company tries to grow too fast. I think that Toyota still proves that average people can have a collective intelligence greater than their own individual strengths, but that this is very fragile.
So much of the lean literature and discussion is about Toyota that this has been rough news... we need to hear more stories about Dell, Zara, Amazon, and other lean companies. Where do you get this kind of news?

the revival of an oral tradition

2010-02-23T10:09:00.000-08:00

Around 400 BCE, Socrates stated he didn't trust the written word for the following reasons:

When the audience was confused, no one could respond to questions
When we no longer train our memory to recall facts, we become more forgetful
The written word cannot tailor the message to the audience, nor does it afford the art of performance

We in the Agile Community can appreciate this perspective; in fact we have embraced face-to-face communication in many ways, from encouraging teams to Sit Together, to promoting peer learning through user groups, conferences, and the Gordon Pask Award (or official Pask Award site), as well as the Agile Manifesto's explicit valuing of "working software over comprehensive documentation", and the popularity of story cards/backlogs that are so brief that they offer no more than a "promise for a conversation".

Yet why is the oral tradition so important? I think it is the most direct way to capitalize on the Wisdom of Crowds, to tap the collective intelligence of the people on our teams who are doing the work. When system requirements are written down, organizations tend to be more hierarchical, individuals more specialized, and more ceremony is involved in software processes. On the contrary, when we rely on oral communication, the organization tends to be more flat, relational, and responsibility is shared. This means that people who have to live with a design/process decision also have the ability to fix any mistakes... and so mistakes are fixed more readily.

There is more. Oral tradition fosters an environment where we begin to use words in a particular way--leading to inside jokes, even dialects--and gelled teams. Often the words used by team members helps them communicate faster and more precisely, at the same time as giving them a sense of belonging and identity. If corporate documentation attempts to standardize on certain word choices, this can damage the fabric of a team. On the other hand, if we allow our teams to specialize their language, grow close and communicate face-to-face, they'll make smarter decisions together, and work together to achieve goals better than if we rely on armchair architects.

Agile Besançon -- beautiful code

2010-02-08T23:46:00.000-08:00

Last night at Agile Besançon we talked about beautiful code (based on the book Beau Code). We started with about a 25-minute implementation of a binary search algorithm, followed by compare/contrast of code, and an analysis from the book of common mistakes. Apparently this is much harder to implement than one would first expect, and only 10% of programmers can get it right in 2 hours. We all found vulnerabilities in our code (overflows, invalid assumptions about boundary or repeating cases), and it was a great opportunity to reflect on the assumptions we make as we code.

estimate-free still needs estimation

2010-02-04T00:22:00.000-08:00

Some agile teams have moved to a kanban-style process in which there is no explicit planning game or estimation cycle--but I think it is an oversimplification to say there are no estimates in the process. How could a team have dozens of story cards approximately the same size if no one ever tried to predict the size in advance?

I posted the following to the XP list today, in response to the Task Underestimation and Overestimation thread:

To [estimate], or not to [estimate]; that is the question,
Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous [deadlines],
or to [code bravely] against a sea of troubles, and by [overtime, to deliver]...

When I think about it, the experiments I've done to remove estimation from our stories were more about reducing the waste, than entirely removing estimates. Consider this--there must be *some* implicit estimation if we're going to slice our stories until they're all about the same size.

My current team has rejected estimation-free cards. We tend to like the size value on the card to remind us of the scope, to keep an urgency about the work, etc.

Still, we've also been unable to add estimates to all cards, using our current planning game; maybe 1/3 of the cards in an iteration show up without estimates at all, and it's too much BDUF to split the stories more. Instead, we treat an un-estimated story as a timeboxed research or a spike--the only expected result of these kinds of cards is a stack of new story cards with estimates. Sometimes the product owners pick how much time to invest in this research, in which case we'll tag the story cost as SPIKE:2, for example, to mean 2 points' worth of spike activity.

flow and concentration

2010-01-28T04:49:00.000-08:00

For 15 of the last 16 months I've been working with my dev team to help them get to the next level with agile--something the Scrum folk call hyper-productivity, but I think they use the term too loosely, based on the number of teams I've compared notes with at agile conferences and user group meetings. Anyway, my team hit that 3 weeks ago--something clicked, and everyone is on the same page. The team is self-organizing, committed to iteration goals, and constantly challenging the scope of a story. They're delivering under-budget on major release milestones, and doing so without increasing any debt I can perceive.

What does this have to do with flow? Since I'm currently playing a role of product owner, this means my workload has just doubled or quadrupled. I'm getting interrupted all the time to answer questions about story cards--and I'm constantly trying to dig into current, past, and future cards to find out exactly what the users need. I'm also hyper-aware of flow right now because I'm reading Peopleware, and so I posted the following to the Extreme Programming yahoo groups list:

short version:
Is there new thinking or studies that rationalize away DeMarco's & Lister's advice against open floor plans? Are there new studies on the impact of background noise on creativity?

background:

I know these are old books, but I decided to read some of the classics that were published before I was done with middle school ;), like Peopleware and the Mythical Man Month.

In Peopleware they talk a lot about flow (mental focus). They cite studies on the negative impact of interrupted concentration, the negative effect of background music on creativity, and about the performance dip faced by teams who they sit in open-plan workspaces. I don't know how to assimilate this with contradictory advice and experience, with, for example, Whole Team, the Customer is Always Available, Pair Programming, the Pomodoro technique, etc.

Personally, when I develop I feel like my pair can keep me in the flow if I get interrupted... but then again, sometimes that interruption distracts both of us. On the other hand, I feel like flow is dangerous--if I don't use some external "wake-up" call like a Pomodoro, I might go down the wrong path and deliver nothing of value. I've also observed my team learn how to get back into flow--I'd say they can often do so in one minute (and they learned this after only weeks of using Pomodoro).

My doubts come mostly from the conviction in DeMarco's and Lister's words, combined with what I'm seeing in the next generation of technology users--people that don't realize the impact of multi-tasking (homework+sms+tv+phone+???). Maybe I'm just not aware of the negative effects of being in a team room because that's basically all I've ever worked in...

Is there something missing in the way I do XP that provides guidance on when it's OK and when it's not to interrupt a pair? (we've actually experimented with it, but basically we believe that a developer should try to answer questions alone for 5 minutes, then ask for help--and the team/individual can respond with help or inform that now's not a good time--come back at the next pomodoro pause. I use the term pomodoro loosely, for more info, see http://dhondtsayitsagile.blogspot.com/2010/01/no-more-pomodoros-synch-point.html ).

No More Pomodoros--Synch Point

2010-01-22T00:25:00.000-08:00

Over the summer our team experimented with the Pomodoro technique, using one pomodoro to rule them all, and now over 6 months later we still have something that was at least inspired by the technique. We call it a point synchro, in French, and the literal translation works well to call it a "Synch Point", but unfortunately that just doesn't have the same feel for me. I think that this is just a problem of being part of a team--we develop our own dialect, our own vocabulary, and it just loses the inside-joke-intimacy when we use more general terms. Regardless, we have speakers set up on a machine to play a random .mp3 for 30 seconds at 10am, noon, 3pm, and 5pm--four synch points a day--and the music plays a software-induced crescendo. When the music stops, everyone is supposed to be at the front of the room, standing up fashion. People share what they need to, the Product Owners ask what it's going to take to move the cards to the done column, and people discuss in as much detail as long as necessary... anyone who is not interested moves on, or interested parties collect around a pairing station to work out some details. Most sync points are done in under 5-10 minutes, for 9 people.

Wisdom of Crowds Release Planning

2010-01-20T08:13:00.001-08:00

At our last corporate meeting, I was invited to facilitate the discussions for the road map / upcoming releases. The slides I used were intended to keep the sentiment light and playful:

Participants were asked to come to the meeting with a list of ideas to work on for the next two releases. (Though we deploy internally every week, and customers can theoretically use these releases, our marketing efforts are geared towards the official releases that come out 3-4 times a year.) Each planning session would run for 90 minutes, and was designed to get everyone talking about what functionality is important.
Each planning segment included a slide that illustrated what each person was to focus on... often for developers it was confirming scope or estimation; for consultants/sales, it was either defining minimally marketable features or re-prioritizing their stories or taking stories away until the sum was 12 weeks. It was frustrating for people when they were asked to move on to another group, but newcomers often had great questions and new ideas. Overall the exercise was a success, from the PO perspective, because it identified some features we hadn't considered, and confirmed other things about our product vision. We ran through the whole process twice, to plan each release separately. We had a quick feedback session/retrospective in between to decide on what to change for the next time around, but mostly we kept the same process. The second cycle went a bit better because people knew what to expect, and they were more comfortable with the aggressive schedule. At the end, everyone was frustrated with the compromises they had to make, but they felt like the draft road map they'd produced reflected their collective priorities.

Setting the Stage
I opened the meeting by setting the stage--saying that officially this gathering was intended to provide input to the Product Owner (PO) team in planning the upcoming releases, but that unofficially I hoped the group could come up with something that would be good enough to be the final road map. I felt that since the whole PO team was present, their input would be considered and therefore the output could be final. I pointed out that each working session would be short--about 10 minutes, and that someone from each group would move on to another group at each pause. I also asked that people aim for equal participation from each member of the group.

Collecting Data/Making decisions
Brainstorming (5 min)--individuals were asked to review and prioritize their lists of what we should work on for the next release (or make one if they didn't do their homework).
Estimating (20 min)--we broke out into two groups of 5-7 people each; each group had at least one consultant, one sales person, a developer, and a PO. Non-devs were expected to take turns describing one idea at a time, in just barely enough detail for a developer to give a coarse-grained estimate in weeks of dev time. Unfortunately people got too caught up in accuracy and only got one turn each... and these story cards were coming in with quotations between 2-8 weeks of development. For the next round we clarified that we wouldn't be keeping these story cards--they're throw-away--and that we don't need really accurate estimates, since we're just trying to get a feel for what the scope might be. In pilot runs of this exercise, when people didn't take it too seriously, they were able to do estimates at about 1 per minute. This time around it was taking 5 minutes per card.
Feasibility (15 min)--Now it was time to see if everything we wanted would fit. The new developer was to confirm story estimates by asking questions about scope. Side conversations in the group were common, and expected, since this increased bandwidth of communication.
Prioritize (10 min)--The group needed to prioritize in order to pick the most two critical stories... these stories were going to be sent to another group. A new PO in the group had veto power over cards, but as far as I know this veto power wasn't used. A few people complained about having to send story cards away, but I thought it was an important element for consensus-building across groups.
Fill in gaps/Find themes (15 min)--A consultant or sales person arrives in a new group with two story cards, and it's time to talk about these new cards, to re-add what was just sent away if necessary, and to re-adjust the set so it sums to 12 weeks.
Prioritize Themes (15 min)--The actual story cards are no longer important--group them into named categories (themes), copy the estimates onto the cards, and be ready to present to the whole room. Everyone's set of stories will have converged, so hopefully a final draft will be easy to make.

Feedback
The time frame was very aggressive. My estimates were off, but ultimately we used the following--brainstorming, 5 minutes; estimation, 20; feasibility, 15; prioritization, 15; themes, 15; prioritizing themes, 10; leaving 10 for shuffle time. I had hoped to have a step or two after what's pictured, where the whole group meets to discuss the set of features for the proposed release, but we ran out of time. People were frustrated with not having prepared enough, with having seen their good ideas get bumped to a later release, or get dropped from the schedule--but the PO team was very happy. We felt the priorities corresponded well with our vision, and some items that weren't on our radar scope showed up.

The Mythical Man-Month by Frederick Brooks

2010-01-17T05:13:00.000-08:00

In the 20th anniversary edition of The Mythical Man-Month, Frederick Brooks adds four chapters to re-evaluate some of the positions he made in 1975. This book is mentioned over and over in things I read, and so I decided to go see what makes it a classic for myself. I was quite impressed with the notion that many of Brooks' ideas and projections are dead-on, even today, well over 30 years after he wrote about them. Then again, he says himself that many of our problems are people problems, not technology problems, and I guess human history is condemned to repeat itself if we don't know what came before.

One projection is that there will be no "silver bullet" that offers orders-of-magnitude improvements in productivity. Another is his emphasis that for large systems, we need conceptual integrity, and to organize it, he proposes recursion of architects (layered levels of decreasing abstraction). Many readers of this book were surprised that it devotes more time to people issues than technical--but he says that is and remains the biggest challenge in software development.

Though I found the book a bit dry and out of date, it was worth a quick read for the simple reason that it holds so many ideas that are so strongly advocated by Agile practices, and others that are not. Consistent with agile--we must use a process that assures us that "one always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build"; "conceptual integrity is the most important consideration in system design". Communication is critical--and exponentially more difficult with larger and larger teams. He advocates giving developers room to be creative, saying they need room for "invention and craftsmanship". I guess the craftsmanship/codesmith movement goes way back! Another great line is "whenever talents permit, senior people must... delight in building programs with their own hands". No arm-chair architects or managers in Brooks' world! He also believes in "done-done", in other words--"milestones musbe be concrete, specific, measureable...coding, for counterexample, is '90 percent finished', for half the total coding time. Debugging is '99 percent complete' most of the time...". Though stand-up meetings weren't called it at the time, he knew the wastes of "status-review" meetings, and started calling things problem-action meetings instead. He also states, in more archaic terms, that getting the Acceptance Tests [design] right is the hardest part of development.

Not part of the agile world, he advocates both small iterations or large deployments, depending on context; he's the one who states "the bearing of a child takes nine months, no matter how many women are assigned", he posits that a project gets to be one year late, one day at a time; he (quoting Harlan Mills) suggests the ideal team structure be modeled after a surgical team. He names the "second system effect" as tempting designers to add extra features and frills that they didn't have a chance to add in the first system--and as a result this becomes bloated and fails. I think I saw that effect when I was on the job in New York. Brooks also talks a lot about documentation... I think this has been obsoleted by the use of intent-revealing test-first coding. Another obsolete point is his statement to "plan to throw one away".

Brooks obviously read a lot in preparation for this book--accumulating benchmarks, such as when he proposes that system coding should only be around 1/6th of the schedule; that developer estimates are often 1/2 of the actual time because of meetings and other interruptions from coding the active project; that higher-level languages (and implicitly higher levels of abstraction) are the only thing that's come along that can offer orders-of-magnitude improvements in productivity.

Agile Besançon Informal Discussion Night

2010-01-17T04:59:00.000-08:00

We had scheduled a discussion on lean for the 7th of this month, but due to low turn-out, we ended up talking about one member's frustration about software development--he stared by saying he was sick and tired of it... that in other professions, a person could reach a level of quality that was demonstrable and durable... take a look at quality stereo equipment, or a hand-made wrist watch. The stereo he has at home was built with such pride that they sent out the schematics for it with the packaging--they felt like if anything ever broke, end-users could get it back running with minimal effort the design was so simple. On the other hand, just taking a look at code he wrote a year ago makes this developer sick with code smells. Why????

We talked for about 2 hours on this and other subjects... we hope to see you at the next Agile Besançon event :

lun 1 fev, 2010, 19h – 21h -- Coding Dojo -- "beau code"
mer 3 mar, 2010, 19h – 21h

mar 6 avr, 2010, 19h – 21h

favorite lines from Peter Block's Community -- the Structure of Belonging

2010-01-13T12:52:00.000-08:00

This book seems to apply to so many aspects of my life--family, political, work, volunteer efforts in the Agile community--Block begins the book by stating that we need to:

Transform the isolation and self-interest within our communities into connectedness and caring for the whole... by shifting our attention from the problems of community to the possibility of community

We suffer from too much individual self-improvement, and not enough connecting. We need to assume bounty, to be generous, to welcome the gifts of those around us, and find what we might build together... find what we want to create, together.

Organized professionalized systems are capable of delivering services, but only associational life is capable of delivering care.

It is care that we need... individual attention to giving what is needed, when it is needed, because we understand and value one another. Block says that just the very declaration of our desire makes it possible, for before anyone imagined it, it clearly wasn't possible that we would work on it, but now that we've stated our intention, there is a chance, that we could work on realizing this potential. Block goes on to cite some studies of Italian towns by Robert Putnam--apparently the towns that were more democratic, more economically successful, had better health, and higher levels of education, shared a common characteristic--what he called social capital. The citizens of these towns were more connected to each other. Putnam goes on to characterize different types of social capital--bonding (inward-looking) and bridging (cross-pollination), and demonstrates that the most important type of social capital for a community is bridging.

Peter Koestenbaum says that choosing to act upon our freedom makes us accountable, that freedom and accountability are intrinsically connected. In addition, he says that for those that hold power over others, the ultimate act of love is to grant their freedom.

How does Block build community? One meeting at a time--by forming small circle discussions, around a broad question, with a diverse cross-section of people. He asks us to focus on the future--not the past, not our differences, but our potential. He seeks small-scale and slow growth. We depend on people that choose to volunteer, rather than those who feel an obligation to show up (as in paid staff). Word choice is critical, because it is one of our only tools of relating--Block notes the difference between the "problems of community" vs. the "breakdown of community"--the second suggests that there is a loss worth reconciling. Personally I think this is a weak distinction, but may still be needed to complete the other tools he presents--focussing on possibility, looking forward, etc.

Block says that all acounts of the past are "Made up. Fiction." When we consider the narrator has necessarily left out some details, things that are important to other parties in the story, it can be liberating to agree. Though these stories are heartfelt, they can be both divisive and enriching... yet stories are one of the most effective tools for sharing. He invites us to find inspiring, hopeful, impressive stories about the future, that will help us transform those around us.

Block contrasts the corporate-driven marketing of fear, fault, and self-interest with that of community/associational relations. On the one hand, there is an idea that with more control, more laws, more police, a better economy, better press coverage, better leaders, that things would go better. On the other hand, Block advocates using our own power to be the change we wish to see in the world. When we look at what is in our own power, we can have a much greater effect than any paid service. When we choose to integrate with those around us, rather than to be insular and worry about our own survival, we increase social capital and restore community. When we restore the community, people are willing to make promises to one another, to help each other, and to be generous.

Why is it easier to raise money for earthquake survivors thousands of miles away than for the people living six blocks away that are having a hard time paying rent or keeping food on the table? Block says this is partially a result of projections--taking attributes that we deny of ourselves, and placing them on other people, e.g., laziness. What happens is we divide our local community, and lose out on the possibilities that come when we care for the well-being of the whole.

When we hear complaints of "why so few people are involved in the community", or hear people talking about "entitlement", it is time to invert the signs of despair. First, ask if there's something we're doing that is excluding some of the community. Then remember that true commitment is a gift, and can never be enforced from the outside (so no one is entitled to anything). When we have a true restorative community, people are not asking "what's in it for me"--they're giving freely. People have been summoned over and over to be part of focus groups, and then wait for the "professionals" to execute the plan. Instead we need to use these meetings as a way to engage citizens to carry out the plan themselves. In addition, the discussion needs to move away from problem solving, as that is often too mired in what exists now; for true innovation we need open-ended creativity, inspired by the right questions.

Block redefines leadership--it is convening, asking the right questions, and listening. What is interesting to note is this relational leadership cannot be measured in the ways that retributional/hierarchical leadership is used to. Action may simply be discussion and connection, not necessarily a change in physical state or status of "the problem". In fact, people may find a possibility they hadn't considered before, rendering the problem irrelevant, while commiting themselves to a new way of being that supports the whole community.

How do we build community? We find out what creates energy. We provide a forum for small group discussion, which values relatedness, is launched by invitation, is focused on possibility, represents ownership by the participants, supports diversity and dissent, expects no bartering for freely given commitments, and these gifts are received with thanks. These meetings revolve around the leader's questions... a powerful question incites action by the mere fact of answering it, like, for example:

"what is the price you pay for being here today?"
"what are the gifts you have to offer that you've not yet brought into this world?"
"what is the story that you keep telling about the problems of this community?"

Before asking the question, however, one must name what distinguishes this from a retributive context, give permission for dissent, and replace advice with curiosity.

Here are a few more great lines/ideas that I don't think really need comment:

"Advice is a conversation stopper!" "Don't be helpful!"
"Real transformation comes only through choice." A leader becomes vulnerable when using the invitation to start out these discussions; "even though there is no cost for refusal, there is a price for coming. Everything that has value has a price."
"The enemy of commitment is lip service, not opposition"
"Without doubt, our faith has no meaning"... "there is no way to be awake in this world without serious doubts and reservations"
"Don't ever underestimate the determination of others to hold on to their stories"
Block doesn't like protest--"every time we act in reaction, even to evil, we are giving power to what we are in reaction to".
"our life work is to bring our gifts into the world"
For snacks at meetings, Block asks us to provide locally grown food that is healthy.

second Agile Besançon event

2010-01-05T21:22:00.001-08:00

This is a long-delayed post, seeing that we're about to have our next Agile Besançon event this Thursday--but for our last event, Monday, Dec 14, we joined with Bar Camp for its kickoff event in Besançon. The organizers there took photos and documented a bit more, so I won't repeat what they said. I presented a topic on test-driven development with a colleague (Fréd).

Jerry Weinberg's The Secrets of Consulting

2009-12-24T08:00:00.000-08:00

This book is a collection of stories and memorable rules... it is unlike anything I've read before, and is hard to absorb in one stretch--I'll probably have to go back to the "listing of laws, rules, and principles" to jar my memory every once in a while. Yet one of the beauties of Weinberg's storytelling ability is that the names quickly bring me back to the story, then back to the lesson.

So, this book says it's about consulting, but he has a very loose definition of the word--consulting is giving advice. The most important thing I got from Weinberg is to never, ever give unsolicited advice. Then, even when asked for advice, it's best not to respond directly, but rather help the person discover it him/herself.

I love his names, like Rudy's Rudebega Rule, the Law of Raspberry Jam, his insistence that as a consultant, he plays more of a role of being illogical, funny, unpredictable than anything else... He seems to have great facilitation skills, great timing "know when pays more than know how". There have been several things I do as a coach that are supported by his rules. I'll list my favorite rules below:

the First Law of Consulting--there always is a problem
the Second Law of Consulting--"no matter how it looks at first, it's always a people problem"
the Third Law of Consulting--if you solve the problem too fast, it's going to be embarrassing
the Fourth Law of Consulting--"if they didn't hire you, don't fix their problem"
the Orange Juice test--"we can do it, and here is how much it will cost"
Brown's Brilliant Bequest--listen to the music and the words
the Buffalo Bridle--you can make 'em go anywhere, as long as they want to be there
the Credit Rule--don't worry about who gets the credit
the Duncan Hines Difference--it tastes better if you add your own egg
the First Law of Trust--"no one but you cares about the reason you let them down"
the Fourth Law of Trust--"the trick of earning trust is to avoid all tricks"
the Five Minute Rule--"clients reveal the answer to their own problem in the first five minutes"
the Ten Percent Solution Law--"if you happen to achieve more than ten percent improvement, make sure it isn't noticed"

corollary to the Law of Rasberry Jam

2009-12-13T04:18:00.000-08:00

Weinberg's Law of Raspberry Jam states that the thinner you spread it, the thinner it gets... it's hard enough to change oneself, harder to influence a team, harder still to influence a class, and yet harder to influence readers of the book. I'd say that a corollary to this is that pop culture, which as whole doesn't respect the source of the ideas, is condemned to keep re-inventing the wheel. It's funny, because one would hope that a really good idea would spread like wildfire, but it can't--it spreads like raspberry jam instead. By the time the masses catch wind of it, it's been reduced to a jingle or technical buzz word.

where the Agile Skills Project needs to go next

2009-12-10T11:24:00.000-08:00

There's something new happing in the agile community, despite the fact that some celebrities in our field are waiting for innovation in a post-agilist era, or saying that there's nothing new at the conferences. The transformation is subtle, but very important. In short, it's the creation of local agile implementations that value people over process, community over employers, dedication to the craft and cooperative relationships.

A lot of practitioners are getting experienced enough that they can exploit self-organization to reach out to people in contexts different from their own. Mostly these practitioners are lower profile than the signers of the agile manifesto, but they're not typical early-late majority adopters either, because they're innovating in the wake of the first wave of agilists. They're running their own open-spaces, creating local user groups and conferences, networking internationally, and doing the best they can to learn from one another. Some might call this massive adoption 'crossing the chasm', but in fact they are creating their own flavors of agile at home, based on the learning that comes from participating in the agile community, from previous experience, from corporate and government requirements, and local cultural needs. The agile conferences have been key to building this community, but they're still spread out in time and space in ways that aren't sufficiently accessible for the masses of people that are trying to do agile these days. In addition, the face-to-face conferences have provided sufficient context for people to start working together remotely. The open source world has long leveraged collaborative work at a distance--the agile community, not so much.

So here's what I see...

There are currently over 700 subscribed to the Agile Developer Skills list, which in my mind is the core of the Agile Skills Project. To me it shows that practitioners are coming together in unprecedented numbers to talk about how we might better learn from each other, to define standards by which we will hold each other, and how we'll acknowledge each other's discoveries and hard work. This is low bandwidth collaborative work and can't compare to what we learn at conferences or with consultants, but there's something new afoot.

Next we need these people to take ownership of various places on the wiki, talking about quests, or certifications, or courses; building on the skills inventory, etc. We'll need people who want to build the web application that logs quests and qualifies certifications and course material our classes.

Mostly what we need is people who are willing to tell stories about their development practices, their conclusions on what works and what doesn't, and then peer-reviewed comments on these stories. I hope to see that soon!

deliberate reflection and the Agile Skills Project

2009-11-26T02:01:00.000-08:00

Recently I read something from Robert C Martin suggesting that it's only through deliberate efforts that we improve our craft (hence his series of Katas)... today I bumped on the following from Alistair Cockburn.

In The Reflective Practitioner, Schön follows the working habits of architects and engineers. In that book, we see people making predictions as to what their situation will support; then they do some of their work and watch what the situation actually produces, and from that, they alter their understanding. They update their understanding of the problem and the proposed solution according to the changed situation and their new learning. This “reflective conversation with the situation” is just what the Wright brothers did in designing their airfoil.

Craft implies skill in working in a medium, mental or physical. There are many materials in an engineering project and therefore many skills or crafts to become adept at. Some people need people management skills, others need mathematical skills, others need visual design skills, and so on.

Each skill and material brings its own specialized vocabulary. Ceramicists “wedge” clay and study the shrink rate of different glazes compared to clays. Civil engineers work with the tensile strength, fatigue rates, and thermal expansion of their materials. Writers look for flow and development in their texts. Programmers look at cohesion and coupling, testability, clarity of expression, and computational complexity in their algorithms. Testers work with test coverage and probabilities of occurrences. User interface (UI) designers work with cognitive-motor task switching times, recognition times, color scales, and user work patterns. Project managers work with people and are concerned with what builds or tears down trust, community, and initiative.

In each case, craft practice requires practitioners to have a reflective conversation with the material, using the specialized vocabulary. They work with the constraints offered by the materials, the vocabulary, and the project.

It is this deliberate, reflective, intentional improvement that we're trying to support with the Agile Skills Project. Do you have something you'd like to contribute? What can we create together? Sign up for the Agile Developer Skills (http://groups.google.com/group/agile-developer-skills) group, and let's talk!

Domain-Driven Design

2009-11-17T05:42:00.000-08:00

It's been a while since a colleague (thanks, Nolan) recommended this book, but I finally read it: Domain-Driven Design by Eric Evans. The author talks about a kind of code debt I'd intuited a long time ago, but could never describe in words--a semantical mismatch between the mental model used to explain the code and the language used by domain experts. This book is important because with an alignment between the code and the domain, we can automate at higher and higher levels of abstraction, and therefore reap the benefits of rapidly increasing productivity. This is the greatest value of custom software--the domain-specific objects that reflect a team's understanding.
In Philadelphia, our team focused our code by naming projects, classes, and methods in ways that business stakeholders would recognize. This made it so we shared a ubiquitous language, as Evans calls it, a clear set of names that make sense to both developers and stakeholders. Something we didn't do enough of, though, is refactoring as the terminology evolved. We did practice merciless refactoring, but it was driven primarily by technical needs. Evans also mentions that the natural language of domain experts will be imprecise and self-contradictory, so it's important to be able to create, together, a new language that is unambiguous. Humans are especially adept at creating language, and the process of using our new shared vocabulary will propel us to simplification--we naturally find easier ways to say things. By implementing these verbal shortcuts in the code, it is simplified as well. The resulting deep model will constantly evolve as our understanding of the domain improves, and our communication about the domain will become more and more precise. In fact, the communication can become so precise that Evans reports an end of the "mystifyingly unexpected requirement changes". The new language used to describe the domain model can be so powerful that it's a selling point for marketing purposes, it's a market differentiator!

The following are points I underlined in the book, but may not make much sense to anyone else:

When we're working on a domain model, name things to reflect intention, rather than implementation. Evans also likes "closure of operations" because they perform operations that bring along no other dependencies (closure means input/output are of the same type).
Evans presents many ways to simplify the domain model, for example:

by constraining many-to-many associations with a clarifying attribute
minimizing the number of associations
making associations uni-directional

If the code is in need of significant refactoring, prioritize by clarifying the core domain first.
He also discusses entity objects, value objects, and services, the last should optimally be an operation that does not fit in either an entity or object, it takes some entity or object as a parameter, and it's stateless.
The Repository pattern is a way to keep caching/data store and retrieval from polluting the domain model. Essentially, the repository objects will act as if they are a permanent in-memory collection of persist-able objects, with even some helper methods for quick retrieval of often-run queries. Repositories are made to retrieve existing objects, while factories create new.

Agile Besançon

2009-11-09T14:14:00.001-08:00

So tonight we held the first meeting of what I’m calling Agile Besançon… it builds upon some organizing work that Ludovic, Olivier, and Regis have done in the past—going back as far as the coding parties that Olivier held at his house. Tonight’s meeting was held in a conference room at Temis Innovation, the incubator for the startup I work for, Smartesting.

Ludovic and I facilitated a discussion on Managing Multiple Projects at Once. Conventional Agile wisdom recommends against multi-tasking, and against running multiple projects with the same team, because task-switching incurs a heavy performance cost. Still, some teams cannot get their management or their customers to focus—so how can they cope?

We started the meeting with a brief check-in, describing how we hope to have monthly meetings where we can play, practice, and discuss topics/skills that we don’t normally address during our work day. Then we showed how we planned to use the time for the evening—check-in until 7:15pm, game until 8:15pm, and retrospective until 8:30. We all introduced ourselves with name, job title, and company affiliation, 11 in total, 3 companies represented.

Ludovic and I had invented a group exercise to help people warm up to the ideas we’d be presenting—the object of the game was to use an assembly-line of workers to build paper airplanes—15 copies each of 2 different models. We started with a 5-minute prototype phase—and the Acceptance Test for completion was that the plane had to be able to fly across the room. After a brief pause, we gave each team (of 4) 5 minutes to build their planes—but they were forced into a Taylorist production model—one person rips out a page from an old magazine, next person puts one fold into the sheet, next two people are plane builders—of the kind of plane they had prototyped. In 5 minutes each team had built about 6 planes—and we then talked for 5 or 10 minutes about what we noticed. Then each team had a 5-minute huddle on how to improve the assembly line, followed by another 5 minutes of production. This time each team produced 16 planes—but one team focused on model A, while the other team built both types. Only one team noticed a hidden requirement written on the whiteboard—that the customers only pay for completed batches of 15 planes. Afterwards, we talked about the strategies the teams used to speed up (moving more people to the plane-building role, thanks to Theory of Constraints), and we talked about what might help them reach the goal of selling both plane types. Someone suggested re-negotiating the batch size requirement—and we said that is an excellent way to deal with multiple projects—that as soon as we can get to small releases (minimally marketable features), it’s not as penalizing to switch off to another project—but to switch before releasing means shelving the unfinished investment and therefore indicates waste. We followed this discussion with a perfection game on the game itself:

The notes, translated from French, indicate that we should keep the:

short iterations
brief reflection after each iteration
simple materials
prototype phase

For next time we might consider changing:

construction targets—different objects, like a boat and plane, or simple folds instead of more precise objects
don’t run an acceptance test for everything?
the number of projects (have more than 2), and find a way to get people more actively involved in decision-making/collaborating
making different objects worth different prices, maybe depending on the construction cost

Points of confusion, open questions:

what was the overall goal?
how can we help people be more collaboratively involved?
deliver airplanes?

We ended the night with a quick Blond-ROTI chart (Return-On-Investment):

Translated, on a scale of 1-10, people rated the following:

Worth it to come to the meeting tonight: 8
I learned something: 5-8
I will change something tomorrow: 1-7
I’m ready to lead a discussion for the next Agile Besak: 2s and 8s
I’ve encountered this problem: 1s and 9s
Would it be interesting to have more of us: 8-10
I will invite someone the next time: 9-10
I’m ready to come the next time: 10
There should have been more experience reports [tonight]: 10

Agile Developer Skills Workshop--Day Three

2009-10-15T08:59:00.000-07:00

Today is the culmination of the three-day workshop... I think the team has really gelled with a common purpose and shared values. I had to leave early, so will only report on the morning--but stay tuned because soon we'll have something sufficiently well polished that we don't have to hide our candle under a basket.

So, with the caveat that the group may quickly change direction (we're all agile, right?), I'm happy to report on where I think we're going. We'll be creating the Agile Skills Project, an ongoing, open, and not-for-profit entity that will do the following. But first--who is the "we" that follows? Assuming that you're at an experienced practitioner level, it probably includes you:

create an "agile skills inventory"--a list of skills that are important to being a good agile team member (note, this is not just for coders), a definition of those skills, and even links to existing learning materials (books, web sites, courses, classes) that may help one acquire these skills. These skills will be mapped to the Seven Pillars, and specific ones will be selected as fundamentals that every well-rounded agilist should know

provide a way for individuals/teams/orgs to self assess against the inventory--this can be an index into where they should focus self improvement efforts, or what kind of help to seek, paid or unpaid.

recognize progression along the agile skills inventory--the intent here is to celebrate the successes we make in our life-long learning; the risk would be that people could misconstrue this as an endorsement of a particular competency, which it is not. We see several levels of progression through a skill: exposure/awareness, attempted, successful execution, refined execution, advanced the state-of-the-art. From the "successful execution" level and up, there would be third party verification that the skill was indeed performed correctly.

characterize learning materials--we'll be able to map existing courses, certifications, conference sessions, books, etc. back to how much they cover the agile skills inventory. This will give a nice "nutritional content" to these learning materials, and help people see the objective value these materials provide

collect experience narratives--at some point, all this work should tie back to the correlation between delivery and skills. This will provide data that correlates successes and failures to how we do the work.

review experience narratives--With experience narratives, we'll be learning from practitioners in the field, and be able to improve the Agile Sklls Inventory accordingly. As a nice byproduct of experience narratives, we'll have a paper trail of what progress individuals have made in their learning journey.

Agile Developer Skills Workshop--Day Two

2009-10-14T13:50:00.000-07:00

So imagine an organization, run by the agile community (or a large subset of it--at least the people that have shown a trustworthy commitment), that is in charge of defining the set of skills we find useful in being a member of an Agile Team. This group would be involved in:
-defining an Agile Skills Inventory (e.g., Active Listening, Story Splitting, Test-driven development)
- providing a repository for reference courses
- defining self/peer assessments
- defining a quest ecosystem
- experience reports
- characterization of external courses (for a fee?)
- rating of trainers for a particular course

Well, this is what we're trying to imagine, and here's how we attacked it today--in several sessions. The group asked me to help facilitate (thanks, Pat, it was a great honor! though I'm not sure if I did in fact keep us on task):

We pondered what value this system would produce, so we talked a bit about supply and demand:

Then we talked about the idea of "a quest ecosystem", or points, or merit badges, or achievements, and ultimately thought it could be called tokens. Basically, we'd like to acknowledge the work people do to improve their developer skills:

Then we tried to clarify what this Agile Skills Project would be all about:

Essentially, what we see right now is that the community would own and maintain the ever-evolving definition of agility, then certify training organizations/courses/study material against the standard. To help developers, these 'certifications' would characterize the courses; alternative free methods would also get characterized as well--so then it's up to the developer to take a course or teach oneself.

To further help the community, we'd have a 'token' system, by which team members could go on learning 'quests' or exercises, which would be recorded in a web site as an experience report. This report would be rated by peers and generate points for both the reviewer and reporter. These points would not be fungible, would have no external worth, but could be used to help people categorize their own strengths and weaknesses, to prioritize further learning quests.

One of our group members took some of the initial 7 pillars work (technical excellence, collaboration, product understanding, supportive culture, business value, confidence, continuous self improvement) and made a wordle picture:

Agile Developer Skills Workshop--Day One

2009-10-13T15:35:00.000-07:00

Today a group of interested and interesting folk (I'll get a list of the 14 attendees soon) met in Ann Arbor to discuss the Agile Developer Skills idea. We started with a quick outline that I hoped would move us from a group to a team--a list of what motivated us to show up at the meeting, a reality check on what our goals were and if our sphere of influence was sufficient to make it happen, a list of customers, and then a discussion of a business model that could sustain this system.

We soon moved into a mindmap of our various motivations:

Then we brainstormed on a list of personas that may be our "customers" or stakeholders.

Then we discussed possible goals / to-do items / outcomes of this workshop.

The next steps are to filter the list of proposed outcomes and to review, in detail, potential "generally accepted curricula" that could be used in various courses.

Agile Developer Skills Workshop--Homework

2009-10-13T14:25:00.000-07:00

In the wake of announcements from the Scrum Alliance and Microsoft on a "Certified Scrum Developer" program, that would cost around $4-5k per developer, Ron Jeffries and Chet Hendrickson are hosting a discussion on how we, as a community, can support skills development for developers/agile team members. In preparation, I hosted an open space discussion on the topic at Agile Tour Besançon, and a parallel session ran in Agile Tour Philadelphia. The community has long resisted any developer certifications, for many reasons:

existing schemes don't seem to measure the most important skills
certificate possession doesn't seem to correlate with skill
certification has been expensive
etc.

When I spoke with other developers, the following topics came up:

how is any test/class going to show if I'm good at my job?
who is going to pay for the test/class?
why should the Scrum Alliance or Microsoft or WAQB or any company be able to define agility?
what happens if people get the cert and I don't?
etc.

I also had a nice conversation with Laurent Bossavit about the topic. He suggested that at the workshop we ban the word certification--that way we'd have to reveal the motivations for wanting the program at all. He feels like certifications are a replacement for a system of trust--but once money gets thrown in, we need a way to justify the system--a way to explain what people are paying for. One motivation for creating a system would be to show who in the community is worthy of emulation... to show what behaviors are valuable, what practices are effective. In any case, this system should be community owned, democratic, and should value/reward life-long learning, while still fostering innovation towards better ways of developing software.

competing with free products

2009-09-30T00:32:00.000-07:00

TestObsessed just Tweeted about how to compete with free products: http://www.businessinsider.com/how-to-compete-with-free-products-2009-9

Short version: beat free with ad-sponsored.

focus on the customer

2009-09-22T04:44:00.000-07:00

Thanks to Poppendieck's book Implementing Lean Software Development, from Concept to Cash, I read about google philosophy:

Focus on the user and all else will follow.

Lean demands that we identify what our customer needs, then we deliver just that. She talks about how the Quicken team entered a mature market of complex accounting software, simplified it, and delivered value to their customers. She mentions Google, Dell, Zara--all companies that have risen to success because they have the right focus.

set-based engineering

2009-09-22T04:38:00.000-07:00

Since research/design is often very risky, the Toyota Product Development system integrates several processes to manage the risk. They use strict time-boxing, with multiple parallel research tracks trying to succeed, and at the end of the time box they can choose from all successful options. Their lead engineers are responsible for not only technical success, but business success, and their engineers stay on the same team for a long time, and are expected to excel in their craft. The teams, and individuals, are given objectives but are not micromanaged.

Why isn't it waste to design things we won't use? It's because waste has to be regarded in context of the whole system--and failing to deliver an acceptable design is a much bigger waste than optimizing the whole.

Agile 2009 Gordon Pask Awardees

2009-09-02T02:17:00.000-07:00

This year's Gordon Pask Award winners were Gus Power, Simon Baker, and David Hussman. Ultimately we'll read more about it at http://www.agilealliance.org/show/1656

genchi-genbutsu

2009-09-01T05:08:00.000-07:00

According to Mary & Tom Poppendieck's Implementing Lean Software Development, genchi-genbutsu means "go, see and confirm". I think it's a very powerful image for software development--when we have first-hand experience of what our customer values, we're more likely to understand its essence and to successfully make a minimalist implementation. It also sets up the relationship for us to ask customers directly about design tradeoffs. So, go, see what your customers are really doing, and find a way to make that go more smoothly--but ask them first about your ideas, to make sure you've understood the process.

Poppendieck's version of Shigeo Shingo's seven wastes

2009-09-01T04:45:00.000-07:00

The lean community has categorized the following as the seven wastes of software development:

Partially Done Work (it delays feedback, thus increasing the risk we didn't catch mistakes; our investment cannot turn a profit if it's undone; we risk falling out-of-synch with other people that continue to work on the previous version)
Extra Features (this is overproduction and the worst form of waste because it's at the top of the food chain, i.e., it inevitably included all the other forms of waste somewhere in the process of creating the feature)
Relearning (if we already paid for one developer to discover something, why pay another developer to do the same thing? still, it's very difficult to have a usable system of documentation that explains why we chose what, when)
Handoffs (tacit knowledge--that which can't easily be explained verbally or on paper--forces the recipient of a handoff to re-do part of what we've done)
Task Switching (task switching increases the time-to-completion of the most important task on our plate, or causes waste in terms of unfinished work or relearning)
Delays (when developers have to wait for a customer's opinion, they may guess or pause. Either way, it's waste.)
Defects (in my opinion, defects may be on par or worse than Extra Features as waste... we've gone through all the work of making a feature, and then have to revisit it, re-test, and re-deploy.)

favorite ideas from Poppendieck's Implementing Lean Software Development

2009-08-27T04:19:00.000-07:00

When I read paper books, I underline and dog-ear the pages. Then I come back a bit later and blog about what I read--it's a way to reinforce what I got out of the book. Here's a summary of the ideas that most struck me this summer as I read Implementing Lean Software Development, from Concept to Cash by Mary and Tom Poppendieck. Quote-marks indicate direct citations.

Toyota's productivity is "consistently four times that of its competitors, and quality is twelve times better", says Jeff Sutherland in the forward.

A little history

The book begins with a 2-page history of the industrial revolution. Starting with the late 18th century French invention to use standard, interchangeable parts for firearms, the US ran with the idea to create mass manufacturing and economies of scale that had never been precedented. Then in the early 20th century Taylor applied the idea to people--making the work of automobile assembly line workers so easy they could be trained in 10 minutes, and therefore be easily replaced. This was in strong divergence with what happened in the loom industry in Japan, where the automated looms required a lot of expertise to maintain and tune--here, individual skill was highly valued and teams were preserved, even as companies were torn down and restarted.
Just after WWII, the Toyoda family (future creators of Toyota) felt the need to catch up with American mass manufacturing, but they did not have access to the wealth of resources required to benefit from economies of scale. Instead, they aimed for "just-in-time flow", which gave them the advantage of driving down the cost of variety in their products. The Poppendiecks say that this is "the only industrial model we have that effectively manages complexity".

The Manufacturing World

Jidoka -- autonomation -- "Toyoda automated looms... detected when anything went wrong and shut down automatically". This sets the stage for a "stop the line" mentality, mindfulness, safety and quality.
When there are mistakes, it's not the worker's fault--it's the process which has room for error. Fix the process so we can't make mistakes.
Plant managers were all expected to spend some time on the line.
It is the creativity and practical knowledge of the line workers themselves that drives continuous process improvement
Lean is infectious--Toyota and Dell have extensive supplier networks, and freely exchange information and training to support the supply chain. They define contracts in a way that align the interests of both companies.
Peter Drucker states that "a company that maintains a single management system throughout the entire value stream will see a 25 to 30 percent cost advantage over competitors"
BAA built terminal 5 at Heathrow airport with a novel kind of contract, including target cost and a risk/incentive pool. Whenever a subcontract finished, contractors got paid the target cost plus anything that was left over in the incentive pool. This aligned the interests of both parties, and work went more smoothly.

How does this apply to product/software development?

the Toyota Product Development System is designed for "generating and preserving knowledge for future use"
in product development, it is not waste to explore multiple options/technologies--they call this "set-based concurrent engineering"--these options allow us to evaluate trade-offs appropriately when the time comes to make a decision
"repeatable and reliable speed is impossible without superb quality"
the Kano model states that to impress customers, we need to satisfy basic needs, as well solve problems they weren't even aware of
"behind every great product there is a person with great empathy for the customer, insight into what is possible, and the ability to see what is essential and what is incidental"--Martin Cagan of the Silicon Valley Product Group
chief engineers at Toyota play a product owner role--they are responsible for the business success of their vehicle family, and they do first-hand research (genchi-genbutsu "go, see and confirm") of their potential customers as well as pay attention to marketing research and dealers
inspection to prevent defects is necessary; checking to catch defects is waste
just-in-time decision making is critical to effective risk management. The longer we wait to commit to a particular path, the more we know about our options--but if we wait too long, some options vanish. Establish, up-front, when key decisions need to be made, and then adhere strictly to those timeboxes. See set-based design.
"above all, team members must be mutually committed to achieving a common purpose"

Software development

"unused features are the worst kind of waste in software development". Justify every feature!
"great software grows out of a mind-meld between a person who really understands the business and a person who really understands the technology"
simplify--both the product and its implementation
part of the design must incorporate the concerns of operations staff--people that will support and maintain the application
seek a "product" funding model, rather than a "project". Products are funded incrementally, evaluated on their return on investment, and are released incrementally. Like landscaping or gardening, custom projects are never done. When a "product" is championed by business leaders, it is more likely to have business value.
Don't automate a complex process. Simplify the process, then code it.
When a lot of work needs to happen quickly, we need "self-dispatching" work--that is, remaining work items need to be evident to everyone on the team, and people need to see the overall status of the group

Intra-team politics

a discussion often changes once a "decider" has been selected. Make it clear who that decider will be, and then watch the arguments unfold.
it's important that proposed changes in a system are done scientifically--so we can evaluate the old against the new (PDCA)

Value stream mapping
A value stream represents the work we do starting with a customer order and ending with delivery of that value. The map needs to be detailed enough to uncover problems, but should also abstract sufficiently so we can see the big picture

long delays indicate queues--we want to get rid of queues because they represent an unfulfilled need, a warehouse of undelivered value that wastes money to sustain, and they inhibit feedback from the customer
process loop-backs indicate churn--if you're re-prioritizing, re-checking, re-designing, re-doing, it's waste!

Reducing cycle time

balance the workload
minimize the items in process
minimize the size of work items
release regularly
limit work to capacity
use pull scheduling

Lean capitalizes on everyone's brainpower

Lean can only be realized when there is true respect for people in the workplace. At Boeing in 1988, the 777 project started with the premise of "working together"--and this fundamental respect for people ended up creating a work environment that shares many attributes with Toyota's lean process.
Deming wrote about how to use people's full potential in the workplace: "appreciation for a system (synergy of parts), knowledge about variation (problems come from the system itself), theory of knowledge (Plan Do Check Act), psychology (skill, pride, expertise, confidence, cooperation)".
Also see Deming's 14 points to increase quality.
Deming said that a company's purpose is to create products that please the customer so much that they'll keep buying more products--that is, to make a sustainable system, focused on long-term relationships
In a lean organization, problems aren't recurrent--they aren't systematic--because as soon as a problem is detected as systematic, the system is changed
"standards are viewed as the current best way to do a job, so they are always followed"--anyone who finds a better way is expected to change the standard documentation

industrial tourism

2009-08-14T00:55:00.000-07:00

A mentor of mine once said that insanity comes from isolation--that without close connections to people outside ourselves, we miss out on reality checks, and start doing things that are crazy, just because in our particular situation it seems to make sense. I think this insanity arises at both a personal and group level. I think the companies that encourage employees to reach out and network with other professionals end up finding more ideas and integrating more successful ways of working.

One means of networking I hadn't heard of before I came to France was first introduced to me by my colleague, Olivier--"tourisme industriel", or industrial tourism, a year ago, as a way to accelerate learning and improve the team's experience. Just this past week we had two "tourists" come in to observe our dev team--and while they didn't have a lot of experience with Agility, it was refreshing to have a new pair of eyes on our process--their questions came much more freely than an intern's or a new team member's, I believe, since they weren't expected to integrate these practices--they were simply here to find out if it made sense for them. I'd be really interested in trying this back in the States on a long-term basis, but the companies I'm familiar with would likely be too concerned about intellectual property to try it. Because of the questions from the tourists, we took a few minutes yesterday to do a special retrospective on whether we should change anything in our process. The tourists noticed that our connection with the XP client was excellent, that our adhesion to the Pomodoro breaks was lacking, and that the idea of deploying to prod was valuable.... Well, no changes came out of this retrospective--we're going to just keep going with our half-hearted Pomodoros, because we think it makes sense in our particular situation ;)

the coach's customer

2009-08-05T04:03:00.000-07:00

Naresh Jain just sent out a pointer to this Business Efficacy eBook, and its 14 pages are well worth the read. The main take-home messages for me are:

In every coaching opportunity, find ways to deliver value to the recipient--otherwise, your changes will not stick around for long. As a coach, I'm constantly asking people around me to leave their comfort zone, to do things I believe are possible, but they don't. But if I can find their currency, this change will be something they value.
Each individual has different motivators, of course! Each person has different ways they like to be acknowledged. Tailor your interactions!
Timing is everything--we're shooting for specific goals and we need to reinforce good behaviors; the amount of effort or time we put in to this isn't important, it's the results!
The coach needs to stay focused until the recipient has made the new practice a habit, and will create opportunities to practice if necessary!
The coach needs to provide clear expectations.
We don't care about volume, breadth, utilization, effort, or percent done. We are focussed on a narrowly defined objective.
A coach encourages learning by asking questions more often than lecturing. Often the difficulty is in applying what we've learned to our daily habits. Ask the team/individuals about what's going on, or how principles might apply to specific behavior.

To capture this all in one phrase, I'd say the coach needs to help teammates succeed, in their own individual definition of success.

Pomodoro Technique Illustrated by Staffan Nötenberg

2009-08-04T02:29:00.000-07:00

In addition to Francesco Cirillo's book on the subject, Staffan Nötenberg adds experience and supporting research in the Pomodoro Technique Illustrated. Here are my favorite ideas:

Procrastination, forgetfulness, and being overwhelmed in our lives can be replaced by energized work
Our brains have a lot of natural rhythms and tendencies. There's a reason why sports stars have quirky game-day habits. Let's capitalize on our brain's natural strengths!
Follow a ritual for winding up the Pomodoro... it frees your mind for more important things. Capitalize on building good habits!
Our brains are not good at task switching, because we have limited "working memory"
Our brains are very good at finding associations. Many memory techniques teach us how to build those associations.
There are two ways to understand time: sequential vs duration. Sequential is more intuitive for children, and is less anxiety-prone for us adults
To get into flow, it's helpful to have the right environment: clear goals, sufficient challenge/interest, alertness, immediate feedback, and the sense of control.
Analysis paralysis is a symptom of having too many choices. If we limit our task selection to the beginning of each pomodoro, we don't lose time constantly rehashing what to do next.
The difference between a to-do item on an Activity Inventory and what's on the Today list is commitment. Maybe other people assign items for our to-do list, but when we do Pomodoro, it's our choice to schedule things for Today, and it's our goal to get those items done...and our satisfaction to succeed. It's critical that the commitment is realistic!
Each Pomodoro day has the following stages: planning, tracking (something, each pomodoro), recording (consolidate to Records Sheet), processing (analyze the data), visualizing (retrospective).
The key to memory is rehearsal. If you want to remember something, review it now, a day later, a week later, a month later, and then again 3 months later. This will strengthen the neural pathways so the info is easy to reach. As part of Staffan's daily retrospective, he draws a mind map of what he learned during his primary task of the day.
There's something about commitment that adds fire to our work. Use this catalyst by planning the day with a Today list, and use a Now List at the beginning of each Pomodoro to keep focused.
The daily retrospective is important to keep us learning.
Interruptions occur. Negotiate to keep them from interrupting your flow. If it's really urgent, you'll have to void your pomodoro. If you do anything that is not on to your "Now List", the Pomodoro is void (unless it didn't interrupt your flow and it took less than 10 seconds).
External Interruption Negotiation--inform the other party you're in the middle of a pomodoro, and will be done in X minutes; ask if you can get back to them then; add it to your Today list or Activity Inventory
Tracking: Staffan records interruptions (' for internal, - for external), unplanned items (U), estimation error (boxes for initial estimate, circles for re-estimates, and triangles for 2nd re-estimates)

Breaks

At a minimum, each break begins with getting away from the active task--i.e., standing up from my desk!
Giving ourselves regular breaks brings multiple benefits: ability to reprioritizate tasks, tendency to view the larger context and discover new associations, and clear delineation between work and rest.
Flow is incompatible with a perspective of the big picture. So we need something to wake us up, regularly, to ensure we're still on the right track.
Much of the discipline in Pomodoro is about setting up artificial rewards... I get a 5-min break if I work for 25, I get an X on my sheet if I don't get distracted, etc.
Short breaks give our brains a pause from a bombardment of stimulus. Get away from machines and texts! Otherwise you're likely to develop "attention deficit trait"--i.e., you're stealing focus away from the next pomodoro.
Breaks are critical to get us out of flow-mind, and allow us to switch to overview mind--where we're capable of making changes to priority/schedule/plans. It may be hard to be disciplined to stop when the bell goes off, but if instead we realize this is a wake-up call, it's no longer something being imposed upon us... it's our choice to be able to reevaluate where we should be going

Pomodoro for teams

2009-07-17T01:43:00.000-07:00

So our XP team has been using some twist of the Pomodoro technique for about a month now. I actually haven't found anything significant about using Pomodoros in a team, so I'm going to share what we're doing, and what problems we're having, to see if you have any ideas.

We use "one pomodoro to rule them all", which means one timer for the whole team. I've read this is an anti-pattern, but I don't see a compelling reason to use more than one pomodoro. We see a lot of advantages in having one pomodoro... everyone has a pause at the same time, so pair swapping is easier, team meetings are easier, etc. If someone's pomodoro is interrupted, someone decides not to participate in this pomodoro ("check-out"), they just wait until the next pomodoro starts to rejoin the synchronized timer. As a team, it seems like we're happy to use Pomodoros--our team communication is up, our productivity, our focus, our check-in/out is all better.

Our biggest problem with Pomodoro right now is in sticking to the 25 minute window--when the timer rings, inevitably someone stops, but most of the team keeps working for another 2 or 4 or 5 minutes. When the 5-minute pause is over, 3 or 4 people approach the story board and start goading others into joining them. This can easily make a 5 minute pause take 10 minutes, at which point we have a mini-standup meeting to verify that we're not blocked or overbudget on any story cards, that we're progressing well, and to verify no one needs extra help.

We've talked, as a team, about why people aren't taking breaks, why people are late to show up after the break, etc. Maybe this pain is why it's considered bad form to use "one pomodoro to rule them all". If we keep just one timer, though, what else could we do to fix our tardiness?

call for nominations--Agile Alliance's Gordon Pask Award

2009-07-13T10:11:00.000-07:00

The Gordon Pask Award

The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the award committee, people others in the field should emulate. In order that people might emulate them, the Agile Alliance will fund each recipient's travel to two different suitable conferences on two different continents. In order to grow the next generation of Agile thought leaders, we give the award to people who have not yet become conference speaking regulars, in part because they have not yet developed a widespread reputation as a top practitioner.

Who is Your Mentor?

We need your help to identify the next two Gordon Pask Award winners. Please send your nominations to pask-nominations@agilealliance.org, including the nominee's name, email address and a short summary of your reasons for making the nomination, limited to 200 words.

In the spirit of Gordon Pask's work (see below), we expect you to nominate someone you've learned from directly, face-to-face. You might also consider asking for additional people to add their names to your nomination. More names don't necessarily carry more weight, but they do give us more people to ask about the nominee. Previous winners can be found at the Agile Alliance's site http://www.agilealliance.org/show/1656. Award founder Brian Marick comments that the selection process is always difficult: "We always worried a lot that it would feel arbitrary... I’ve gotten complaints that it’s too much of a programming award and not enough of a management award and that could well be true." There are always many qualified nominees, who are ruled out when the committee asks “Does this person actually need our help?”

We will accept nominations until August 1, 2009.

About the Gordon Pask Award

Laurent Bossavit, a 2006 recipient, says "one of the more appealing traits of the agile community [is] that it provides room for new voices to be heard and to offer original contributions". This is a community that fully embraces the notion that through face-to-face conversation comes enhanced understanding... a community that believes that thoughtful critics and new enthusiasts alike have something to offer. This emphasis on discourse is partially inspired by the work of Gordon Pask and other cyberneticians, who practically "had no effect. Eventually they retired, or died, and that was kind of the end of it. The first wave of people failed to build up the next wave," according to Brian Marick. The Agile Alliance's support of this award shows a strong commitment to nurture growth and discovery in the agile arena, and to further emphasize its significance, currently it is the "only award that the Agile community gives," says James Shore (2005 recipient).

Agility is a Social Phenomenon

This is a community of artisans, constantly trying to hone their skills by taking notes from one another. Bossavit says "I benefited a lot from the writings of the 'official' founders of Agile, many of them among the original signatories of the Manifesto... [but I] couldn't have learned about XP, Scrum and all that solely from reading books or articles. Rather, my understanding grew from the opportunity to participate, interactively, in several communities. These included on-line communities such as Ward Cunningham's Wiki and the XP mailing list, and real-life gatherings such as the european XP200x conference, the various XP Days, and so on. I have a huge debt to Jerry Weinberg... for fostering a community of people passionate about 'peopleware', about the human, sociological, psychological aspects of software."

Agilists are finding better ways to work, to learn, and to teach. 2005 recipient James Shore says he learns by "trying things and seeing if they work", but that's not all. He gained a lot of insight by working with his local Agile User's group. He says, "I'd bring in my problems and we’d talk about them and I’d say, 'That can’t possibly work' and I would go away and try it and come back and say, 'Well, you know… that worked. Here’s what I did and now here’s the new problem I’m having,' [something] I wish more people would do." Regarding learning by doing, he goes on to say that, "training some times works... you can pick this stuff up from books... [but] following a leader who has done it before; having them work with you directly is by far the most effective way of getting it in to place quickly". Instead of training sessions in lecture format, 2005 winner J.B. Rainsberger says that he "tells people stories... which helps them understand". If you go to any of the agile conferences, you'll find games, workshops, debates, and other engaging, interactive formats focused on improving communication. Not only are the user groups and conferences lively. "Agile is bringing back the freedom, creativity and innovation back to software development. It is making life easy and enjoyable for software craftsmen. And I'm glad to be a part of such a movement," says 2007 winner Naresh Jain.

Gordon Pask--Improved Understanding through Discourse

The Gordon Pask Award embeds a special message for the Agile Community. "Lots of big names are projecting a very dogmatic and rigid view about Agile. In my experience Agile is nothing on those lines," says Naresh Jain. The problem with mass-broadcasts from "big names", from a Gordon Pask perspective, is that we lose out on the collaborative learning. It's not to say that a rigid view of Agility is incorrect. James Shore says: "we can’t just say we won’t do that piece of Agile. [Instead of asking] "How are we going to solve that problem in a different way?", I see people saying, 'That’s hard. We’re just not going to worry about that piece of it.'" He clarifies that newcomers would be "better served by... seeking excellence than trying to fit in." Trying to fit in by following the letter of the law will not give us the gains in productivity promised by Agile. "The big wins are not in doing work in two-week Sprints. The big wins are increasing your communication, working simultaneously, because simultaneous phases are also a way of improving that communication so that you don’t have a throw-it-over-the-wall mentality."

Kent Beck talks about self-similarity in nature--that is, design patterns that work well, often are replicated in various sizes and environments. The fact that communication helps us improve our effectiveness on the job, as well as in the Agile community, is a self-similar pattern mastered by award recipient Kenji Hiranabe. He says that it was not he who won the award in 2008, but it was the strength of the community in Japan that brought the award to him. This obvious valuing of community before self is also repeated in their conference marketing: "we prepared 'Pair discount' pricing and strongly recommended the attendees to come with their boss or clients. The result was 75% of them came in pairs! I believe it is a sign that engineers, managers, and clients have started talking to one another to make this software development world better... Along the way of introducing Agile to Japan, they came and formed a good community."

Now it's your turn. Nominate someone that has helped you out... better yet, collaborate with a few colleagues, face to face, to discover who to nominate. It takes less time than reading this article!

Drexler-Sibbet Team Performance Model

2009-07-09T02:53:00.000-07:00

Thanks to George Dinwiddie for the pointer to this image (actually, I don't know the etiquette here in terms of referencing an image from another site...), but anyway, this model can help a team gell. Read more at George's blog.

software has no intrinsic value

2009-07-09T02:01:00.000-07:00

After Kent Beck's musings on how to find paying customers for his work on JUnitMax, and on capital efficiency, I started wondering, well, if we won't buy from Beck, who will we buy from? Maybe no one--in fact, recently, I've stopped buying software. It comes embedded in the gadgets I buy, or it comes OEM with my new PC, or is available on a free CD that accompanied a gadget I just paid for. Even with all this "free" software, the first thing I do with a new toy is try to make it work with my computer without installing any of the bundled software at all... and speaking of minimizing my need for software--the first thing I do with a new PC is uninstall as much as I can get away with. Why do I uninstall? To me, each unused application is waste, risk, in short, rubbish--so I clean up aggressively. It's not that I don't have any software at all. Every once in a while I do need software that wasn't given to me, so I'll evaluate a few freebies online, and ultimately choose some product that does the job well enough.

Note the change in focus here--I'm talking about getting a job done. There's no intrinsic value in the software itself--but there is potential to accomplish a task, and therein lies its value. Yet it's rare that my needs correspond exactly with the software's behavior. So if it doesn't do exactly what I need, and there's a free one that is just about as inadequate, why not go for the free option?

I'm not alone. The prevalence of free web software (from list serves to social networking to banking), plus the thousands of open and closed source software products that are available free download, suggest that there may not be much time left for people that are still trying to sell their software.

Now for the irony--I've been paid for years as a 'software developer' for in-house applications, and there are lots of other workers getting paid to contribute to free software. Where's the money coming from? Where's the value? As I've already said, it's not the software. The value comes from getting the job done better. The less software involved, the better (per James Shore's spag code debt model). I think, then, my job isn't to write software. My job is to solve business problems... to figure out what the business really needs, to deliver value, with as little technology/effort as possible.

Greiner Curve--organizational growth challenges

2009-07-01T00:39:00.000-07:00

As organizations grow, they need different kinds of leadership. The Greiner Curve can help you anticipate these changes:

Growth through creativity --> leadership crisis (small team, informal leadership)
Growth trhough direction --> autonomy crisis (single level of management)
Growth through delegation --> control crisis (middle managers)
Growth through coordination --> red tape crisis (executive managers)
Growth through collaboration --> growth crisis (matrix organizations, partnerships with internal groups)
Growth through alliances

Porter's Five Forces

2009-06-30T07:37:00.000-07:00

Another interesting idea from MindTools.com:

In business, power comes from these five forces.

Supplier power: more suppliers, less power for each one
Threat of new entry: if it's a profitable business, someone is likely to jump in to compete
Buyer power: big buyers can dictate terms (think Wallmart forcing Coke to give them a discount 10% lower than any other buyer, or Amazon taking 70% of newspaper revenues)
Threat of substitution: if there's another way to meet the customer need, maybe the customer will use that solution instead
Competitive rivalry: competitors tend to drive down the price to the "marginal cost of production"

Geert Hofstede cultural dimensions

2009-06-30T02:25:00.000-07:00

While stereotyping can be misleading, sometimes it's practical. I just learned about Geert Hofstede's cultural dimensions study, started in the 1970s, where he categorized different cultural values. I was surprised, for instance, to see that the French have a lower rating for gender roles than Americans, but then again, my house is in the Mount Airy section of Philadelphia, a progressive haven that is not at all typical of the U.S. Still, this study rates dozens of countries along four or five axes, and may help us understand what is more valuable to people in different cultures:

PD: hierarchal vs cooperative leadership/power
IDV: individual vs community
MAS: clear, different gender roles vs gender equality
UAI: avoid uncertainty, like formal structure vs informal and tolerant of risk
LTO: long-term orientation, value family and education vs valuing shorter feedback and innovation

capitalize on learning styles to communicate effectively

2009-06-29T02:32:00.000-07:00

When you're planning a meeting, retrospective, discussion, or training session, try to incorporate activities for each topic that cater to people that learn in different ways. While there may not be a scientific basis for the following categories, considering them can make your presentation more likely to engage more of the audience. The following are the Felder/Silverman learning style axes:


Sensory    <-->  Intuitive
Visual     <-->  Verbal
Active     <-->  Reflective
Sequential <-->  Global

These learning styles show a preference for:
Sensory: feeling/detail
Intuitive: theory
Visual: pictures
Verbal: words
Active: experiments
Reflective: plan
Sequential: details or steps used to build the big picture
Global: use the big picture to figure out where the steps should fit

Key characteristics of a performing team

2009-06-19T00:12:00.000-07:00

Thanks to Gary Derbier for this concise summary... a performing team has these characteristics:

everyone takes care of themselves
everyone fully connects with each other
everyone unanimously agrees on one objective and how to achieve it... this unanimous agreement should be so strong that every member of the team believes that this objective is the best real option, right now for reaching both our individual and group goals
everyone expects that perfecting the team will perfect the product

Once a person has been part of a performing team, it is hard to enjoy team work without it.

Herzberg Motivation-Hygiene Theory

2009-06-18T02:08:00.000-07:00

Today I read a bit about the the Herzberg Motivation-Hygiene Theory, which in a nutshell, expresses that there are two levels of needs for employees. If we want people to stick around, we have to prevent job dissatisfaction by meeting:

their basic needs (keep the work environment sane, fair, with competitive benefits)
their motivational needs (job satisfaction comes from challenge, recognition, autonomy, interesting work, and room for growth)

I used to say that a good manager does two things: gives employees autonomy (read: room to make mistakes), and challenges employees to grow. I'm finding out there are some prerequisites to this, and am trying to learn how to verbalize them.

deleting your way to success

2009-06-15T07:39:00.000-07:00

Every once in a while, we get a story card that allows us to simplify a requirement or interface, and we get to "delete our way to success"... that is, we end up removing more code than we add, and maybe we don't end up adding any code at all. Today that's what my pair and I did for the first half of our card, and it's so liberating. We don't need to think much about code rot, tests, or any of it... just remove and verify we didn't break something else. Quick win!!!
Thanks to my colleague from Philly, Nolan, for coining this phrase!

effective delegation

2009-06-15T04:36:00.000-07:00

Esther Derby's when to stand back, when to step in touches upon delegation. I'd like to comment on that, by merging some of what www.mindtools.com had to say about it. When we delegate, it's necessary to:

describe the need/ultimate goal
encourage sign-up for responsibility
define authority depending on skills, how critical success is, and whether there's room to clean up any mistakes--should this person act independently, review plans with you, or review intermediate outputs before proceeding?
once you've given out authority, you must hold back, even if mistakes are about to be made... being given the room to make mistakes is how we learn

my favorite lines from Derby/Larsen's Agile Retrospectives

2009-06-12T05:06:00.000-07:00

A retrospective needs to happen in several phases:

setting the stage (why are we here, time line, and check-in)
data collection (put all the facts in front of the whole team)
interpretation (as a group, look for patterns)
decisions (propose options, then decide on what can be done by whom, when, and define acceptance criteria for the work)
closure (ensure tasks have been assigned, thank participants)

The authors have lots of hints on how to facilitate group discussion (now we'll see if I can do all this in French):

ask the group to build working agreements, and then just remind them to follow their own rules when necessary
at every meeting, get every person to speak in the first 5 minutes
check your assumptions... ask people what they think! pose clarifying questions to make sure you understand!
to help everyone have a voice, incorporate small group work in the meeting
retrospectives are for creative thinking--so do use innovative meeting formats
when the facilitator speaks, this often stops group discussion
when the group is stuck, ask them questions, e.g. about when they saw a similar problem in the past
when things get heated, try asking "what is going on?/what just happened?"
use a change in venue when the team bombs an iteration

They also present lots of group exercises, that I won't repeat here... I keep the book handy for retrospective preparation. These are a few general hints for leading group activities:

most people can't absorb multi-step instructions
debrief every activity
after giving instructions, ask for questions
shuffle time--it takes a few minutes every time we switch tasks in a meeting to get everyone on board with the next meeting--it could be 15 percent of the time!