BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Interviews Ronica Roth on Vision, Visibility and Business Agility

Ronica Roth on Vision, Visibility and Business Agility

Bookmarks
   

1. Good day this is Shane Hastie from InfoQ and we are here at Agile 2014 and I’m talking with Ronica Roth. Ronica welcome, thank you for taking the time to come and talk to InfoQ today, would you be so kind to very briefly introduce yourself for the audience?

Absolutely, and it’s a pleasure to be here, thank you very much. My title at Rally is Lead Product Manager for services, which basically means I kind of run or own our catalog of consulting, coaching and training services, I make sure we have the services and the people and the quality available to help our customers succeed with Agile and Rally.

   

2. So in that position it sounds very much like herding cats?

A little bit, we strive the Rally to have, we have an incredible group of consultants and coaches who have deep experience with Agile, they all have strong opinions and we want to meet that careful balance between independent ideas with strong opinions about what really works, but alignment. We don’t want to send three different coaches to the same company and have them start holy wars and they don’t, ultimately I think we are aligned and a very practical group when it comes right down to it, getting to the principles and finding, as Scott Ambler said earlier today, the practices that work best in this context.

Shane: Excellent. One of the things I suspect that you are getting from that position is you’ll be seeing a big picture across many organizations.

Yes, absolutely, it’s exciting to see what’s been happening, I’ve been at Rally for almost 8 years and I’ve been in Agile World for, I don’t know, I can quite do that math, but call it 13 or 14 years. It’s been interesting the change and I was a coach before the consultant, I’ve been deep in there but it’s been interesting the change as I look at the customers, companies we’re engaged with now, they come to Rally, they are used to come to us to have us help them pilot Agile in small teams and kind of figure out what they want to do. Now they come to us, they’ve already done these pilots on their own and are coming to us saying: “Yes, we know it works, we know this is going to make a difference, help us go all in, help us go big”, so we are kind of more often than not going right to the how do we scale this thing and make it work.

   

3. What is “scaling”?

That’s a million dollar question right now, isn’t it? Well so that was the talk I gave, vision and visibility, structures and strategies for scaling Agile and for me it means I guess, it sounds so jargony I wish I could think of a better way to say it, but it’s about scaling up and bigger, so more people using Agile to deliver on bigger things, so that’s what I think of with scale and to do that without losing the effectiveness, the productivity, the throughput, so what do you think about when you scale a platform, it handles more but remains efficient and stabile and performance and all those things. So I think it’s the same thing, so scaling Agile is about getting to Agile in the large; by definition in therefore means getting beyond just the development organization or development and test organization, so you start getting into DevOps on the delivery and you start getting into how you think about product and portfolio management, sort of feeding what is the work we are doing, so there is an element of that too, so you are scaling sort of in the layers of the organization, probably falls short of what would call business agility which is a topic where I want to come back too, so I think that’s what scaling is.

   

4. Ok, so you mentioned your talk vision and visibility, do you want to give us a quick summary?

Yes, I’d love too, takes a couple of times delivering a talk to really get it, I feel like this is my third time and I though really good about it and had a lot of people tell me they connected to it which is nice. So essentially and I started with a metaphor of an avalanche training class I did about 2 winters ago and I talked about the structure you have to have in place, so your team of people you can’t go back country skiing on your own, so what’s the equipment you bring, how you are going to communicate, who carries what so you have enough, making sure you have the avalanche equipment, that is the right quality all that kind of stuff and just sort of setting yourself up for success with everything you need to have for you and communication among the team, if one person goes down on that slope, how are they going to communicate back follow me or don’t follow me. So all of those things and then we also learned about having a plan or a vision for what kind of day you’re trying to have in the back country, if everyone is not on the same page you might have the person who’s trying to kind of do death defying and the person who wants to just kind of go out for a nice stroll and if you are having that battle while you are out there, that’s too late, so kind of having a goal or a plan for how to get there, plan A and plan B, and then finally the last piece was, I mean the whole training ultimately when we got out in the field was about learning, how do you read the signs, how do you throw out your plan, so that you can meet your vision for the kind of day you want, which is ultimately one in which you got to go home at the end.

