Create Your Agile Culture: Embrace, Not Manage Change

Stu, a manager who'd been successful throughout the years by managing risks and managing change was concerned. “I don't want to move fast and break things,” he said. “I don't want to move too slowly. I'd like to move fast. But I don't want to break anything.”

Stu didn't realize he could manage risks and manage change in an agile project. Here are three ways he found to manage his risks.

Tip 1: Manage Schedule Risk by Measuring Cycle Time

I see too many teams struggle to estimate so they know what they can do. They faithfully use story points. And, the story points don't answer the question, “When do you think you'll be done with this feature set?” (Or some other interim milestone.)

Story points don't easily translate to time. Which, to be honest, was the point of them way back when. However, managers don't have confidence in an estimate that doesn't somehow translate to time.

If you don't know how to measure cycle time, check out this blog post: Measure Cycle Time, Not Velocity.

You can use cycle time in any project. Yes, even a waterfall project. That cycle time might nudge you to work more incrementally, finishing feature sets instead of having lots of Work in Progress (WIP).

Stu asked his teams to measure their cycle time and let him know if they spent more than 25% of their total time in wait states. If it was, he would help the team remove the obstacles that created long wait times.

Stu had plenty to do. However, within a month the teams could predict short-term schedules based on their data. Now, it was time to embrace change for the product.

Tip 2: Manage Feature Risk with Experimental Demos

Stu's next big concern: “How do we know we're actually creating a product the customer wants?”

Good question.

The first thing Stu's teams did was to create a cadence for demos. Each team demonstrated its product on a weekly basis. (See Thinking About Cadence vs. Iterations to see how some teams manage their cadences.) The demos were brief and highlighted what the team completed since the previous demo. Every month or so, (depending on the product), the product manager demonstrated the product to the organization.

That was good, but Stu wondered why the product owners and managers wanted to change the roadmaps so often. He wanted to verify the learning the teams did. That meant the company needed to ask customers for feedback.

Stu's product management team chose several trusted customers and asked them if they were willing to see experimental, interim demos of features. The company wouldn't guarantee the feature would make it into a release. But, if the customers were willing to see early possibilities, the company could take their feedback and update the roadmap.

Six customers agreed to see interim demos. Based on the customer feedback, everyone realized what they could stop, what they could change, and how little they needed to add. (Your organization might need A/B testing or some other approach.)

Tip 3: Manage Architectural Risk with Learning, Socialization, and Criteria

Stu still had a big concern: “How can we manage the architecture risks without architecting the system up front?”

Stu knew that the architecture changed as the teams progressed through their work. Stu's teams used all of these options:

Architectural spikes of a day or so to learn.
Propose a paper architecture (similar to a paper prototype) and as the features changed the proposed architecture, discuss and socialize those changes.
Create acceptance criteria around the various performance requirements.

Your teams might need more, but these approaches worked for Stu's teams.

Stu is a lot happier with their agile approaches now. Each team works autonomously, demonstrating at the regular cadence. Stu isn't sure they need all that change, but the people are happier, the products are more robust, and they're releasing what customers want more often. As a result, they're making more money.

Earlier in his career, Stu managed change through hard work and some good luck. Now, as he embraces change, he and the organization need a lot less work and less luck.

When we embrace change and manage risks differently, we can create successful agile projects, and even more important, an agile culture.

Learn with Johanna

I'd hoped to have more online workshops to announce, but not yet!

My online workshops with Esther Derby are at Your Management Mentors. The first workshop is Make the Most of Your One-on-Ones.
My online workshops with Mark Kilby are at Distributed Agile Success. The first workshop is Prepare for Successful Distributed Agile Teams.

In addition, Create Your Successful Agile Project is now available in audio, wherever you buy audio books.

I know I'm late with this Pragmatic Manager. I had a wonderful summer and am back to my regular schedule. I might send a Pragmatic Manager more often to “catch up.” Just letting you know.

New to the Pragmatic Manager?

Are you new to the Pragmatic Manager newsletter? See previous issues.

Here are links you might find useful:

Till next time,

Johanna