Debunking Some Start-up & Software Myths

I saw a great article by Tim Ferriss quoting Rob Mee of Pivotal Labs thanks to someone I follow on Twitter, and thought I should mention it here. It's rare that I read an article on a topic like this and agree with it 100%, but it happened in this case. I encourage you to check out the post itself, but in order to whet your appetite, here are the 7 Myths he describes:

1. You have to hire "ninjas."
2. Programmers need to work in quiet, without interruption.
3. Start-ups run hot, so we're just gonna have to burn everyone out.
4. Looming deadlines necessitate shortcuts.
5. Developers should take ownership of their code.
6. You need a quirky hiring process.
7. Specialization is essential.

As I say, it's a very good read and excellent food for thought!

Agile 101: A Workshop

It's been ages since I posted anything here, but now seems like the perfect time to end that drought. Yesterday, I spent the morning and part of the afternoon at a large local company that wanted to get an introduction to Agile. Since one of the people involved with that initiative is a friend and former co-worker of mine, she put out the call to AgileMan and I was more than happy to answer it!

To accommodate the request, I designed a two-part session that lasted 4 hours. There were 22 attendees, along with two colleagues of mine (my wife, Vicki, and another friend). The first half was a presentation called "Agile 101: An Introduction to Agile", in which I did my best to describe what Agile is, and what it isn't. I started off with a very high level definition of Agile (from Wikipedia) in order to provide at least a notion of what it is, and then talked about why we decided to "go Agile" at the work place where I gained the AgileMan moniker.

Next, in order to put some more flesh on the initial definition of Agile, I took the approach of looking at Agile from several different perspectives, specifically trying to capture what people often assume Agile is when they first hear about it:

• a response to the historical high failure rate of software projects
• a loosely-knit collection of lightweight development approaches
• a way of doing iterative programming
• a mitigation strategy against ever-changing customer requirements
• a commitment to quality and customer satisfaction
• the latest buzzword, fad or silver bullet

Taking that path into Agile allowed me to acknowledge what I suspected were some of the impressions already floating around in the minds of the attendees, and it seemed - based on some of the vigourous nods I saw - as if I hit some nails on the head.

I then spent a consider amount of time going through some of the more common principles and practices in the Agile community, such as:

• Inspect & Adapt
• Empower Teams
• Size Relatively
• Co-locate teams
• Work at a sustainable pace
• Don't compromise quality
• Automate your testing

and several others. There were lots of questions during this portion, as people began to wrap their heads around just how different an Agile work place is from a traditional one. Most of the questions were asked in an inquisitive, interested manner, but of course there was the odd individual who made it perfectly clear by his wording that he thought this was all rubbish. No surprise there.

I had to go at a brisk pace through the presentation because we had a full-on activity to do after the break, and that unfortunately meant that I couldn't spend as long on some of the questions as I'd have liked. By this point in my career, it's gotten very easy to tell the difference between a back-and-forth that may eventually lead to a resolution and one where the other person has already made up his or her mind on the subject. I tried to keep the former type going while cutting the latter ones off, but I'm sure I did an imperfect job at that in the final analysis.

After a 15-minute break - during which time I was inundated with more questions, which is always a good sign - we began the hands-on portion of the workshop. The 22 attendees were split into 3 groups of about 7 people each, and each group got one of myself, Vicki or our other guest as their Product Owner. All 3 groups were tasked with "building" (on paper only) the Meal Planner application, based on a visionary set of requirements (lacking in specificity, by design). The deliverables for each feature included screen design/diagrams, test conditions and help texts, and the teams were given four 20-minute iterations in which to do as much of it as they could.

Interestingly, all 3 groups started off working in smaller groups - screen UI vs testing vs help - only to realize, by the end of the first iteration, that they hadn't known enough about what their teammates were doing to be able to do an effective job on their stuff! We had short planning sessions to start each iteration, followed by the doing, then a hand-waving "demo" to the Product Owner and a quick Retrospective before beginning the next iteration. This exercise worked extremely well, as it provided everyone with a taste of what Agile is like: short cycles, lots of adaptation, emerging requirements, high degree of collaboration, etc. As far as I could tell, everyone in the room was fully engaged in the activity, and there was a palpably-high level of energy present for those eighty minutes!

After the 4th iteration, each team briefly presented its "application" to the others, along with what they'd learned in their mini-Retros. Then we wrapped things up, at which time several attendees offered quick testimonials about what they'd learned and how much they'd enjoyed themselves, which was very gratifying to me and my two helpers.

As I usually do in workshops, I handed out a very short, 1-page survey to encourage the attendees to provide feedback on the session. I asked them to rate three things:

• how effective the presentation portion was at introducing them to Agile
• how effective the hands-on activity was at introducing them to Agile
• how effective the Product Owner had been in helping them understand Agile

The results were extremely good, as we received average scores of 8.4, 9.1 and 9.2 (all out of 10), respectively! Those are some of the best numbers I've ever gotten on a workshop! There were also a couple of comments along the lines of "Best workshop I've ever attended", which obviously makes me day!

It still remains to be seen whether I'll be asked to do any more Agile consulting for this particular company, but the signs are promising at this point. Several topics were mentioned as potential areas they'd like help with, including estimation skills, breaking large features up to fit into short iterations, Retrospective facilitation and Product Owner-type training or consultation.

All in all, it was a great day and it took me back to my initial two years as AgileMan!

Agile Metrics

I'm only partway through the video (it's about 2 hrs long) but so far I'm really enjoying and agreeing with what Dave Nicolette had to say about Agile Metrics at Agile 2009. If this is a topic that's of interest to you - especially if you're a Project Manager! - then I recommend you give this video a watch.