Shane: So it is useful

So how do you read the signs, how do you read the snow, how do you read the conditions and all that stuff and it’s a perfect metaphor for what we need to do Agile at Scale, so I talked about structure, I started with structure. Someone asks me a great question at the end: “wouldn’t you have to start with vision before you can define a structure” and I was like and I realized, yes, and I should it said that, I only started with structures because was easier in the flow of the talk, but like Allbright says, your structure has to follow the vision, what is it you are trying to build, what is it you are trying to accomplish giving that the structure we need. But the structure piece ultimately is about, so when you are scaling you go from teams planning sprints, then first you need the majority that those teams can do mid-range planning, plan three to six sprints out, some kind of predictability and then but if you want to build something that takes a hundred people, then you need ten teams, ten Scrum teams or twelve Scrum teams and they all need to be aligned so we’ve got to get them aligned on the same cadence and synchronize them, we need to add some structure to help them communicate Scrum of Scrums, product owner councils or product owner teams.

And when you start getting into that alignment and that cadence and getting all of those teams doing mid-range planning together, then now you are beginning to look at something that looks a little like the Scaled Agile framework or some form of it; it doesn’t have to, but the pictures I have in my slides, the pictures that I’ve had for a long time and I look at the big picture of SAFe, it looks a lot like what we’ve been drawing, what we’ve been doing with people, but we don’t make cool drawings like Dean’s group, but.. And the other thing I talked about is what gets in the way of creating that structure or what often goes wrong with that structure, is we want to set up the teams to be able to coordinate well and still maintain that throughput right, our performance to be at scale but be performant and the things that getting the way of that I think are, so we could blow up our silos to do some pilot teams but are we really ready to blow up our silos for a hundred people, are we really ready to break out of a project mentality where we are assigning resources to projects and instead get into a product mentality where we were flowing work through teams. Are we ready to change, I’ve worked with companies that have component teams, they look at their, it’s Conway’s Law, they look at their architecture, look at their system and they can imagine not having component teams, because these guys are experts in this part and these guys are experts in this part and how can we possibly break that up, but as soon as you have component teams, you have a million dependencies, nothing gets through without everybody and it’s hard to be performant with those kinds of dependencies.

