Q&A on the Book "Create Your Successful Agile Project"

The book "Create Your Successful Agile Project" helps people understand agile approaches and select what could work for them.Too often, teams adopt a framework without understanding the context in which that framework is useful. This book shows how you can use your team’s unique product, context, and people to define a suitable agile approach for your project.

InfoQ readers can download an excerpt of "Create Your Successful Agile Project".

InfoQ interviewed Johanna Rothman about how agile and lean fit together, how teams can organize themselves, which criteria can be used for ranking features and how to use them, why she doesn’t like "hardening iterations", and why learning opportunities are so important and how to create them.

InfoQ: What made you decide to write this book?

Johanna Rothman: Many people - teams and managers - want to use agile approaches. That’s great. However, they might not be a cross-functional team. Or, they might have to work on several "projects" (streams of work) at one time. Or, they might have so many interrupts that project work comes last, as opposed to first.

These folks still want to use agile approaches. They can. However, an "out-of-the-box" approach doesn’t work for them. They need to design/create/explore their possibilities so they can make progress on their work.

I have used many different agile approaches over the years. I’ve helped my clients create successful agile approaches for varying projects. I wanted to share ways to learn, think, and experiment with others.

InfoQ: For whom is this book intended?

Rothman: The short answer is technical leaders, but I don’t think you need to have a title that says, "lead" or "manager" or "coach" or anything else to read this. If you want to improve your agile approach or your team’s agile approach, this is the book for you.

InfoQ: How do agile and lean fit together?

Rothman: In reality, agile is a subset of lean. However, too many people think that lean is for manufacturing and agile is for innovation. Not true! Lean says, "Let’s make respect for the people paramount." Agile approaches say, "Let’s make collaboration and frequent delivery and transparency paramount." Instead of choosing one, consider selecting agile and lean approaches based on your context.

Here’s an example. Susan, who called herself a Scrum Master, tried to use iterations with a 14-person team. They needed all those people to manage the work they wanted to finish in a given iteration. However, they had to support the product in the field and the support requests did not arrive on a regular basis. The team was suffering from overtime and the testers "couldn’t keep up."

Susan and her team had heard of iteration-based agile approaches, such as Scrum. They tried to make it work for them. When she heard of the lean pillars, respect for people and continuous improvement, she realized she’d been missing something. That knowledge, coupled with technical practices, helped her realize her options.

The big problem was that her management (and originally, Susan also) had thought that agile approaches were just another life cycle. No one realized that agile approaches are a cultural change to the team and the organization.

Susan and her team asked themselves how could they see their work, limit their work in progress, and deliver value often, in a way that collaborated with their partners across the business? Once they asked that question, they changed their boards, changed how they planned work, changed how they responded - everything changed. They had some hiccups along the way because it’s difficult to learn and not make mistakes. However, they needed both the agile and lean principles to create an environment of innovation and delivery.

InfoQ: How can teams organize themselves?

Rothman: In many organizations, managers assign team members to a team. That’s the start of becoming a self-directed and then a self-organizing team.

When team members take control of their process, they realize who has the skills and capabilities necessary to deliver finished features. If teams start to visualize their flow, they know when they need a UI person, or more testers, or a database person. Teams can ask the question, "How can we learn from each other, to bring out the best in each other, so we can collaborate and deliver value? How can we, as a team, finish valuable work and show it to our customer?"

When teams answer those questions, they learn to see their process and can improve it.
Then, as they work through their answers, they create their collaborative cross-functional team.

InfoQ: You stated in the book that you don't like adding "visitors" to a team as a solution when the team doesn't have the necessary skill. Can you elaborate why?

Rothman: Software is all about learning and innovation. Sure, we might know some or even many of the requirements. And, we know how to approach some or many of the features. But, we more often are doing something unknown. Maybe not completely unknown, but unknown.

Here are some problems I’ve seen with visitors. First, is that even though they are supposed to be part of a team for a while, they are not. They don’t sit with the team. They have other commitments. One visitor said he was supposed to visit with five other teams over the course of several weeks. That’s not what people mean by "visitor" (assigned to one team for a specific duration), but that’s what his management thought visiting meant. He was not effective and he was quite concerned about it.

