Three New Year's Tips to Ease Your Team's Agility

I hope you are all having a terrific holiday season. A reader asked me about tips I had to ease her project's transition from waterfall to an agile approach. Woo! I have plenty, so I decided to select three tips I have seen work.

Tip 1: Use Principles to Plan Your Team's Approach

Many teams that want to use an agile approach start with planning from a given framework. Instead of using a framework, consider explaining the principles you want to achieve. Then, conduct some data-gathering so you can create experiments.

This approach works particularly well if you've tried an agile approach before and “failed.” Even if you haven't tried an agile approach, you might learn more from experiments instead of adopting a framework.

Benny, a project manager who had just completed Scrum training, realized the Scrum ideas and practices would be foreign to his team. Benny had been reading about agile and lean approaches for the past year. He realized the team if the teams started with these three ideas, they might learn to adopt an agile approach:

How to collaborate as a team (resource efficiency vs .flow efficiency)
How to release value as quickly as possible (cycle time)
How to see and manage their team's WIP (Work in Progress) (cumulative flow)

Instead of asking the team to use any of the Scrum practices, he asked them to conduct a 30-minute combination reflection and planning session, focused on these questions:

What could we do to make sure we increase the flow of features from our team out to our customer? How can we finish faster, with excellent quality?

The team members didn't understand the question. He explained these points above. He wanted to help the team see how they might work in the future.

Tip 2: Learn Together as a Team

The team decided they needed more time to learn about these ideas and then to implement them. The team asked to do a 30-minute learning and data-gathering session every morning. They did that for three days, taking the ideas of flow efficiency, how to measure cycle time, and see their team's WIP. Then the team decided on these experiments:

The team decided to map their flow of work for several features for two purposes: verify how the flow of work through the team and to collaborate where possible.
The team was willing to swarm over just one or two features at a time to reduce their cumulative flow and manage their team WIP. (See pair, swarm, or mob for definitions of ways team members can collaborate.)
They wanted Benny to work with the Product Owner to reduce the feature size. The PO kept insisting the PO needed “everything” to release.

The team started to learn how to manage their work. By the end of three weeks, they released one feature. And, they learned how to create better automated and exploratory tests.

The team members explained to Benny that the incoming “features” were feature sets. The incoming work was too big. That was Benny's next set of actions.

Tip 3: Move to “How Little” Thinking

(You might remember Reframe the “How Much” Conversation to “How Little” several months ago.)

The PO, Janet, was concerned the customers wouldn't want features-in-progress. Benny thought that was reasonable. He suggested feature flags, so the team could still release, but not expose the not-quite-finished features to the customers.

And, Benny showed Janet several features that were very large. He said, “Feature A is really about 20 stories, see?” He showed her the backlog. “I am sure we can release before we finish all 20. Don't we want feedback on some of these before we finish everything?”

Janet sighed. “Yes, we want feedback. And, my boss still wants to know when we'll finish everything.”

Benny realized that the managers were still stuck in one-release thinking, not multiple-release thinking. “If I help with your boss and the other managers, tell me where we can create breakpoints with this feature set.”

Janet and Benny spoke for a while. (Yes, it might have been better for the entire team to be in the conversation, but neither Benny nor Janet was ready for that.) They agreed where the team could use feature flags and where the team could release independent features.

Over the next few months (nothing is fast with this much change), the team was able to move to releasing something valuable almost every day.

Now, Benny had time to work on the managers and their attitudes. (You might like Frequent Releasing Can Lead to Short and Frequent Planning as a way to help you and your managers think about more frequent releasing.

If you like these three tips, please do read Create Your Successful Agile Project (ebook, print, and audio). You'll find many more tips in that book for a successful agile project, and the start of a successful agile transformation. And, if you have other questions, do email me.

Learn with Johanna

If you are a leader like Benny in your organization, please consider joining us at the Influential Agile Leader, May 6-7, 2020 in Boston. You have until Jan 1, 2020 for the best possible rates. If you do register before January 1, 2020 and you can take advantage of one hour of coaching with either Gil or me.

Other learning possibilities:

My online, self-study workshops with Esther Derby at Your Management Mentors.
My online, self-study workshops with Mark Kilby are at Distributed Agile Success.

Do you want more online workshops from me? Drop me a line and let me know what you'd like to see.

New to the Pragmatic Manager?

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
Coaching
Managing Product Development Blog
Create an Adaptable Life
Johanna's Fiction

Till next time,

Johanna