In this issue:
Three Tips to Move from Agile in Name Only to Real Agility
Several of you have written to me, asking about the problems you see. Your managers focus on certifications, practices, and vanity metrics—not real agility. The managers don't understand how agility can help them. You see cargo cult agile. You worry that agility is a fad and your organization can't succeed.
You have choices.
Mary, a Scrum Master, explained that her managers had arranged certification-based training. However, the people watched videos as individuals because they worked from home. They trained alone and thought that's how they were supposed to work—alone. She asked, “How can I help them learn to work as a team?”
Peter, an agile project manager, explained that his managers want to measure the team's velocity instead of any other metric. He asked, “How can I help managers realize they're asking for a metric that won't give them the information they need?
You might have these concerns, too. Here's how Mary and Peter helped their organizations achieve more agility.
Tip 1: Limit the team's WIP (Work in Progress)
Since Mary's team had learned about a particular agile approach as individuals, she wasn't surprised they worked as individuals. She didn't suggest they work together. Instead, she asked, “Is it okay if we limit the number of things we work on at any one time? That way, we can probably finish more in a given week.”
After some discussion, the team agreed to try an experiment. She then asked, “There are seven of you. How about if we limit our WIP to not more than three stories, no matter where they are on the board? We need time to practice how to work like this.”
The team wasn't so sure about three stories anywhere, but they agreed they should limit the total. Mary helped them design a kanban board so they could see where the work was. They worked for a week to track their flow.
Mary encouraged them to swarm so that they could feel the accomplishment of finishing work. Mary had learned about kaizens, and introduced the short reflections to her team. They used the kaizens and the longer retrospective to inspect and adapt their way to a collaborative approach.
After the fifth week, the team had WIP limits on every column on their board. And, they collaborated in various ways to finish the work.
Tip 2: Create Measures that Help Management See Progress
Peter's challenge originate in how management saw an agile approach. Management thought velocity was something that would increase until the team was totally productive. Peter asked the team if they were willing to collaborate to refine stories so the team could finish a story every day. They agreed and started to complete a story every day. (That wasn't easy, but they worked hard to achieve that completion.)
Then, Peter offered a demo every day to anyone who wanted to see the demo.
No manager showed up until the fifth day. That's when one manager arrived and said, “How can you possibly have something to show us every day?”
Peter said, “First, let me show you the demo, and then we'll discuss the data.
The manager was surprised by how much progress the team had made in just five days. “You must have a velocity of 100 by now,” the manager said.
“Nope,” Peter said. “Our velocity is 5 stories per week. Every story is a “1” so we don't have to estimate too much.
The manager wrinkled his brow. “Could you do more?” he asked.
“Nope,” Peter said. “We're able to do one story a day with the people we have. Let me show you our cycle time.”
That's when Peter explained how a demo was the best measure of working software, along with the product backlog burnup chart and the features chart. (See What Decision Will You Make Based on This Data? for examples of the charts.)
The manager realized they could use demos and these different charts to make good decisions.
The team used the principle of Inspect and Adapt to create small stories they could finish on one team-day. And, Peter helped the managers inspect and adapt their ideas.
Tip 3: Inspect and Adapt to Discover What's Next
There's only one practice in the Agile Manifesto principles: to reflect and tune at regular intervals. You've probably heard this as “inspect and adapt.”
In reality, you only need this one practice. That, and a continuous improvement mindset so you experiment your way to success.
I happen to also use these ideas a lot:
- Limit the WIP to finish more work faster with collaboration.
- Seeing progress with demos, running, tested product.
And, when we run experiments and inspect and adapt, we can overcome the mechanistic view of agile approaches Mary and Peter saw in their organizations.
You don't need permission to do the right thing. You can use your influence. (See the Influence newsletters from earlier this year.)
Start with yourself. What do you need to do to reflect and tune your approach and work with others to create real agility? I suspect any changes you make will take time. That's okay. What have you got to lose?
If you have the problem of cargo-cult agility anywhere in the organization, drop me a line. Let me know where your issues seem to be.
See Distributed Agile Success for all of my self-study classes with Mark Kilby based on our book, From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver.
Are you new to the Pragmatic Manager newsletter? See previous issues.
Here are links you might find useful:
- My Books. (BTW, if you enjoyed one of my books and you have not yet left a review, please do. Thanks.)
- Online Workshops
- Managing Product Development Blog
- Create an Adaptable Life
- Johanna's Fiction
Till next time,
© 2020 Johanna Rothman
Tags: agile, management, metrics, replan, tips, transition to agile, WIP