Software Development is a Team Sport! : Agile

Agile 2007: Reaching New Heights - Learning to Adapt

aridle — Tue, 18 Sep 2007 06:32:33 GMT

In her opening keynote, Susan Ershler told the autobiographical story of her experiences climbing Mt. Everest. It was an entertaining talk. But, relating the subject matter to the Agile community was a bit of a stretch.

The primary message of Susan's talk centered around her tag line: "Project, Prepare, Persevere."

Project - Envision where you want to be.
Prepare - Sharpen your saw, stuff your pack, and take a map.
Persevere - If at first you don't succeed...

Entertaining? Yes. Motivational? Perhaps. Agile? I'm not so sure.

Tuesday @ Agile 2007

aridle — Wed, 22 Aug 2007 00:26:43 GMT

Tuesday saw the opening keynote by Susan Ershler, as well as the beginning of the vendor talks that I organized this year. Here's the full list of sessions I attended:

Reaching New Heights: Learning to Adapt
by Susan Ershler

Agile Tooling: A Point, Counter-point Discussion
by Ryan Martens (Rally) and Ron Jeffries

Agile Practices in a Distributed Environment
by Michael Vax (Luxoft)

Absolute Agile: Applying the Synergy of Lean and Agile to Enterprise Transitions
by Paul Hodgetts (Agile Logic) and Justin Yaros (Kelley Blue Book)

Empowering Agile Transformation
by Amr Elssamadisy (Valtech)

Agile Adoption at Google: Potential and Challenges at a True Bottom-up Organization
by Mark Striebeck

I also had an interesting conversation with James Shore Tuesday afternoon. More on each of these to follow.

Agile 2007: The First Thing to Build - Trust on Agile Teams

aridle — Wed, 22 Aug 2007 00:12:29 GMT

Diana Larsen is a special sort of nut. She's an organizational development and communications expert, not a technologist. Her sessions touch on many of the softer skills necessary to thrive on a team (any team, not just an Agile team).

