News Stay informed about the latest enterprise technology news and product updates.

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

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How often are you finding Agile working in theory but not actually in practice?
Here’s what I’ve seen. I see it working in theory all over the place, but I generally only see it working in practice in two scenarios. First, in companies that started with agile methodologies. Second, in small isolated groups within organizations that were established and had processes in place before agile was introduced.
Agile is definitely not a blanket solution for inefficient teams. I work on an agile team and we certainly have our share of issues. 

We are creating a new application with tablets for our field techs. We brought in a company to do the project. They used Agile. It cost over 3 times the estimate and 3 times the amount of time.

There was so much rework because of doing only a little piece at a time. It seems to me if you are developing a brand new application that is not dependent on a current system. Agile may be a good thing.

Agile working?  It is an interesting question - as if you ask 10 different people to share their insights about the outcome they expect to see as a proof of "Agile Working"

- Being flexible to change?  OK What about the impact on associated Budget and Work which is still in "WIP"
- Higher productivity - Getting more delivered from every unit of work invested into?
- Better Product  - but please be quick!  Well I wish to eat a well cooked and tasty dish - but I need it quick please!

"Agile working"  should be seen from the perspective of "change in mindset and approach" over a period of time! I am firm believer that each person, group, team and organization had always had some element of "Agility" in their character always - it was known by some other name in the past and most likely will be known by something else in future!
Agile in name only is a common problem when companies decide to implement agile. It takes a cultural shift to truly implement agile methodologies, and that can be hard to accomplish (at least initially). The true power is in allowing your people to be agile enough to address the changing business landscape, and many failed or pseudo-agile implementations are only superficially agile, with the old, rigid organizational structure in place behind the facade.
I have been in IT since 1968 so I grew up with waterfall. There are some really good things with the agile method, but from what I have seen either method will work or fail depending on the personnel. What some of the younger people are lacking is some common sense and business knowledge. That causes a lot of rework. 

When I read the title and decided to read this article, my first thought was that there is no way for anyone to "size up" Agile in a one day conference, absolutely NO WAY.  The article lacked depth and there were no true take aways for me.  Throw in a couple of Agile terms around the article and voila, you think you know what you are talking about.  Sorry, but you missed the point. 

I do not know who the attendees were in the conference, but the idea that people "bristle" at "It doesn't matter what priorities were a month ago. What are the priorities now?" is silly.  That is the whole point of release planning in Agile.  Last month's priorities do not exist. 

Another comment that was strange was "What do you do when you work for a startup and the CEO is your de-facto product owner?"  This came from an "experience" Agile coach?  Seriously?  The CEO should not be the de-facto anything other than the customer, not the product owner.  If that is what they have done they will fail.  This person has a direction to go in for the development team, this person is the customer and nothing else.  And please NO, the CEO in the retrospective?  Do you know what that ceremony is about?

I totally agree with CharlieBrowne. Agile is no magic bullet that's going to work super well and efficiently for every team. 
This was a great commentary on Open Space. We use it to solve a myriad of issues, especially when the problems are not well defined and the number of people affected are large. Thanks for this one.