Getting onboard with Agile methods across your organization is no small task. To do it well requires knowledge, culture change, and practice — lots of practice — at all levels.
Rally is fortunate to have some of the most experienced practitioners in the industry. Their broad experience working onsite with customers and their deep knowledge of Agile practices, organizational culture, and human behavior only excites in them a deeper curiosity and eagerness to learn. As you can imagine, this makes them great advice-givers and storytellers!
Recently we assembled a few of these Agile aficionados (Agile Coach Tamara Nation, Transformation Consultant Eric Willeke, and Services Product Manager Ronica Roth) to respond to some of your toughest Agile questions with their advice and stories. You can listen to the whole terrific webcast of their conversation here, but below we share a few things we learned from their chat.
You Can’t Innovate Until You Can Execute
ERIC: A lot of the language I'm hearing with executives and business partners around the IT industry is all about, “We need to innovate more. We need to do more of this, more of that.” I fear that people are losing sight of the need to actually be able to implement those ideas and operate the businesses effectively once those innovations are brought to market. A lot of the focus I help organizations drive early in their transformation is to stabilize your implementation capability. Stabilize that execution organization that's able to build those new ideas, able to bring them to market. Then use that as the base from which to start to launch innovation and start to disrupt the markets you're in, and move the business in the places you want to go.
TAMARA: I see a similar trend, especially when I'm working with really large organizations that have organizationally institutionalized impediments. You know those silos that we're always talking about? I feel like I've been in a lot of conversations recently where IT and development folks are pointing the fingers at “the business” … when, really, we need to be able to deliver predictably. We need to be able to deliver quality products.
Agile Ops: Upfront Architecture or Emergent Design?
ERIC: At least in my mind, the real purpose of architecture is to ensure that an organization is in a position to take care of future opportunities, be ready to seize those and have the technical infrastructure, the technical platforms to put the company where it needs to be in the future.
One of the things that architects need to be good at is the capability to see around the corners, to anticipate that beyond the current need, beyond what we're building now, what are we going to be faced with on this platform, and in this environment, and in this market in the future?
Sometimes that means overinvesting in flexibility early in a platform. Sometimes that means closing a platform so that you can milk every last penny out of it at the lowest operational cost. But first and foremost, it's to help take those needs and convey them into the organization in a form that allows you to articulate the trade-offs and steer the decisions that need to be made by the teams moment to moment.
The flipside of that, and this is where the emergent architecture aspect and emergent design aspect comes from, is most architecture groups can't move at the speed of development.
Once you achieve that execution engine, once you have a development organization that can push out high quality software week after week, quarter after quarter, nobody can predictably say, "Here's what design you need." We want to ensure that the development organization always has a direction that they can go that they know they can implement at full speed and not cause things to break, not go off the rails and cause huge operational costs or poor flexibility or challenges down the line. That is the tension and the balance that we're looking at when we talk about the intersection of intentional architecture and emergent design.
A lot of the ideas around service-oriented architecture and now the DevOps microservices mindset are really taking balance and pushing it to the extreme where it's in smaller and smaller groups that have both skill sets and both mindsets and decentralizing that decision-making around architecture. It's a continuum, but it's also a very careful balancing of those two forces of predicting the future and moving at full speed today.
TAMARA: I think the other thing I look for, Eric, is, can we start to build a group of people who can make good architectural decisions? I 100 percent agree with that paradigm. It's really systems thinking. How can we set up an environment where our teams can be successful? What are the guardrails? What are the performance ‘ilities’? What are the things that this system needs to be able to do and how can I create architects of the future, for instance? How do we have that architectural skill set in each of our Agile teams?
ERIC: I like what you said there, Tamara, because it really indicates that we all think that we're past the day of fire-and-forget architectures. It's no longer at a point where you can define "the architecture" and then move on with life. The people need to be embedded. They need to be engaged throughout the development process and probably into the operations stage of any major platform. It's not an up-front activity by any means anymore.
How Big Room Planning Pays for Itself
RONICA: I know you guys have seen the release planning or big room planning where we bring everyone in a delivery group or release train together to plan a quarter's worth of work. What are some experiences you guys have had recently where that event has had a radical impact on a group's ability to execute, or what resistance have you seen?
TAMARA: I think the number one piece of resistance I see is about, "Well, I can't afford it, we're too busy. People need to keep working, so I can't possibly get everyone together to do this big planning exercise." This first time is scary because the upfront investment looks big. The downstream benefit's harder to see until you've actually executed the event.
ERIC: The same thing for me. Cost, cost, and cost are always the first, second, and third complaints. Generally it's travel costs, followed by the cost of the time of the people, and then the cost of distraction and planning are the three types of costs that I hear people concerned about.
TAMARA: Have I ever seen a time where bringing everyone together and talking about our work and our priorities didn't yield a significant either cost savings or we were able to see a risk and mitigate it earlier in the process? I can think of one example with a particular Salesforce implementation. That's a lot of configuration, those types of implementations. They realized, "Oh, we're configuring the exact wrong module. [laughs] We'll never use that one, so why waste our time doing that?" That was $100K savings from a real quick conversation. I saw it happen in front of me. I don't think you could even monetize the value from bringing those people together.
ERIC: I don't think I've ever seen one where there wasn't at least one directly attributable learning or discovery that didn't pay for the cost of the event in terms of travel and logistics and everything else. That doesn't even include the real outcome of the big-room planning, which is to create an organization and a group that's ready to deliver that plan. Like the classic saying that "planning is invaluable, the plan itself useless." These groups come together and the people that are excluded, in my experience, you can noticeably see over the next 10 to 12 weeks that they're at a distinct disadvantage in their ability to contribute compared to the people that were in the room.
Planning and Continuous Delivery Are Not Mutually Exclusive
RONICA: Why a release train and a continuous delivery model? If we're doing continuous delivery, why do this by quarterly plan, that look-ahead?
TAMARA: The whole planning event is designed around, What should we be working on? What's the next right thing to do, and what do we need to know to get that done?
ERIC: Yeah. A lot of us, I think, recently, have been reading Patrick Lencioni's new book, The Advantage. In all of his language about organizational health, he really drives those four principles all back to clarity and providing intense clarity among the organization about, What are the goals and how are we going to accomplish them? Beyond what that book offers, the big room plan, to me, is such an amazing opportunity to get a much larger group than you normally would be able to enrolled into the same clarity of intent that at least we're all operating off the same view of reality. We believe we're all moving to the same direction. Sharing that clarity and sharing that alignment is so powerful for the day-to-day execution that needs to follow starting, generally, the day after planning, like the Monday after planning.
TAMARA: The continuous delivery is an important part of that. Things are moving quickly, the pace and people's expectations on our ability to deliver new things, respond to changes, and fix defects. I was listening to a story from one our colleagues in China about how he submitted a defect through Twitter — the Chinese equivalent of Twitter. He got a response within four hours that they'd received the defect, and he got a notification 10 hours later that it was fixed. I thought, "Wow." Once things are identified, we know that's a priority and respond quickly, that's what continuous delivery's all about.
ERIC: it's so critical for people to remember that, yes, there are still enterprises that are in an annual delivery cycle and maybe a twice-a-year delivery cycle. Something like SAFe and the midrange planning helps them get down to a 10-week cycle. But I think it's gotten to the point where we all assume, of course you're going to deliver faster than that if you can and it makes sense for your business. We forget to say, "No, there's nothing that limits you to deliver once a quarter. There's nothing in SAFe or any of the other larger scaling models that say you can only deliver in your planning boundaries." I know multiple companies that have gotten down to where they can essentially deliver on-demand whenever they have something worth delivering. They do that within the construct of SAFe. They do that as part of their normal sprint planning, is to say, "Yeah, I can create this feature, and this feature will be done. We'll get them through this cycle, and let's go and share those next Thursday, before the end of the sprint."
Agile Metrics: What to Measure, What to Ignore
RONICA: Of course, there are two sides to metrics. One is, How do we measure success of the Agile adoption? Then, of course, there is, What are the good Agile metrics that help us know whether our projects or programs or delivery groups are being successful? What metrics might you suggest avoiding? Talk to me about some of your favorite measures.
TAMARA: I think about cycle time and lead time as the most important metric, because it's going to touch all parts of your business. If you have a really good understanding of how long something takes from the time somebody has an idea or submits a defect, to when you can get that idea into production, that's going to help you uncover all of the different areas where you have bottlenecks, where there are transparency issues inside of your organization.
Interestingly enough, I don't know if Eric's at this place, in terms of Agile adoption metrics, I talk about that a lot less, because I feel like Agile's really crossed...it's crossed the chasm. I'm a little less concerned about their adoption and more on whether there's real, tangible business impacts we're having.
ERIC: Yeah, I've actually taken, maybe, even a step further beyond that and I'm at the point of saying, "I actively discourage centers of excellence and transformation coalitions from having percent-of-adoption type metrics." I find if you start to look at something like the percent of teams that have adopted Scrum or something like that, you actually drive worse behaviors in the organization once you hit a certain tipping point. Because the push is to get people to where you can give them the stamp of Scrum approval or the stamp of, "This team is Agile," rather than focusing on the improvement journey or the business impact that's so much more valuable.
The first-order metric I'm usually looking at is lead time, from an execution perspective: what's the impact? Is it reflected in the share prices? Is it reflected in the large business programs that are using Agile techniques to show more capability and more market presence than the ones who aren't? Then work back to, "What are the factors that drive it?" I think sustainable shortest lead time is a huge, almost number-one goal to get that feature delivery and then cycle from idea identification, opportunity identification, all the way through to business implementation and revenue recognition and can you shrink that time.
That gives you the ability to respond to the market faster. That gives you the ability to learn faster. Then once you get inside of that, almost every metric I use is situational. Is it indicative of a specific impediment or bottleneck that we're trying to resolve in an organization? If so, let's wrap some evidence around it and find the right metric that illustrates what we're trying to do and brings the impact of the problems to some sort of visibility, work to resolve it. Then keep capturing the data.
TAMARA: I feel that there is an addiction to metrics inside of organizations, particularly technologies companies where they feel like, "We're sitting on all this data. We should be able to have really great metrics." I feel like I see so many executives really locked into their red, yellow, green dashboards and that's what they're using to sense and understand where their business is...it's such a temptation to fall back into, "I want the cold, hard facts. I want the numbers," when we all know that metrics can be shaded in either direction.
ERIC: I had a senior leader who has, roughly, 35 teams under his purview. A month or two ago he actually came out to Rally and visited our steering. But while he was in town he actually hung out with two of his development teams that were located in another office. He just took the teams to lunch. None of the management in the middle was present. There was probably a two- or three-layer power gap. He just went to lunch and he came away with a very different understanding and perspective over what some of the relationship challenges were among different parts of the organization. None of that ever finds its way up through the reports or the PowerPoint decks or the executive status boards or anything else that you're going to run into.
Want to hear more? Listen to the whole conversation.