Using the Best of Agile and Lean for Your Project

Cindy, a Scrum Master, strode into her manager’s office. She said, “Got a sec, boss?”

Andy, turned around and said, “Sure. What’s up?”

“I quit,” she said. She turned around and started to walk out the door.

“Hey, wait a sec,” he said. “You can’t drop a bomb like that on me and then leave. What’s going on?”

Cindy took a deep breath. “Okay. Our ‘process’ is strangling us. Every time the team and I want to experiment with something, we get the auditors breathing down our neck. Or, the PMO tells us we’re not doing it right. I don’t know who taught them about agile or Scrum, but this is ridiculous.”

“Give me an example,” Andy said.

“Okay. We workshop stories in the middle of our iteration. We specifically work as an entire team and the PO to workshop the stories together, so we have really short stories, a day or less in duration. That way, we don’t have to estimate. All we do is count stories. We can finish 10 or 11 stories in an iteration. Easy, right?”

Andy nodded. “Sounds like it.”

“Well, someone from the PMO didn’t like the fact we weren’t ‘estimating’ the way they wanted,” she continued. “We don’t need to use story points. We don’t need a freaking burndown chart. We need burnup charts because all we do is count stories.”

Andy nodded. “Makes sense to me.”

“That’s the crazy part. The PMO has no idea how agile really works. So, we’re not following the ‘official’ (she used airquotes) process and they’re dinging us for it.” Cindy paused and took a deep breath. “They actually told the auditors we weren’t following the official process. I had to talk an auditor out of writing up a finding because we’re more effective than the official process.”

Andy frowned. “You’re using agile and lean principles. That official process thing makes no sense at all.”

“It gets worse,” she said. “I track cumulative flow and our WIP–Work in Progress–so we understand where the time goes. Sometimes, we need to add items to our board because we support production. I was told that we only should track velocity, that cumulative flow and our WIP doesn’t help us.” Cindy was practically vibrating with anger. “How dare they tell us how we should work. How dare they!”

Andy sighed. “Okay, I get it. What do you want me to do?”

“Tell them to butt out of my project!” she said.

“How about if we help them understand that you can still use Scrum with lean ideas?” he suggested.

Cindy shrugged. “Okay, but get them out of my project.”

Each Team Can Design Their Own Agile Approach

Each team is unique. Some teams can commit to an iteration’s worth of work. Some teams can’t because they also take support work as Cindy’s team does. Agile approaches can accommodate both kinds of work, with and without interruptions.

Some teams don’t yet have all the people they need. Those teams might rely on a UX service team to support their UI efforts. Other teams need to rely on a deployment team. These teams might want to track their wait times and where bottlenecks are–something a kanban board does quite well.

When teams start with the principles: collaborate on small chunks of work to deliver often and reflect, they often define their own board and approach to the work that fits for them.

You might be in an organization that mandates a specific agile approach. In that case, consider these options:

• Discuss the reasons for any mandates
• Discuss the outcomes the team wants and management wants to find common ground
• Create experiments that provide feedback for the team and for the people who want to mandate one approach.

The first step is to understand what people want.

Discuss Why Your Organization Desires a Standard Agile Approach

Some people want every team in their organization to have one standard agile approach. If you ever used a waterfall lifecycle, you could make your project look like everyone else’s project.

However, the point of an agile approach is to iterate over the requirements the way your customers need, and to deliver increments of value your customers need. Some project teams need many small experiments they can discuss with their customers. Some project teams need frequent delivery to solve problems every day for their customers. Some projects need both, at different times in their projects.

Just as no two projects are equivalent, different agile approaches help your team define what it needs and when. When teams combine the best–for them–of agile and lean approaches, they often have different artifacts than other teams do.

When people in the organization mandate specific agile approaches, and even worse, practices, they ignore the best part of an agile approach: the ability for each team to work in a way that satisfies their customers.

Andy and Cindy investigated and discovered that the PMO had not yet had any agile training. They didn’t realize the wide variety of possible metrics and the possible approaches to backlog creation and refinement. The PMO thought agile approaches were another life cycle, not a different culture of work.

That meant that the PMO had defined practices for teams, not principles. The auditors didn’t understand agile principles and could only assess teams against these practices. Luckily, Cindy’s teams was the first to help the PMO and the auditors realize the difference between practices and principles. The organization created training for both the PMO and the auditors and changed how the auditors reviewed projects.

Discuss the Outcomes Everyone Wants

Cindy’s team delivered the outcomes her customers wanted. The team was able to deliver a small story at least once a day, and was able to manage their production support work. In addition, the organization wanted some “common” metrics they could use to assess every project. That was the original reason the PMO wanted them to track velocity.

Andy took this discussion point and explained that velocity was personal to a team–that no two teams would have similar velocities. He explained about throughput, cycle time, and lead time. He agreed these measures might look like “lean” rather than agile data. However, that data plus the board of what was done but not yet released to the customer were better measures than the team measurements.

After the PMO’s training, they were able to define data each team could gather, to report about the progress of each project and where work was stuck.

Receive Popular Monthly Testing & QA Articles

Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.

Subscribe

We will never share your email. 1-click unsubscribes.

Create Experiments

Cindy and Andy invited the PMO to create experiments, about the data they wanted from each team, and for the principles each team would use. The PMO invited the auditors to understand the experiments, so the auditors could provide feedback, too.

Here’s what I mean by an experiment:

• We have a hypothesis about something. In this case, it was about the metrics for projects. The original hypothesis was this: “We can use velocity to compare agile teams and to predict the health of the project.”
• We create an experiment to measure results. The PMO and auditors collected velocity data and throughput data from seven teams.
• Is our data providing information we can use? If not, create another hypothesis. If our data provides information we can use, continue. The velocity data did not correlate with throughput. They had data they could use, but the data wasn’t helpful.
• Analyze the data and see what the data says about our hypothesis. When they looked at velocity, they realized there was no correlation with throughput.
• If we answer our questions, we’re done. If we can’t answer our questions, create another experiment and continue. In this case, the PMO and the auditors reviewed cycle time, lead time, and a variety of WIP data for each team. They discovered those data helped the organization and the auditors assess the relative health of each project.

One good thing arose from the velocity data experiment. The organization stopped trying to compare teams.

Agile Invites Experimentation

Your team might need different data to see if the team has a project making enough progress. Because agile teams have all the agile and lean principles at their disposal, the team can use the best of agile and lean to progress the way they need to. Some teams love the structure of a timebox. Some teams, especially those with much support work prefer to use a cadence of planning, demonstrations, and retrospectives.

There is no One Right Way for a team to use agile and lean principles. In fact, I might even suggest that a team that doesn’t experiment often isn’t agile because they’re not inspecting and adapting.

Some of the teams with the happiest people and the most throughput use their personalized agile approach which looks like a mishmash of several formal frameworks. If your team is experimenting and refining their approach, you’re on the right track.

This article was written by Johanna Rothman. Johanna, known as the “Pragmatic Manager,” provides frank advice for your tough problems. Her most recent book is “Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.”