Want to see how Agile works in practice? Here's an inside look

To really understand how Agile works, you need to try it. Columnist Jennifer Lent spent a day trying Agile on for size. Here are her takeaways on what works and what doesn't.

I'm calling this my "Agile in action day."

On a recent Saturday, I took part in an Agile Product Open event in Cambridge, Mass. I got to see firsthand how Agile works. Agile can be powerful when you push it to the max, continually removing obstacles from your path. And I also saw how easy it is to fall back on "business as usual," with some self-organizing groups using "Agile in name only" practices.

For a tech journalist who doesn't see Agile in action everyday, it was energizing and fun to participate in this event. Unlike traditional conferences and seminars, where topics and speakers are predetermined, the Agile Product Open took an Agile approach to setting agendas. Participants decided what they wanted to talk about. Anyone could lead a session on the topic of their choice, provided they drum up enough interest from the group. This made for a fast-paced, focused event -- and saved us from sitting through a bunch of PowerPoints.

Here are some of highs and lows of my day learning how Agile works.

Agile in action: What to talk about?

Once the rules of the game were set, serious work got underway. Participants stood up and announced what they wanted to talk about. No introductions, no rambling on, just name your topic, just write it down on a Post-It and stick it on the board. It moved fast, and the process was illuminating because we learned what keeps people up at night. Here's what the group came up with:

  • Transitioning from Waterfall to Agile.
  • Slicing user stories.
  • Making sure the important things get done.
  • Prioritizing.
  • Concept of product is blocking organizational agility.
  • Awesome retrospectives.
  • Product owner: part of delivery team or leading delivery team?
  • Working with Scrum masters.
  • How do we talk about product vision?
  • Agile without colocation.

We initialed the Post-Its to signal our interest. Topics that earned enough followers were assigned locations and time slots. So many topics were compelling to me -- it's tough to choose between two in the same time slot. Don't worry: If you don't like your session, walk out and join another. No excuse or apology needed. That's one of the rules of the game.

I opted for "Agile without colocation," and it was so engaging I stayed the full hour. It's an Agile in action experience. Our leader didn't set the agenda; we did, but she kept us moving and pushed us to find answers to hard questions. And almost all the questions were hard. At rapid-fire pace, she led us to consensus on what makes a team Agile. We winnowed down more than a dozen elements to these five:

  • Two-week sprints; release to production at least once per month.
  • Fulfilled action items from the iteration.
  • Team's ability to unblock themselves.
  • Time-to-demo iteration to "done."
  • Percentage of stories completed based on user needs.

We looked at how lack of colocation impacts a team's agility. The big sticking point was how a team unblocks itself; that is, how it gets unstuck and keeps moving. "It's about the team's ability to not collapse with change," one participant said. "You get a new set of information. Are you going to respond -- or are going to continue sailing the Titanic?" another said.

The ensuing discussion: How do you get fast answers to quick questions with teams in different time zones? Cultural norms get in the way. Depending on the country, some people always say "I'll get back to you." How do get around this problem? The best answer: Make sure teams at all locations get the same training at the outset of the project. Let everyone know quick questions demand fast answers.

It's not perfect, but this group has momentum. It keeps moving toward answers. The hour was up quickly and it's time to move on.

Agile in name only

Next was "Making sure the important things get done," combined with the Prioritizing session because the leaders agreed their topics are one and the same. Discussion focused on prioritizing the backlog. Good observations emerged -- not every customer complaint is a separate backlog item; you have to sort and organize them. But it felt like a brainstorming session with one person at the whiteboard. It's an old style meeting, where people took turns talking, some more aggressively than others. But was anyone listening or responding in meaningful ways?

The most interesting moment occured when a participant recommended throwing everything out and starting over. "It doesn't matter what priorities were a month ago. What are the priorities now?" she said. I saw people bristle at this idea, and no one took her up on it. I asked her to say more about this. She said she uses this approach each time a new member joins her team. "In order to get their buy-in, we don't show them the backlog," focusing instead on the meta questions: "What are we building. Why? Who is going to use it?"

 She didn't gain traction with the group. This session felt more like Agile in name only than Agile in action. It's a reflection of how Agile works in the real world. It's humbling to see how easy it is to fall back to this approach.

Agile in action: Courage to ask for help

The next session was: "Product owner: part of delivery team or leading delivery team?" The session took awhile to find its footing -- with good reason. Participants face real struggles making the product owner role work. "The business says: 'I provided you with a BRD [business requirements document], and I want you to deliver.' But that's not Agile," one participant said, as people nodded in agreement.

The most pressing problem to emerge was: What do you do when you work for a startup and the CEO is your de-facto product owner? The participant that raised the question is an experienced Agile coach, and I was struck by her courage to admit she is stuck and seeking help. She's tried many things. She asked him to join the team, and he engaged with members for a while. But once the team split in two, his participation fell off. Our group worked on the problem; we swarmed around it:

  • Get him to participate in retrospectives.
  • Reduce sprints to a week to expose problems earlier.
  • Establish total clarity about acceptance criteria and make him responsible.

There are no easy answers to this problem, but we're working on it. I was experiencing Agile in action.

My favorite comment of the day came from the "Agile without colocation" session. One participant captured the vibrant energy of the event: "I've never been completely colocated ever. That's life; I'm totally fine with it. Let's just keep moving. I have teams in India, teams in California and in Washington state. But please, when we have a Google video chat, I want to see you -- not your stupid little robot thing!"

The Agile Product Open was the best industry event I've ever attended. I can't wait to do it again. 

Next Steps

Agile -- should it be out with the old and in with the new?

Would you consider Agile all grown up?

What happens when Agile and CD meet?

Dig Deeper on Topics Archive