Agile Learning Labs

Heading to Agile Open Northwest

Chris and I made quite a few new agile friends at a private consultants retreat we attended back in November at the Sylvia Beach Hotel in Newport, OR, and a lot of the same people will be attending Agile Open Northwest on Feb 10 & 11, as will we.

I say new friends, because as a native Portlander, I've already got a lot of old friends in the area. I'll be getting into town a week early for a first planning session for a new literary festival, and to have time to visit them all, and will be working most days out of my brother's coffee house, Ristretto Roasters, so let me know if you want to meet for an excellent cup of coffee to talk about anything from Agile to the Future of New (and Old) Media to the '76 Trailblazers (I was there for the victory parade, if that dates me).

Jim Shore does a good job of describing what an open space is like and why you should think about going to this one.

Track Velocity, Not Time Spent on Tasks

A member of a new agile team asked the Scrum Development list how to keep track of the actual time engineers spend on tasks, and how this relates to the agile concept of velocity. Velocity is the agile metric for tracking how fast the team is completing features, and thus how long it will take to complete a project. The group's opinion was that tracking time spent isn't necessary or useful.

I'm currently working with a client that is struggling with this same issue. After reading some books, they started down the path of estimating stories using points, but then breaking them down into tasks that are estimated in hours. They then wanted to use burndown charts, but became confused about whether they should burn hours or points. They also weren't sure if they should have a single burndown for the whole release, of a series of burndown charts, one for each sprint.

My advice is to only estimate, track, and chart stories. Completed stories are the unit of delivered value, and the only thing that people outside of the team care about. If the team's stories seem too big for this to be workable, the solution is smaller stories, not another level of tracking overhead.

Most folks on the Scrum Development list, including Ron Jeffries and George Dinwiddie, seem to agree with this approach. It was a good discussion thread and I recommend reading it. You might also want to read the article I wrote for InfoQ about the discussion, or this one about Ron Jeffries' thoughts on burning stories not tasks.

Cheers,

Chris

Bees, Butterflies and Ultralight Backpacking: Thoughts on Creating Open Space for the Orlando Scrum Gathering

We met Ainsley Nies for corned beef hash and crab cakes at Peter's in Millbrae this morning. It was our second planning session for the Orlando Scrum Gathering in March, where Chris and Ainsley have been invited to host an Open Space for 300 agile souls, based on the strength of their performance as organizers and facilitators of last year's Agile Open California. I'm helping--well, mostly I'm sitting at Ainsley's feet in rapt attention, soaking up all I can about Open Space Technology, which I find fascinating.

A thought occurred to me while we were drafting the description for the conference website: how many structural parallels there are between OST and Scrum. Both have ceremonies. Scrum has roles, while OST participants may be described as "bees," "butterflies" and in some versions as "groundhogs." Scrum has artifacts, eg, the product backlog, the sprint backlog and the burndown chart. And OST has the Marketplace. Structurally, both are lean frameworks--they put me in mind of ultralight backpacking tents made with light, flexible but strong kevlar poles.

Ainsley and I had an interesting side discussion about the meaning of the word framework: We both think of a framework as providing strength and creating and holding space (like a tent), but it's a tricky word to use in a piece of writing, because many think of a framework as being rigid and restrictive.

Upcoming Conferences: STPCon & SD West

We've just finished submitting our slide decks for two upcoming conferences: SD West 2009 and Software Test & Performance (STPCon) Spring 2009. Both take place right here in our neighborhood (we'd say back yard but then you might expect barbecue).

SD West happens March 9-13th at the Santa Clara Convention Center, and includes over 100 speakers, including TMI's own Chris Sims, who will be delivering one of his most popular workshops, Why do Agile Projects Succeed (or Fail)?. The same workshop was a big hit when offered as a Birds-of-a-Feather session at last year's Dr. Dobbs Architecture & Design World. Check out Chris' write up of it here.

One keynote address that looks particularly juicy is the debate on Agile v. Traditional. Not the first time this fight conversation has taken place, but what makes it special is that it pits IBM v. IBM, as Big Blue is fielding both debaters: "Practice Leader of Agile Development" Scott Ambler will square off against "Rational Evangelist" Terry Quatrani.

The conference organizers have also promised more "fun" events this year, including the Jolt Awards, aka "the 'Oscars' of our industry." We definitely think the award for Coolest Job Title At a Fortune 500 should go to Ms.Quatrani, even if she is an old school waterfaller.

STPCon follows hot on the heels of SD West, running from March 31st through April 2nd, in San Mateo. Chris will be leading two sessions: The Makings of a QA Leader and The Most Effective Ways to Improve Software Quality. Chris delivered the latter as a workshop at STPCon Fall in Boston last year, where the group put "Proper Test Planning" at the top of their list, which you can read in full righ here.

Planning to go to either conference? Let us know!

PMI Workshop: The Most Effective Tools & Techniques for Project Managers

Chris recently had the pleasure of facilitating a lunchtime workshop as part of PMI Silicon Valley and SDForum's Tools & Techniques series. A group of 23 Project Managers turned out to discuss "The Most Effective Tools & Techniques For Project Managers" using the Group Wisdom Without Groupthink (GWG) structured brainstorming method.

GWG begins with a round-robin survey of the entire group to elicit ideas, which are posted on the wall. Next, participants vote for the items they think most important and the results are arranged in tiers. Here are the results:

Tier 1: 11-15 votes

Web conference tools

Well-defined metrics

Dashboards

Scope management

Project meeting w/agenda

Proactive risk management

Brainstorming session

Project stage gate reviews w/all key sponsors

Face-to-face kick-off

Fist-of-five

Tier 2: 6-10 votes

Management by walking around

Status reports

