Friday, July 17, 2009

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?

Monday, July 13, 2009

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!



Thursday, July 9, 2009

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.

Wednesday, July 1, 2009

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