In addition, the visitor name often reinforces that person’s expertise. The idea under the name "visitor" is that the team doesn’t need that expertise over the long term. In my experience, that vision is wrong. Too often, the team needs that visitor’s expertise not just now, but also in the future.

Because the visitor isn’t full-time with the team, the visitor needs to learn to collaborate with an existing team, a team who has learned how to work together. That creates delays.

The visitor might have no incentive to share their expertise. Even worse, I’ve seen environments where visitors are incented *against* collaboration and deep working with a team.

Even if you have people who want to work with a team, visitors interfere with the team's collaboration. The team has to explain to each new visitor how the team works. And the team will have to re-form as it learns how to work with other people. If you need visitors, I recommend pairing or mobbing to learn what the visitor knows.

InfoQ: Which criteria can be used to rank features?

Rothman: I like three options, specifically for features: shortest work first, value over time, and learning.

When you use the shortest work first, you can get quick wins. You might even be able to build a walking skeleton.

If you use value over time, you help everyone see that different features have different value over time. Sometimes, there is no value *yet*. Sometimes, the only value is *now*.

I also like valuing by what we will learn.  This encourages MVPs and MVEs (Minimum Viable Experiments).

InfoQ: How can you find out which one to use in a given situation?

Rothman: I like to start with learning or shortest work first to help the team create a walking skeleton - the bare minimum of a feature set so we can see how the product will work.

Too often, the PO (and other stakeholders) have the big picture, a vision for the entire product. They say, "I need it all or it’s not valuable." They might think so, too. If we can break apart this big picture into small features, we can see what will provide us value now vs what will provide us value later.

As we proceed working in small features, I like to think about what we need to learn. (Sometimes, we need to learn before we can even start with a walking skeleton.) When we think about learning, we often consider who needs what when, and what the users need to learn when.

All three of these possibilities encourage everyone to create and use small stories. That’s the "secret sauce."

If the project is straightforward, I use shortest work first. If the project is not straightforward, I use learning. If we have large feature sets, I use value over time to see what to do first for the most value.

InfoQ: What's your opinion about "hardening iterations"?

Rothman: I hate the idea of hardening iterations. When we define and use acceptance criteria on stories and a definition of done for teams, we are able to know that we finished this story. It’s really done. It’s - forgive me - done-done or done-done-done.

If teams can’t finish work and know that they finish work, they end up having to return to the work. No one feels good when that happens.

If your team has trouble knowing or getting to done on a story, consider these options:

1. Conduct a retrospective to understand what data people had to make decisions at the time. Now, as part of the action item generation, consider experiments to see how to provide other data to the team.
2. Understand if your estimation efforts actually created the not-done pattern. Sometimes, a team feels as if they need to push to do "more." We have a legacy of "how much" thinking from more serial approaches. Moving to "how little" thinking can challenge everyone.
3. Take a look at what done means for the team’s working agreements, for stories, for iterations, for releases. Is it possible to create more opportunities for the team to finish and know they are really done with a feature? (I like to use scenarios as part of the story and release criteria.)

InfoQ: Why are learning opportunities important and how can we create them?

Rothman: We have an opportunity with agile approaches to receive feedback on the product, on the team’s process, and on the team interactions as often as every day. Why not take advantage of that?

Agile teams can take advantage of the retrospective for more formal learning about the product and process, and just as I like small stories, I like learning small.

In knowledge work, we uncover and learn about the requirements as we proceed. We learn how to work together, every day. We learn how the product works (or doesn’t!) every day.

The more we work in small stories, collaborating with each other, the more opportunities we have for improvement. For me, the goal is not just improvement - no, the goal is a wonderful product that helps me learn to improve alone and with a team. And, to create a product that solves a problem for our customers.

About the Author

Johanna Rothman, known as the "Pragmatic Manager", provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Rothman is the author of more than ten books, including: Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, Agile and Lean Program Management: Scaling Collaboration Across the Organization, Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd ed., See more of Rothman’s writing at jrothman.com.