Is Agile Just A Placebo?

A good friend of mine is a big fan of Linda Rising, and so anytime Ms. Rising's name pops up, I tend to take notice. This 15-minute video of her speaking about the Placebo Effect is quite interesting and typical of her style.

The First Retrospective

Last week I spent Thursday morning facilitating a project Retrospective for a local development group who'd never held a Retro before. As part of my engagement, I was also asked to do some "training the trainers" in the sense of working with a couple of people there who were interested in taking on the facilitation role in the future. The thinking on the part of the executive sponsor was that they wanted to bring an expert in for an early Retrospective (or more) but not be reliant on him forever, which is a sentiment that I totally agree with and was happy to support.

The preparation for the session started several days beforehand, as I e-mailed questions to the sponsor and also had a phone conversation with him. I'd sketched out a possible structure for the Retro prior to that, and then the two of us hammered out the final details during that call. One of the most important factors we talked about was duration, which ultimately ended up being 2.5 hours. I would have loved to have scheduled it for longer since it was covering an entire 6- or 7-month project. However, the flip side of the coin was that this was going to be everyone's first Retro, and there was concern that being subjected to a full-day session first time out would be too much, too soon. That led to the decision for a meeting running from 8:30 to 11:00 a.m.

When I got on-site Thursday morning, I met with the future-facilitators for an hour and described what would be happening. The three of us got the room ready by putting up some large sticky notes (a mostly-blank timeline, ground rules and the agenda) and I provided a few thoughts on what I believe the facilitator's role to entail:

• keeping the group focused on events and learning, not on people and blaming
• warming up 'cold' rooms and cooling down 'hot' ones
• nipping any personal attacks in the bud
• avoiding ruts in the proceedings by keeping things moving forward
• making each of the attendees feel comfortable with the process itself

I'd planned a warm-up activity that went well (got people talking, generated some light-hearted laughter, felt like fun) and then we drove headfirst into the agenda.

Most of the attendees were slow to open up very much, as you'd expect from people in their first Retrospective. Nothing too contentious came out until more than halfway through, and even then it was offered up fairly tentatively. By the 2.5-hour mark, though, things were getting much more interesting... just as time was up! As one of the trainee facilitators pointed out, it was all we could do to get several of the attendees out of the room even half an hour after it was over! And these were very busy folks, some of whom were missing other commitments in order to stay a little later and chat with us about what they`d just gone through. That sort of thing is really rewarding to see!

The results of the 1-page survey that I handed out at the end were very positive (scores averaged between 8.2 and 9.0 out of 10). In our 1-hour debrief after the session (half of which was chewed up by the hanger-on-ers!), the two trainees did a great job cleaning up the room (while I was waylaid with questions) and then talked about how interesting it had been for them. They were concerned about being able to do what I had done, but I assured them it was easier than it looked! In fact, the toughest part for me was that I was on my feet for nearly the entire two and a half hours, an amount of standing well beyond anything that I've done in the past several months. I'd had the presence of mind to bring a big bottle of water with me so I wouldn't get parched, and yet I didn't think to sit down for more than about 2 minutes over the course of the meeting!

I don't know yet whether or not I'll be invited back for additional work, but this first contract was very enjoyable, indeed. The participants were committed to the process and willing to open up in front of each other and a stranger, and you can't ask much more than that!

This Looks Like A Job For... AgileMan!

Later this week I'm scheduled to facilitate a Retrospective for a local development group. This will be their first ever Retro, and so they've decided to bring in an outside expert to lead it. I haven't done one in a while, but back in the heyday of my AgileMan stint I was facilitating about one per week. Of course, that was with people who I knew (to some degree or another) and this is with strangers... but I'm hoping it's like riding a bicycle, regardless of who makes the tires!

So in preparing for this engagement, I've been working with the executive sponsor to sort out the logistics for the event (what type of room, duration, number and makeup of attendees, etc) as well as to determine what kind of format might work best. Because it's a Retrospective for a recently-completed project that ran for nearly half a year, we're going to do a Timeline as our main source for gathering data. In an ideal world, a session covering this long a period of time would probably be a full day in length. However, since these folks have never been in one before, we opted for a shorter format (2.5 hours). Because of that, I want to get as much data out on the table as quickly as possible, and a Timeline seemed a good vehicle for that.

Once we've completed that activity and found a few hot spots (via a voting mechanism), then the plan is to use the Force Field Analysis process to uncover what forces have worked for and against whatever it is that we're discussing. From that I hope to be able to lead the team in agreeing on a few Action Items that can be applied on the next project to either weaken some of the opposing forces or strengthen the supporting ones.

It's not the most elaborate agenda I've ever set out for a Retrospective, but I'm trying to remain mindful of the fact that this is something new for this group. I don't want to run the risk of overdoing it on the first step of the journey, and these activities seem appropriate for striking a balance between sophistication and simplification. Of course I won't really know how well I did until I hand out my 1-page Feedback Survey at the end of the session, and then review the results. That's always been my best metric for these jobs, and I've learned a lot from what people given me on them.

And naturally, if you're looking for help with a Retrospective yourself, or any other sort of assistance with an Agile topic, don't hesitate to contact me (AgileMan@sympatico.ca). I'm always on the lookout for jobs for ol' AgileMan (superhero at large)!

Good Reads On Pair Programming

Just a quick link to this blog entry from someone who feels very passionately about the benefits of pair programming but doesn't believe that most software organizations could pull it off. He even provides 10 reasons why.

And then for the opposite view, see this, a much shorter article that argues, in rebuttal of the first, that pair programming could be for everyone.