Roll Your Own (Agile Lifecycle)

Imagine this scenario: you want to transition to agile, and you have a geographically dispersed team with people all over the world. You have two developers in the UK and two in Boston, two testers in Portland, Oregon, a product manager in Brazil, and you, the project manager are in Sweden. And, you are pretty sure that transitioning to agile would make a difference to your project, because you’ve used agile before on a different project in a different organization. And, because you are geographically distributed, you know can’t use agile-out-of-the-box. What do you do?

One approach is to start with the principles of agile and decide how to create an agile environment that works for you, your team, and your context. You create your own agile lifecycle. That’s what Joakim, a Swedish project manager did.

Joakim and I spoke when he was organizing the team. He asked about the iteration length. I asked if the thought the team could manage a one-week iteration. He thought not; he thought a two-iteration would be a big-enough shock to their system.

Why a short iteration, such as one or two weeks? Because the team needs the feedback about everything, not just the code. They need the feedback about their planning, about their standups, about their stories, about how they work together, everything. Everything about their transition to agile is an experiment, so they need to start with a short iteration. One week is even better, but for many teams that seems impossible to imagine, so they start with a two-week iteration.

This team was lucky, and the product manager flew up to Boston for the first planning session, so the product manager and two of the developers were together to learn to write stories together.

This team did not have any agile training, which in my never humble opinion was a huge mistake. Since Joakim had successful agile experience, he held internal workshops as part of the first few iterations and compiled a list of readings for the team.

In preparation for the first iteration planning, Joakim created a project charter and a list of roles and responsibilities. Joakim sent this email to the project team before the iteration planning:

Dear team, we start our iteration planning on Wednesday morning my time, which is this time for all of you [he listed the times in all the time zones]. See the draft project charter on our project wiki.

My job as the project manager is to facilitate our work. I will not drive us to completion; I will facilitate our work. I will resolve our impediments. I will be the face of our project to our management. And, you will help me, by making your work transparent to me, in the best way you know how. I have some ideas on how to do that, and we will address that during our iteration planning call. Thank you in advance, Joakim.

Joakim and Andre, the product owner from Brazil worked in advance to prepare some of the stories for the backlog, and to start on the product roadmap, so the team wasn’t starting from zero.

On their first call, Joakim and Andre explained to the team that they wanted to have stories that were “small,” meaning the story could be completed by a developer and tester in a day or so. A “medium” story could be completed by both a couple of developers and a tester within two to three days and a large story could be completed by all of the developers and all of the testers in less than a week. If a story was larger than “large,” the team had to tell Andre, and they all had to work to make the story smaller. That way, the entire team could complete any story inside of one week.

Everyone had questions about how they would work together—the idea of developers and testers working together to complete stories was new to the team members.

Joakim introduced the idea of a kanban board to the team, so that the developers would not produce more features than the testers could test.

kanban.iteration.lifecycle.rollyourown

There was silence for a moment. Then, one of the developers said, “Oh, this makes total sense. We have to work together. Okay. No problem.”

The team agreed to a daily standup time that Joakim proposed. At the standup, their questions were:

  • What did you complete and with whom yesterday?
  • What are you working on and with whom today?
  • What are your impediments?

These questions reinforced two ideas for the team: that they were working on small stories until the stories were done, and that they were working with other team members.

After the first week of the iteration, one of the developers suggested that each team member add a happy/sad face to his/her checkin to explain his/her emotional state, and Joakim could follow up with sad people. Joakim countered with a suggestion that each person add a 20-second explanation of his/her emotional state, and that if each person needed something, that person was adult enough to ask for it.

After a stunned silence, the team members agreed.

Joakim congratulated the team on their movement to being a self-managed team. “It’s difficult for me, too. I want to help. And, I have a hard time know how to serve you. I am sure you will let me know if I not helpful enough!”

Joakim tracks the team’s velocity and the cumulative flow, not knowing which data the team might need. In addition, Joakim tracks the impediments for the team. Management does not always realize how much the impediments affect the team’s output.

Andre works on the feature roadmap and derives the product backlog from the roadmap. There are times when the stories are huge, and while Andre does not know how to make the stories smaller by himself, the team can help him.

This team has had its ups and downs. It took the team close to seven iterations to find its velocity, even with the kanban board helping to reduce its WIP (work in progress). The time delays introduced by the time zones are considerable, even though the work is flowing from east to west. And, just because the team delivers more consistently doesn’t mean they deliver what management needs. Andre still has problems understanding what senior management really wants from the product.

However, at the end of each iteration, the team is done, and has a demo. They are ready to work on the next set of features.

So, if you are part of a geographically distributed team, you too can transition to agile. If you can get training as a team, do so. Make sure you get feedback on your team’s process, not just the work product, and get that feedback often. Find ways to work together, and instill that working together into your daily work. Look for ways to reduce the work-in-progress. And, don’t think you have to use an already-existing agile lifecycle. You have a unique team. You can create your own agile lifecycle and succeed while doing so.

© 2012 Johanna Rothman. This article was originally published on Gantthead.com.

Leave a Reply