With Agile software development moving from the fringes to mainstream to enterprise-wide, a dilemma with many contradictions emerge - how do you scale Agile? Much like “distributed” seems to be contrary to “Agile”, “scale” also fits in rather uncomfortably with “Agile”. The SAFe framework has its fair share of criticism, but what are the alternatives? Who better to inject some fresh perspective in than Johanna Rothman - the “Pragmatic Manager”? Johanna is a prolific author - with over 300 articles, 3 well-subscribed to blogs, and 8 books including the classics “Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects” , and “Manage It!: Your Guide to Modern, Pragmatic Project Management”, organizational coach and regular speaker at Agile conferences. In this interview we chat about various aspects of organizational agility with a focus on scaling Agile - a topic close to her heart and soon-to-be-released book Agile and Lean Program Management: Collaborating Across the Organization.
Q You have coached numerous organizations in Agile transformation. What would your top 3 pointers be to management to nurture successful agile transformation programs?
For management the top three pointers are:
1.Focus on the strategic work for the teams, so you can keep teams together. That allows work to flow through the team. This means you have to manage the project portfolio. Ask yourself, “Why is the team multitasking?” Stop that, and you can make work flow through the team.
2.Stop thinking in terms of experts. Sure, everyone has expertise. Developers are not going to become testers, and testers are not going to become developers. But inside development or testing, people are much more flexible than they or you realize. If you give the team a chance, they will surprise you and themselves. Break down the silos!
3.Help the team look for bottlenecks and eliminate them. Too few teams know how to look for bottlenecks in their work. Managers can often see the bigger picture. It’s not about the release date; it’s about what’s in the way of getting to the release date.
Q Distributed teams are becoming more the norm as the global battle for talent increases. How do you make that anomaly - Distributed Agile - work in practice? What is the groundwork required for a geographically disparate team to stay agile?
Respect for each other is the very first piece. If people don’t respect each other, you don’t have a team. How do people respect each other? By delivering value. Facilitate that, and you have a start on a team.
I understand that managers want to take advantage of smart people all over the world. I like feature teams all over the world, not pieces of teams all over the world. You can make a geographically distributed program work with feature teams much better than a distributed project work.
In either case, it’s critical that the people deliver value to each other, on a regular basis, every day. How can they do that if they’ve never met each other? I don’t understand how you can have a geographically distributed team who are supposed to work with each other every day for years, in an agile way, without meeting each other, even for one week. How can they learn how to collaborate? The managers who create these teams are not looking at the value stream.
If you bring people together for one week at the beginning of a project, they will learn how to work together. That will set the stage for the rest of the project and allow them to create value together. It makes sense and costs much less than what people try to do now.
Q What are your main tips to a product manager transitioning from a Waterfall environment to an Agile one as far as product design and roadmapping is concerned?
Right now, in waterfall, product managers think BIG. In agile, product managers have to learn to think small. In waterfall, the roadmap tends to be static. In agile, the roadmap is a living document. Product managers have to learn to make everything small and change the backlog every couple of weeks, based on what the team completes.
This is a huge shift in mental models. It requires that the team gets to done throughout the iteration or that the team works in flow and finishes features every couple of days. It’s a huge shift in mindset.
It also means that the product manager doesn’t say, “I want a box here” or “I want a pull-down menu there.” The product manager has to explain the value of what he or she wants in terms of users. This is another big shift. No wonder our product managers might feel a little crazy.
Q Pointers on identifying and dealing with risks on Agile projects and programs? How does one forecast/sniff out the red flags?
I look at burnup charts inside the iteration to see if the team is finishing something every day or so. If they are, things are probably okay. If not, I get worried.
If the team works in flow, I use cycle time and see if it’s increasing.
I ask the team, “How do you feel about where you are? What risks do you see?” The team is a pretty reliable barometer.
Q Is Agile getting a bit hypocritical - with rigid sprint velocities, ceremonial meetings, ritualized charts and metrics that don’t really matter? How do we get agile back into Agile?
I changed the first question a long time ago when I taught agile, and explained that to my clients. I explained that I didn’t like the emphasis of “working on” because it allowed stories that were larger than stories I was comfortable with. I like one-day or two-day stories. I like teams to swarm around stories. I like teams to change the questions if they don't fit for that team.
So, I changed the question to “What have you completed since the last standup?” If someone had to say, “It’s been 5 days and I haven’t completed anything,” that person needed help. It wasn’t that person’s fault. That person needed the team to swarm with that person.
Agile is about the ability to change. What do you have to do to get that ability? You move a feature across the board. How do you move the feature? By having the team collaborate on moving it. By keeping your work in progress small. By doing your professional best on all you do for that feature.
It really is that simple.
Q What’s your take on SAFe based on what you’ve seen of its practical implementation? What are the alternatives to a methodology to scale Agile?
To me, SAFe isn’t particularly agile. I like release trains, but you don’t get feedback often enough to change the backlog. I don’t like hardening sprints, and building them into the framework says, “You don’t have to get to done all the time. You can take shortcuts.”
When I teach agile, I teach swarming. Because I teach that, my clients don’t know about hardening sprints. They only know about small features that are totally done. They practice with me, so that when I’m gone they know what agile feels like.
I know that sometimes they are not going to be able to do everything and they will put a card on the backlog. We discuss that. But a whole sprint worth? I don’t think you should plan for it.
When you work in a program, you want to have a small batch size. You want your features to be as small as possible, and to integrate them as often as possible, all over the program. You want the system to be as releasable as possible as often as possible. With hardening sprints built in, you don’t get this.
But I’ve done this for years. Why would I transition to agile and lose this for programs? I don’t understand.
I don’t understand all the prediction required in SAFe. I don’t understand the way they want to manage the project portfolio. I wrote a book about managing the project portfolio that is much easier to understand: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects.
To me, SAFe is hierarchical, which goes against the spirit of agile.
Q Can you tell us more about your upcoming book?
Sure. “Agile and Lean Program Management: Collaborating Across the Organization” is how you bring the original principles of agile and lean to a program. When you tell people the results you want, and people understand what agile and lean are, they can make an agile and lean program. You can change the backlogs as you create the product. This is necessary for managing the project portfolio and responding to disruptive change.
Is it easy? Of course not. Is it for everyone? No. It’s for those organizations that say, “Yes, we are willing to commit to the discipline of agile or lean in our teams. We want the magic that those collaborative teams bring to an organization. At the same time, we need the guidance that program management brings, so we bring a product to market.” It’s a fine line.
I have a section in the book for those organizations in the midst of their agile journey who want to know how to manage a program that’s partly agile and partly waterfall, because I am nothing if not pragmatic!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.