First Steps Towards Agile

Yesterday I received a note from a fellow NAU alumnus who found me on LinkedIn and asked where to start with a small-team transition to Agile.

Aside: I sent a reply; mostly an unedited stream-of-consciousness, but I thought it was good enough to post here. I'm not sure I'd give the same advice to everyone, but it seemed to make sense for his circumstances as I understand them. I got the sense that he's in need of a do-it-yourself Agile transition, perhaps due to his remote location. (Though I suspect he knows that I'd travel to his particular region of the country without hesitation. I give discounts for certain personally-nostalgic locales! :-)

Feel free to comment with other suggestions. What would be the first two or three steps you would take in his circumstances?

The Letter

I was wondering if you wouldn't mind helping me? I lead a team of developers, analysts and a webmaster...read a lot about agile and think it's potentially a great way to go. How do I even get started?

To date I started doing some small team-ups for projects we have. I have assigned tasks to different team members. I know this isn't agile but up until this time our team developed everything silo'd. They all had their own projects and never worked on someone else's work... So I figured it would be a good start to at least expose them to teaming...

From here I am really not sure what to do nor do I deeply understand the concepts in agile. I have read a ton on the internet but there is nothing like experience to really help.

Effectively, I suggested he start with a retrospective...

My Reply

Hi,

I think I have a great answer for you, but I want to say a few words beforehand so you don't think I'm just handing you more to read.

I was glad to hear that you're getting them used to working together as tiny teams. I suggest that small organizations try to partition the teams by separate code-bases. Products tend to map one-to-one with a code repository, and teams work best when they map one-to-one with a product. People often try to have multiple teams with their hands in one code-base, and they often discover that they're inadvertently impacting each other. If someone can impact your team, that someone is effectively on your team. But I'm wandering into dangerous territory since I'm not familiar with your set-up.

When a team starts to do things differently, it is difficult to figure out what to do first, or to just jump in with both feet (or head-first, perhaps?). So keep that in mind: Ultimately, you have to decide what's the right first step for change.

It may sound odd, but the first thing that needs to be in place is a mechanism for getting anonymous feedback on how the process changes are being experienced, and what the team's biggest problems truly are. I would start with a "retrospective" meeting. I suggest that teams do this every two weeks. It doesn't have to take more than an hour:

1. Get everyone in a room together and have them write troubles on sticky (Post-It) notes and have them post these stickies randomly on a wall. This gives people the ability to anonymously voice what they see as the biggest pain points. No limit to the amount of troubles.

2. Then have them go up in small groups and rearrange the notes. Not in rows/columns, but in clusters by how closely related the troubles are to each other. Duplicates are very close, similar topics farther, and wild suggestions farther. Let the stickies clump organically, so to speak.

3. Then look for the biggest cluster. Help the team find a way to fix that.

If your team is too small to distinguish a cluster after step 2, replace step 3 by giving each person three stars or colored sticky dots to use to vote for their top three problem areas. We usually require that they cannot vote for the same problem more than once. You'll probably find that they all agree on one or two major problems.

That's one of the first things I would do with your team. But since I don't know what they would come up with as the biggest problem, I can't suggest further action except to go out and obtain a copy of The Art of Agile Development by James Shore and Shane Warden, and read it as though your career depends on it. I worked closely with Jim Shore in 2001 and he knows how to solve problems. Most of what they have recorded there is stuff that we were doing in 2001, and it's still some of the best "agile" advice, all collected in one place.

Lastly, be aware of the two primary reasons why agile projects fail, and how to prevent them:

1. The Product Champion (Scrum "Product Owner" or XP "Customer"), the person who decides what features go in and what features don't, and also chooses which order they go in, must be readily available, willing to work on creating "stories" with enough detail and acceptance criteria so the team knows what is needed, how to test it, and how complex it is (for estimation). And this person must be ready to decide what the top priority detailed stories should be done first. Without this, the project will probably fail. "Agile" is not just a developer's process, it tends to impact the way the organization builds software product.

2. Too few automated tests. I call this the "Agilist's Dilemma" because without tests it becomes obvious to the developers (whether they'll tell you or not) that it's getting harder and harder to change the code to accommodate the next set of stories. At the very least, encourage developers to try Test-Driven Development practices wholeheartedly, right away, for two 2-week iterations. They'll need to learn how to do it right, and with some discipline, to get the full value. Dave Astel's book is good (Test-Driven Development: A Practical Guide), Kent Beck's book is good (Test Driven Development: By Example).

My courses are even better, because you get hands-on experience plus team-specific guidance! I'm also available for coaching, of course.

Serendipity At StarEast

This same question (effectively "What are the first steps?") came up after Lisa Crispin's talk at StarEast today. I like her answer, too. She responded with these two (I'm paraphrasing):

1. Get some Agile training for the team.
2. Talk with managers about how their roles will change, and let them know that the team will need their support and confidence.
Summary

So perhaps I'd alter my list to be:

1. Get some Agile training and/or hire an external coach.
2. Run a retrospective on the current, pre-transition process. Refer to Art of Agile for potential solutions. Try the chosen solution for two weeks. Repeat.

...And include management in both!