I've been seeking out and attending Diana's sessions since my first experience with her and her toys back at ADC 2004 when she ran a Discovery Session that explored self-organization. (Speaking of the toys, I didn't see them this year. Where were they, Diana?)

In this session, Diana explored the concept of trust, starting with a quote from Brad Appleton: "The first thing to build is trust." I took several pages of notes during the session. But, of everything, one point stood out for me: individuation.

Individuation is the process of getting to know someone as a person, finding out what differentiates them as an individual. Without individuation, all you have to judge someone are the stereotypes and prejudices that you carry with you. (And, I with me.) In order to truly trust someone, you must get to know them personally.

It seems so simple that it's almost silly. But, I'd never thought about it before. And, it explains a lot about my own behavior and that of others with whom I've worked.

During the course of the session, Diana recommended several books, including:

And, one of the folks at my table highly recommended another, related book:

The Five Dysfunctions of a Team

There was much more to the talk than I'm mentioning here. I recommend looking through Diana's slides if you are interested in more information. The slide on symptoms of distrust (12) is work the click alone!

Agile 2007: Having Fun with Rails & Agile Development

aridle — Tue, 14 Aug 2007 21:46:00 GMT

In 90 minutes, Garg, Matt and David built a working web photo sharing web site. Garg played customer. David played whip-cracker (um... PM), and David did all the heavy lifting with Rails.

This talk was a high level introduction to the speed and power of Rails as a development environment. As such, I found most of the material repetitious of other demos I've seen. But, the guys did a good job of showing off the Rails notion of "convention over configuration." They also showed off RSpec and demonstrated the plug-in architecture.

Recommended resources (from Garg, Matt and David):

I would have liked the session to be more hands-on. I'll have to check out the Rails lab for that level of immersion.

Monday @ Agile 2007

aridle — Mon, 13 Aug 2007 20:04:28 GMT

The conference is organized a bit differently this year. The only thing going on this morning is registration. So, I checked in and scanned the program guide for sessions I'd like to attend. There are too many good looking talks, this year! I hate that! How can I ever get to see all of them. I'm going to attend the following sessions this afternoon:

Having Fun with Rails and Agile Development
by Barg Upender, David Naffis, and Matt Scilipoti

The First Thing to Build: Trust on Agile Teams
by Diana Larsen

I'll pen reviews in between the sessions.

Agile 2007

aridle — Fri, 10 Aug 2007 04:50:00 GMT

I will be attending Agile 2007 in Washington, D.C. next week. In my capacity as Vendor Talks Chair, I will be moderating the vendor talks in Meeting Room 3 on both Tuesday and Thursday.

Drop me a note if you're attending the conference. I'd love to meet you and find out about your experiences with Agile.

Update: Iterative and Incremental Development

aridle — Wed, 01 Aug 2007 21:04:28 GMT

I am enjoying the copy of Visual Studio Team System: Better Software Development for Agile Teams by Will Stott and James Newkirk that I picked up the other day. So far, it is doing a good job of both explaining Agile and how an Agile team might use VSTS. They've even gone to the trouble of creating a VSTS process template for XP. Of particular interest to me, though, in light of my recent post, is this bit on IID:

... software is developed in a series of cycles which each deliver some working software (iteration) that builds upon what has gone before (incremental).

Short & sweet - just like I like it!

Definition: Iterative and Incremental Development

aridle — Thu, 26 Jul 2007 02:49:00 GMT

Agile software development methods are often described as being forms of something called iterative and incremental development (or, IID). But, what does that mean? I went looking for an answer recently, and was surprised to find a single, simple definition elusive.

Wikipedia defines IID this way: (from Wikipedia: Iterative and incremental development, accessed on 2007.07.25 at 3:00PM PDT)

Iterative and Incremental development is a software development process developed in response to the weaknesses of the more traditional waterfall model.

While true, that definition hardly describes what it means to practice IID.

Craig Larman, in his book Agile and Iterative Development - A Manager's Guide, defines "iterative development" as follows:

Iterative development is an approach to building software (or anything) in which the overall lifecycle is composed of several iterations in sequence. Each iteration is a self-contained mini-project composed of activities such as requirements analysis, design, programming, and test. The goal for the end of an iteration is an iteration release, a stable, integrated and tested partially complete system.

Now we're getting somewhere. So, the "iterative" in IID means that work is broken into sequential "iterations" that are themselves composed of enough analysis, design, implementation and testing to produce a "partially complete system" that is "stable, integrated and tested."

Larman goes on to define "incremental development" as follows:

Although an iteration can in theory be only for clean-up or performance tuning, usually the partial system grows incrementally with new features, iteration by iteration; in other words, incremental development.

So, the "incremental" in IID means that one or more new features are added to the system each iteration. Let's put it all together to come up with a single, short definition of IID:

Iterative and incremental development (IID) is a process that grows a system feature by feature during self-contained cycles of analysis, design, development and testing that end in the production of a stable, fully integrated and tested, partially complete system that incorporates all of the features of all previous iterations.

So, what should you expect to see when someone describes a process (agile or otherwise) as iterative and incremental? Well, first, you should expect to see the team working in iterations. Second, each iterations should be growing the software feature by feature. And, finally, each iteration should end in the production of a stable piece of software that real users can use. If you don't see these things, the process is not IID.

---

Update: Note that my definition above does not preclude non-agile processes. For example, a team could be doing IID by stringing together multiple miniature waterfall projects. While agile methods tend to use IID, not all IID processes are inherently agile.

Agile Prioritization

aridle — Sat, 28 Apr 2007 04:26:00 GMT

Joel Spolsky and Dmitri Zimine mixed it up last November over whether or not to interrupt a team in the middle of an iteration. I'm pretty late to this thread. But, I think I have something to add. So, here goes...

Dmitri started the thread by arguing on behalf of never interrupting an iteration once it starts. Basically, he's just parroting the party line from the Scrum doctrine: Management is not allowed to interfere with the operation of a team during a sprint. If they do, the team can cancel the sprint.

Joel countered that you should consider the nature of the interruption before blindly preventing it. He argues in his inimitable way that the financial independence of the individuals involved could very well be at stake. He may as well have been yelling: "Take door number 3!"

What both guys missed is that they are arguing the opposing sides of a pendulum, and that the real truth probably lies somewhere in the middle. (Ironic considering the tagline on Dmitri's blog.)

Here's my advice when faced with the decision of whether or not to accept new work after an iteration has started:

Take five minutes to estimate the newly requested work.
Communicate this estimate to the person who requested the change in scope.
Explain the concept of velocity (if necessary).
Ask them to stack rank the new work into the remaining backlog of unfinished work for the current iteration.

There, now. Everyone has visibility into the process. And, the person in the best position to make the call as to priorities - the one who knows both the benefits and (now) the costs of swapping in new work - is the one responsible for making the decision. That's what I call Agile Prioritization.

For further study, I recommend that Dmitri and Joel (and everyone else) read Mike Cohn's excellent book: Agile Estimating and Planning.

CNN International was just here...

aridle — Fri, 27 Apr 2007 23:31:00 GMT

A CNN International crew from Hong Kong was just here filming the patterns & practices agile development space. They were working on a feature program called Global Office. They filmed me while I pretended to be reading email on Peter’s laptop while sitting in our lounge. Thank goodness I wore some decent clothes today! I just wish I’d shaved.

No word on whether or when the footage will actually air in the US. If I hear something I’ll pass it on.

Another TDD Convert

aridle — Wed, 04 Apr 2007 08:57:00 GMT

I recently stumbled upon the blog of a colleague, John Socha-Leialoha. And, in familiarizing myself with his writing, I found these three solid little posts on what it was like to transition to Test-Driven Development:

I especially like the first post. It says exactly what I would have shortly after learning TDD. Trust in the tests!

Become a Certified Agile Software Specialist!

aridle — Wed, 04 Apr 2007 08:27:00 GMT

Thanks to the good folks over at Agile Certification Now, you too can join the legions of Certified Agile Software Specialists already making the industry a safer place.

Follow the link. You won't be disappointed.

Capacity vs. Velocity

aridle — Wed, 04 Apr 2007 02:11:00 GMT

My team just completed a discussion - at times a rather passionate discussion - about what work items we should be tracking in TFS. Sanjeev, our PM, argued in favor of tracking everything we do - except meetings. I, lead dev and agile purist that I am, argued in favor of only tracking those work items that directly contributed functionality to the software we are building. But, ultimately, we decided to track both. Here's why:

The argument for tracking everything is that unless we track all activity, we might miss some task that we are required to do. For example, the development process used in Developer Division at Microsoft requires us to pass several "quality gates" (such as a security review) before we integrate our work into the central repository. This work must be done, in order to satisfy the process. And, there are several different tasks that fall out of this work. Tracking them all makes sure we don't miss any required steps.

The argument for tracking only those things that directly contribute to the software is that by tracking everything, we will not be able to accurately predict when we will be done with our backlog. Non-backlog items would be given equal weight to backlog items. So, it would be impossible to set priorities. And, it would be impossible to accurately predict when we will be "done" with our backlog.

Needless to say, both Sanjeev and I felt strongly about our positions. (We had to break out the "talking stick" in order to keep from talking over each other.) But, ultimately, we decided that we were both right. So, we're going to track everything (capacity) and flag those items that directly contribute to reducing the backlog (velocity).

Our hope is that this will give us meaningful information about the taxes our development process imposes on us, as well as a way of prioritizing work that directly relates to reducing the backlog. Once we have both numbers, we will begin trying to squeeze as much velocity into our capacity as possible. Ultimately, I would like to see a burn-down chart that looks something like this:

Where:

Total Work = All work, including features & overhead
Feature Work = All feature work (sans overhead)
Overhead Work = All non-feature work, including "infrastructure" or "process" imposed work items that do not directly contribute functionality to the resulting software.

Calling attention to the overhead (as this chart does) allows the team (and their managers) to think about how much more productive they could be without it. Some of it will be out of the team's control - like the "quality gates" here at Microsoft. But, other bits of it will be within the team's control - like sending everyone to group status meetings when a single representative might suffice.

In other words, the three trend lines could be restated as:

Projected Total = This is when we think we will finish everything.
Projected Feature = This is when we think we will finish the features.
Projected Feature without Overhead = This is the soonest we could possibly finish the backlog, assuming all overhead items were to disappear.

So, in the example chart, the team in question expects to be done in iteration 14. They also believe that they will be finished with their feature work in iteration 12. And, if they were to drop everything but the feature work, the soonest they could finish would be iteration 9. So, the overhead is costing this team a full 5 iterations!

Ultimately, what we hope to accomplish with this data is to understand what our overhead looks like, and what impact it is having on our ability to deliver. We hope this will be incredibly useful feedback to the process about the process.

Now, how do I get TFS to produce this chart?!?! Where did I put that book on on MDX?

Buckshot Brainstorming

aridle — Sun, 25 Mar 2007 09:52:00 GMT

When my team is stuck, I like to break the log jam with a bit of brainstorming. I've had good luck with this well known technique. Maybe you will, too. I call the technique "Buckshot Brainstorming." Here's how it works:

Get the team together

Pick a time and place where the team can concentrate uninterrupted on the task at hand. Invite people to check their laptops at the door. And, set the tone by welcoming everyone and explaining the goal of the session - to come up with as many ideas as possible.

Give everyone a pad of sticky notes and a pen

Individuals will use the sticky notes to capture ideas - one idea per sticky. If you can, give people brand new pads. This tells them that you expect lots of ideas. Tearing pads in half or quarters can work. But, make sure that there are an adequate number of stickies in the room. Running out of stickies sends a subtle message to the team that you aren't willing to listen to all of their ideas.

Brainstorm as individuals

Take a few minutes to jot down as many ideas as possible. Time box this effort to somewhere between five and ten minutes to keep people focused. Discourage talking, as conversation distracts others and could potentially filter out ideas. Encourage a little friendly competition to see who comes up with the most ideas (or the most unique ideas).

Group the stickies by author

Once time is up, reconvene the group and ask everyone to place their stickies on the wall. Invariably, people will place their stickies in small groups. It looks like someone shot up the wall with a giant sticky shotgun. Thus the name "Buckshot Brainstorming."

Brainstorm as a team

Now comes the fun part! Take turns presenting your stickies to the team. As you take one of your stickies off the wall and read it, explain what you meant to the team. Encourage people to ask questions to make sure they understand the idea. Often, reading one of your ideas will trigger another idea for someone else. When this happens, capture the new idea and add it to the And, allow people to add stickies to the wall throughout the meeting.

Group the stickies by category

As team members read their ideas, some will be duplicates and some will be closely related. Place similar or related ideas into groups on a different wall. Name the categories as you go. These names represent the high level concepts people were trying to communicate. The more stickies there are in a category, the more people were thinking about it. This may indicate the importance of one area, or the need for additional thought in other areas.

Give it your own twist

I recently participated in just such a brainstorming session with a team of about 12 people. We were trying to come up with things we would like to see in Visual Studio Team System that required collaboration with other teams.

The conditions were not ideal. Some people came late. Others had to leave early. But, in about 2 hours, we brainstormed, discussed and categorized about 100 ideas.

The categories we came up with at first were things like "process," "development," "test," etc. But, once we were done, we decided to matrix the ideas into three more categories - things we could do without another team, things another team could do without us, and things that required cross-group collaboration.

In the end, we produced about 15 high quality ideas that required cross-group collaboration, which was the point of the exercise. Further, these ideas were also categorized by the area of Visual Studio with which we would need to collaborate. So, the matrix of categories worked great for us.

Once we finished placing ideas into our matrix, we voted on the items in the collaboration category. Up until that point, all ideas were considered equal. After that, though, we had exactly what we wanted - a stack ranked list of opportunities for collaboration.

Why I like this approach

The best thing about this approach is that it is so inclusive. Everyone gets to share their ideas. And, no one is allowed to critique an idea. Malformed or wacky ideas may actually trigger a really good one for someone else. So, everything gets equal time.

In fact, right up until the end of the process, some pretty strange ideas were on our list. Eventually, they either didn't involve collaboration (removing them from the list entirely), or they didn't receive any votes (placing them at the bottom of our stack-ranked list right where they belonged). Even so, the authors of these particularly original ideas felt great about the fact that they had been included in the process. And, as such, they'll be more willing to work on the ideas that ended up higher on the list. That's what I call a win-win.

Drop me a line

If you are already using this technique, or you give it a try for the first time, drop me a line to let me know how it works for you...

I wish you luck. And, may all your ideas make the cut!

Commitments

aridle — Wed, 16 Aug 2006 22:00:22 GMT

Like most organizations, Microsoft is keen on rewarding people who go above and beyond. Defining what “above and beyond” looks like for every individual in the company is a process we do annually called “Commitments.” As an organization, we spend significant portions of July and August defining our commitments for the next fiscal year. The process starts somewhere high in upper management, and gradually filter down to those of us leaf nodes.

Last year was my first pass through this process. And, while I don’t yet know the results of my review, I feel that the process failed me. Here’s how: I wrote my commitments in July/August. By September, they were out of date. By October, they were meaningless. Why? Because priorities changed, and my role on the team changed. But, my commitments didn’t change with my role, in real-time. Sure, I tuned my commitments in February at my mid-year review (MYR). My manager and I adjusted them as best we could based on the information we had at the time. But, by April, they were again made meaningless, when I changed roles yet again.

Because I only had two shots to get my commitments right last year, they rapidly became little more than silly reminders of a foregone time. “Look at those old commitments! Aren’t they quaint?!” They held little relevance for me in my day to day job. And, as such, they were useless to me as a tool for deciding how to prioritize my work and where to spend my time. This (fiscal) year, my first and most important commitment (to myself, not Microsoft) is to figure out a saner, simpler, more Agile way of setting commitments that mean something over time.

Step One: My commitments must change to reflect my role on the team. At the beginning of the year, I will have specific commitments. If my role changes, I commit to adding new commitments to reflect my new role, and to evaluate and retire commitments that no longer apply. If this works the way I hope it will, by the end of the year, I’ll have already written most of my annual review. In a sense, I want to define my commitments incrementally, as circumstance change throughout the year.

Come back soon for Step Two: My commitments must reflect those of my team, my group, my organization, and my division.