the coach's customer

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

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

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

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

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

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

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