On the other side were used to specialization, you only have some many UX people, you have so many DBA people, you have some many, I can’t possibly have cross functional teams that mix those folks up, but then those specialists teams become bottlenecks, in classic kind of lean flow. So I’ve watched a lot of companies try to scale Agile and kind of start to sort to get there but they try to scale like a platform, is like the performance goes way down because they have to fundamentally change the way that are organized. So I talked a lot about that and I had a worksheet in my talk where you kind of, at a high level in a rough sense, what’s the kind of work you do, what are the teams you have for any given piece of work, what are the teams that have to work on it, start drawing lines. You’ve got a lot of lines, you’ve got a lot of dependencies, can you begin to rethink your structure and I’ve had a couple of people come to me and say: “That drawing is what’s going to help us change”, that’s the proof point. One guy said these coworkers were starting making the drawing and coworkers said: “That’s why we can get anything done”. That was gratifying because was exactly what’s been happening. So structures, if you try to get the right structure, and you won’t get it right the first time, I don’t remember if I remembered to say that out loud yesterday, perfect is the enemy of the good, where a learning organization get started, try it, see. The vision piece which really should probably precede that is, for me it’s to, it goes both ways, what is our vision, what do we really trying to accomplish, what is the work, what do we try to do with this product, what do we try to do with this system, not just what do we try to build this year but as a business goals ideally and how that come down into therefore what initiatives are working on, therefore what features and therefore what stories and I really want individual team members to be able to connect all the work they do back up to why it matters and in my talk rather than just talk about initiatives or features or epics or whatever, I kind of went all the way up to what Rally does in terms of our corporate strategy which is to talk about “true north” and “mother strategies”, and this goes far beyond what software we build, it’s a true north for the year of where we want our company to go and the mother strategies are kind of our strategies for how to get there[ it comes from “doing the right things” is the name of the book, I can’t think of the author. This idea of true north and mother strategy and then from the Rockefeller habits we have rocks, so in quarterly planning 20% of the company participates in all in, again not just software planning, work planning but strategic planning, what rocks, what cross departmental large efforts do we need to charter in order to move the needle on our mother strategies.

So I really challenged people to be as participatory as possible with that kind of strategic planning, but at the very least really focus on communication and again, it ties to what Diana was saying this morning in her keynote about purpose. I want every single person to understand why they do what they are doing and not everyone, maybe not everyone can connect to the corporate strategy but I challenge you to, challenge you to have a corporate strategy that folks can connect to and test for that. So on the vision side, and we talked about some examples and then comes the, so now you’ve got this visibility, ok here is how is my work, so because of this strategy here is some work, execution work we are going to do to implement that strategy. So there is an example of one time in quarterly steering we realized that to implement a strategy what we really needed to do is give the users some love in terms of what we are doing with our product and so customer love month was introduced and the whole prioritization and planning happened to figure out what’s the most we can get done and I think it got extended beyond a month because we were liking it, but if we really focus on making users super happy, what would be prioritized, and that was a powerful experience. And then it has to go back up, it can’t just be information down about what work we do, but information back up about how realistic is that work, can we implement our strategy and so you go down to a lower level of planning. I forget exactly the other example I used, without my notes in front of me, but it was an e-commerce, we tried to do an e-commerce thing, that was the strategic thing, they go and do the planning again in R&D and it becomes really clear that is, the things included are all out of whack and out of alignment, it wasn’t even like we can do it or we can’t do it, it was just more like this is a collection of ugly, this is an odd collection of stuff that isn’t actually going to move the needle on the reason we are doing e-commerce, and so that was the information back up, well let’s rethink all of this.

Shane: The ability to feed back up.

Yes, the ability to feed back up, absolutely. And the last piece is usability and a lot of people try to figure out what metrics do we need, how do we measure, how well we are doing at scale, or measure or see the work, but I really wanted to focus on visibility as a tool for decision making, Don Reinertsein in Product Development Flow, one of his principles is to decentralize decision making, to centralize decisions that are made infrequently and are unlikely to change, so the true north mother strategy would be an example of that, we don’t change that, it stays for a year. But decentralize everything else because the people closest to the, the people sort of closest to the hands on work have the most information, so let them make those decisions, plus it’s more efficient rather than waiting; so how do you do that? Well… and it goes back to the other element, if I can really visualize how my works ties to the vision, then I can make better decisions as we are being Agile and discovering and learning and breaking work down, and decomposing work, I want every single person to be able to continually do that check, are we still in line, are we still aligned to what we are trying to accomplish. So what visibility, what kinds of visualizations and information do you need to help with those decisions? Same thing with structure, it kind of goes back to structure, if I have a bunch of component teams, how do I help any given individual understand how to deal with some problem. Well if it’s a million dependencies, no one person can possibly see it, visualizing what bottlenecks are becomes much more difficult. So anyway going back to that whole worksheet thing we talked about, so instead of just being about metrics, it’s about enabling decision making, enabling everyone to own continuing to get work through, continuing to stay align to strategy, learning things that we need to provide feedback to other people.

So I gave people a chance to think about what kind of information would you want to have if that was your goal, which is also powerful and I was about to give shameless plug for Larry Maccherone work around insights in Rally. Some of what they are doing is about that kind of visibility, so a lot of its visibility for actionable continuous improvement, which is probably side topic compared to what my talk was but I do think it’s an exciting opportunity and again I want to go back to Diana’s talk, when we are empowered to collaborate on work that has meaning and where we get things done, then we begin to have a job that we love.

   

5. Thank you, really interesting talk. One of the points that you, one of the topics that you touched on was Business Agility, what do you mean by that?

What do I mean by that? For me Business Agility is about that getting beyond just software development and even getting beyond making software, so all the pieces part of that, but into an organization, a whole organization, whole company, whole division that has a mindset and an ability to sense the opportunity, sense what’s happening in the marketplace, create, build and then respond to change. So we see it the small, a team that is working on users stories and work that isn’t yet started, that’s why we can shift directions because the things that we haven’t started we haven’t started. It’s a little like I want a whole company that thinks that way, but how can, you start looking for opportunity, what would make us more nimble, how would we’d be more able to react if something expected happen to this year, if a new competitor jumps out of the woodwork because it’s so easy today for new competitor just make and app and it’s only cloud and it’s out and version 1.0 is maybe not perfect but it’s lean, is not overloaded with features and whatever it is, it’s a threat, what if that happens, and how I set up companies that have true agility as we can change, we can react, and so it’s a company that works in smaller chunks, makes smaller bets, doesn’t commit to a one year or two year detailed plan that set them up to be measured more and whether they achieve the plan rather than whether they achieve results. It’s a company that values feedback in all of its forms, how could I know more, I’m always asking the question I assume I don’t know enough, I assume I don’t know everything, how can I know more, how could I connect to my customers to know more about how they feel about us or our product, what could I build now that we test them on the right track and get more feedback, that that’s sort of, it’s another element and that sort of sense and respond piece, or I say well I want to build a little something and get feedback and decide whether to build more or move on, change directions. That to me is Business Agility, I think that’s a much bigger opportunity, it’s not just about, I mean software is the most powerful place for it because of the way we can build things, I can turn on a dime on my software easier than on my tractor although John Deere’s a highly Agile Company. So I think that’s an exciting opportunity and it’s an entire company where people feel connected to purpose and know how to align the work to the strategy of the company and are able to work collaboratively and empowered to make decisions because they have the right information, so all the things we’ve been talking about but for the whole business.

Shane: That’s a challenge for many organizations.

It’s huge, it is a challenge but so was Agile Software Development in the beginning. So sticking to software companies I think about a leader, a CEO who says: “Yes, I want that kind of company, I want a company that is resilient to disruption or they can, even though we’re big, be a disrupter, expand our market and so, at the very early end I can look like kind of Jeffrey More, we are going to make an intentional investment in innovation and although we use traditional Agile Software Development, how you like that, it’s people who like the traditional or Agile, I’m going to go with traditional Agile, or we are doing Scrum or Scaled Agile/SAFe something over here but then in our innovation lab we are using Enterprise Lean Startup and running completely differently and being measured completely differently and so Lean Startup principles inside the enterprise to innovate, so that’s one piece. There is another piece at the portfolio level, can I begin to just, I’m not going to approve a hundred projects in January, I’m going to have a running backlog and assess value and what that look like, all of that ultimately although, is what the innovation level we can do it anytime, but all that kind of Business Agility at the highest level is best enabled by execution agility I think, so it goes back to really enable that kind of decision making to be able to respond to change, if I have Agile Execution working at scale then I enable all of that, so although it is a long journey and I think we haven’t solved it, by any means we haven’t solved it all and I’m very excited about what people at this conference are thinking about. The steps to get there is still the stuff we’ve been talking about launching programs, agility at scale, again meaning that it’s a larger group but it’s still performing, still has throughput, still has quality, we are better and better in building the right thing. I think maybe the differences is it a VP of engineering who wants to do all of that or a CEO who wants to do all of that and how much more can we do if we have the support of that CEO who has a vision around agility, agility as in I can move.

Shane: Ronica thank you very much for taking the time to talk to us today, that’s some really, really interesting stuff and quite inspiring!

Cool, I hope so, I certainly get inspired here, thank you!

Jan 02, 2015

BT