Repeatable release process

MS Excel

Sharepoint

Resource management

Stakeholder management

Tier 3: 1-5 votes

Tools for change management

Resource allocation matrix (RAM)

Portfolio management

Acknowledge success

Post-meeting buffer

Work breakdown

Social collaboration

Effective open-ended questions

Process workflow w/visio

Requirements trackability

Setting team ground rules

Weekly status for subject matter experts (SMEs)

Short-term goals

MS Project

Adaptive project management

Project dream list

Case complete

Version control tools

Quindi

Managing up

Determine costs of being late

Global collaboration - video

Tier 4: 0 votes

User contextual inquiries

Preview of materials

Groove

Going down a rat hole

Skype

Scrum meetings

Group Wisdom Without Groupthink works well with all kinds of groups, both technical and non, but clearly the project managers had a special affinity for the exercise, as participants rated it an average of 4.75 out of five, leaving comments like, "a very useful technique that I can implement right away."

Here is a similar workshop Chris ran on the topic of What Makes Agile Projects Succeed (or fail)? at Agile Open California 2008.

January Support Group: Sudden Survey

Last night's meeting of the Engineering Managers' Support Group at the British Bankers' Club was an intimate affair, as inclement weather kept a lot of members home. Those who did brave the rain thoroughly enjoyed the atmosphere, drinks and pub food--the engineering of the Tuna Nicoise, pictured, drew quite a bit of praise.

Chris led the group through a lively discussion on the topic of the economy and how it has affected our companies, jump-started with a game known as the Sudden Survey (hat tip to the thiagi newsletter).

What is a Sudden Survey? It's a lightning-fast exercise in which teams have mere minutes to gather information from the whole group, analyze it, and prepare a presentation. We had just enough participants for two teams, and as we happened  to have an even number of men and women, we decided to make it a battle of the sexes. Here are the questions the teams addressed:

• How has the economy affected staffing at your company?
• What other steps has your company taken in response to the recession?
• What lessons from the past will be valuable during this downturn?
• Has the recession affected how you manage your team? In what ways?

Both teams made their presentation "deadlines" and performed admirably; the men nabbed the flip chart for their presentation, but the women dealt with the resource deficit by pantomiming theirs, after which it was universally agreed that pantomime beats PowerPoint hands down.

The survey results held a couple of surprises: first, of the six companies represented by the participants, only one had actually experienced layoffs. A secondary commonality that emerged was an atmosphere of belt-tightening that included conserving resources, but also conserving intellectual capital by focusing and sharpening business and marketing plans. After the survey, several participants said they felt reassured, and that they would henceforth worry a bit less.

The Sudden Survey seems like it could be a useful tool, especially for groups where the participants don't already know one-another's opinions and backgrounds. I can see a planning body, for instance, using it at the beginning of an important meeting to identify assumptions, determine experience levels, or simply take the temperature of the room.

Win a JetBrains license at tomorrow night's support group meetup

JetBrains has graciously donated two software licenses to be raffled off at tomorrow night's meeting of the Engineering Manager's Support Group, so come on out if you're feeling lucky. Winners can choose from several JetBrains offerings, including IntelliJ and ReSharper. These products retail in the $250-$350 range for individual licenses.

We'll be meeting at the British Bankers' Club in Menlo Park tomorrow evening, Thursday, January 21st, at 6:30 pm. The event is free with a cash bar and full menu available. You can RSVP here.

Socialize, don't evangelize

Proponents of agile, in my experience, can be quite passionate, and it can be argued that their infectious enthusiasm is what is making agile so "hot" these days. These agile evangelicals have spread practices, and an ethos, that have made a lot of developers' lives a lot happier, and bless them for it.

I was just reading Robert Dempsey's report on a Rally Software webinar called Agile in Turbulent Times, in which he listed the key takeaways from an experience report on HomeAway's path to agile adoption. One of their big lessons learned was: "Socialize, don't evangelize."

I take it this means not that evangelism is bad, but that it isn't enough. It isn't enough to obtain buy-in at the start of the adoption process, or to hold a two or three day training and walk away; people new to agile need resources and context to assist in making what amounts to a huge cultural change. Just the other day at the SD Forum's Egineering Leadership Sig's monthly event, I had a conversation with an obviously brilliant young software architect who said he didn't like his first brush with agile one bit. When I asked why, he cited the pain of "the hour-long meetings every morning." Yikes! Hopefully these weren't stand-up meetings. That's as good an example I can think of to illustrate how poor socialization around agile practices can lead companies, teams and individuals to reject agile like a bad kidney.

Too many agile adopters slide into what I will call the Romantic Comedy Model--they fall in love with agile, and then expect to live happily ever after just like that. It's useful to remember that doing agile well is no less a challenge that building and sustaining a good marriage.

The rest of the gleanings from HomeAway's experience are just as interesting, and the whole post is well worth a read.

Pair Programming vs. Code Review

Pair programming and code review are each practices that improve the quality of software, as well as promote knowledge sharing. When the Agile vs. Lean, XP vs. Scrum, and vi vs. Emacs debates get slow, developers have been known to debate the merits of pair programming vs. code review.

I have worked with teams that used each of these practices to great advantage, as well as teams that used the both. Not surprisingly, the teams that used both practices had the cleanest code and the fewest problems with customer-reported bugs.

Theodore Nguyen-Cao described code reviewers as chickens, and paired programmers as pigs. I found the analogy interesting, and so I wrote this article for InfoQ.

Cheers,

Chris

Code Monkey Like You!

If you haven't heard of Jonathan Coulton yet, now you have. He's clever, geeky, and his music lends itself to great videos. This one is 'Code Monkey'.

As a special bonus, here is 'Mandelbrot Set'.