The Ugly Truth About Scaling Agile

Congratulations. 100% of your developers are now practicing agile. You have a stable, predictable velocity and even your CEO knows what a scrum is. You’ve scaled, right?

Wrong. The ugly truth about scaling agile is that no matter how many individual teams practice agile in their own unique ways, scaling “wide” without scaling “up” means that your organization as a whole still lacks the transparency, alignment, and collaboration necessary to gain the benefits of agile at scale. This webinar addresses the ugly truth about scaling agile to the enterprise; uncovering 5 truths every executive should be aware of before embarking on their agile transformation journey.

View the Presentation Below

Executive Summary (Transcript)

Ben: My name is Ben Lack and I’m on the marketing team at cPrime and joining me today to go over the session is Scott Blacker, VP of Products and Services at AgileCraft and Kreisler Ng, Senior Manager of Agile Delivery at cPrime. We’ve got quite a few folks joining us on the session, so I want to go through a couple of housecleaning items before I pass it over to the guys. First, the session is being recorded today so you’ll have the opportunity to review and share with colleagues after the session and we will be sending along a PDF of the slides after today’s session as well in email so that you can reference it as well. Any questions for our presenters or if you are having any trouble with anything, please go to the Q&A box and shoot me a note and I will pass the question on to Kreisler and Scott after they’ve both finished. So, without further ado, I’ll go ahead and pass over the ball to Kreisler. Kreisler, take it away.

Kreisler: Thanks Ben, hey everyone, this is Kreisler Ng and as Ben let you know the senior manager at Agile Craft over at cPrime. So a little on cPrime, Inc., we’re an Agile Consulting Company, we’ve been around for well over 10 years, Fortune 1,000 company and internally, we’re just really big firm believers that a transformation needs to be looked at holistically in order to make your organization and teams extraordinary.

Scott: Thank you Kreisler, my name is Scott Blacker, as mentioned I’m the VP of Products and Services at Agile Craft. Agile Craft is an enterprise software company; we help large organizations scale initiatives to all levels of the organization. So, kind of a fun aspect of that over the past month or so was that we were actually named the number one small business to work for in America by Fortune magazine, which was awesome. Since I work out of my house, I joke that my home is the number one place to work at in America, which is great.

To get into the webinar here, we’re going to share with you today a number of ugly truths that are born out of the experiences that Kreisler and I have had helping organizations scale Agile. We all know the quote from Marc Andreessen that “software will eat the world.” And in fact, the increase in software development activities among large organizations is really a major contributing factor to the quickening pace of turnover within Fortune 500 companies. If you look at this graph, in the 1950s, it literally looks like I’m looking at a black line here 30 years for an organization that was a Fortune 500 company to cycle out and today its the green line, which is just 15 years. Its not just tech companies. So the top five companies in terms of market capital last month were all technology based, Apple, Facebook, Amazon, Microsoft. Software has become a strategic asset at nearly every major corporation. Southwest airlines compete on their reservation systems. Fidelity on the basis of the user experience within their online brokerage. Within almost every large company, it has really come out of the shadows to become a major strategic asset to the organization.

We found this interesting graph which is BCG, Boston Consulting Group, you know, they’ve got their BCG matrix and there’s this interesting insight that 50 years ago, I guess 65 years ago, the number one determining factor about whether or not you were going to be a market leader in terms of profitability was how big you were. There was a 50% chance that if you were the biggest company in the industry, you were also the most profitable and it was a key driver of your competitive edge. Today, in 2013, that was less than 5% and so the insight here is that looking at the factors we just discussed, that agility has really replaced market share as a key driver of competitive advantage. Organizations are looking to take advantage of the lessons that Team Agile has been able to teach them and the improvements that Team Agile has been able to introduce into their core development lifecycle and have those benefits scale up to the enterprise.

So as we look at the generations of agile adoption, you really had this first wave that kind of started in the 1990s and went through the … Roughly speaking when the Agile manifesto was published which was a team level adoption of Agile. The second generation, we look at that as more of a dev ops thing where the benefits of Team Agile were looking to get extended into quality and build and deploy type of life cycles. Really now we think we’re in the middle of the third generation or the third wave of Agile adoption where organizations are looking up and saying its great that we’ve delivered more value, that we’ve become more effective and more efficient at the team level, how do we take the lessons of Team Agility and really infuse that into our organization as a whole and so we’ve seen this whole wave of large enterprises that are trying to literally scale Agile and companies like cPrime and Agile Craft play, from a product and services standpoint, into that evolution.

So given that scale has become so important and given that we know that there are lots of frameworks like SAFe (Scaled Agile Framework) or JIRA (Atlassian JIRA). You would think that and I think organizations do think that they can sort of pick one of these frameworks, train their teams and the benefits of scale will start to be delivered to the organization. The reality is it’s always a lot harder and it takes a lot more time and it’s a lot more complex than you think. Our core focus today is to introduce you to the five ugly truths that are prevalent in almost scaled Agile implementations and then introduce the secret weapons that you can use to help combat these truths to make your transformation go smoother and more effectively.

Without further ado, we’ll jump into ugly truth number one, which is that really even the seemingly simplest aspects of a transformation are massive headaches. Those simple things can be something as basic as semantics and we’ll sort of use that as a first example here where what I call something and what you call something, we may be talking about the same thing, a unit of work, a story, a feature, an epic, a program, a release train, and so there’s this kind of idea that how hard should it be to get fifteen scrum masters to agree that a feature is a feature and an epic is an epic. That’s really not the case when we see that.

So here’s a real common example, JIRA. We see JIRA as a very prevalent team level tool in the market and I’m sure most folks know, JIRA has this thing called a story, stories within JIRA roll up into to epics, and then that’s really what JIRA has but many organizations may then call something above an epic an initiative. Then lots of organizations say okay we want to scale JIRA so how are we going to do that? We’re going to use SAFe. Well, SAFe has a thing called a story, and then this thing called a feature and then this thing called an epic. So what do you do there? When the team is saying well we’ve used JIRA and this is what we call an epic and the enterprise is looking to drive a SAFe adoption and they want it to be simple so they’re just going to take the standard industry terminology and now you’ve got, well is a feature an epic, or is an epic an initiative and we’ve got this thing called an epic but it exists at two different levels so when I say epic is that what you mean? This is not something that you can figure out and say as of now, this is what an epic is. You can do that but it causes a lot of turn.

One of the really ugly truths to be aware of here is that semantics matter, that it may take you days or weeks or even months to really align the organization around a common set of semantics, to even agree how to tool your Agile solution or how to communicate with one another so that everybody’s sort of speaking the same language. There’s lots of other examples here as well. So for examples of sprint start date can be a massive headache, right? I’ve seen holy wars start over whether it’s best to start a sprint on a Wednesday in the middle of the week or a sprint on the weekend. There are 50 valid reasons why you should never go with a 2 week sprint and refuse. Not everything is required, you don’t all have to be on the same sprint cadence but the more you can align from a scale perspective, the smoother that’s going to be and so there’s this constant significant banging your head against the wall in terms of why does it have to be this difficult, why can’t we all just agree that the sprint is going to start on a Tuesday.

Then the same from a scoping perspective, although this is the opposite, right? As teams estimate their work and use Finocchi sequences and say well this is a three year, that’s a five or that’s an eight, its perfectly fine and just about any implementation will have their own sense of what a three is or a five or an 8. The law of large numbers sort of takes care of aggregating that stuff at the higher levels of scale that people at the portfolio levels don’t need to worry about. I can think about a rare implementation we walked into where the question wasn’t asked by somebody on the executive team how do I normalize my team so that a three on team A, a three on team B, is a three on team C. Then driving the discussions around why that’s important and trying to use those kind of discussions with an organization can be just as frustrating. Having presented these, Kreisler will start to talk about now some of the secret weapons that can stop you from banging your head against the wall as you go forth and start to drive your transformation.

Kreisler: Thanks Scott. Yeah, and we can totally relate to this. I spent hundreds of hours in transformations walking through what I thought would be a simple concept but as we scaled, we ran into issues. So secret weapon number one against this ugly truth is create a strong Agile coalition or community to practice. What I mean by strong, that means cross functionally including all groups, it’s not top down, right? It’s not all executives. Its different levels of the organization. Second is it has enough political teeth and power to listen to the entire organization as well as standardization, trainings, town hall meetings, fireside chat rooms, things like that to help the organization move forward. Second piece is the coalition is going to do a lot of listening, so do a lot of explaining and why and from there know when to pick a strong stance or when to listen and just allow a little bit of turn because you want to allow a little bit of experimentation for different groups so as they come to the right decision all together. Then people are more bonded and engaged to battle this ugly truth.

When I think about these secret weapons, I think of a lesson learned where I did not create a strong cross functional Agile coalition up front. We did a transformation a couple years ago, mid sized transformation, about 500 people, across functional teams. Within the first three or four months of the transformation, we were doing well, we had scaled it across various groups, and we had 8-10 teams running scrubs. Then as we scaled more and more across different functional groups, we realized that the semantics were getting lost. Some of the concepts were being morphed or for instance, some of the basic concepts that the earlier teams went on scrubs starting morphing and changing their understanding I guess. We had a scrum master meeting to practice in place but the problem there was it was mainly made of engineering folks and so they lacked executive leadership as well as the political power and teeth to continue moving that conversation forward and so that devolved and derailed our transformation for a good 1-2 months, even something as small as that, until we were able to build a stronger coalition to get back in place on our transformation plan. So that leads us to ugly truth number 2 where a coalition is just a beginning of starting a transformation.

Scott: Great Kreisler, thanks so much and yeah, that’s a good point. That does take us into our ugly truth number 2, which is if you approach your transformation from a top down perspective it’s going to fail. And if you approach it from a bottoms up perspective, its probably also going to fail. The reasons for this are many fold. I think first, Agile has traditionally been a very grassroots movement and so teams of developers themselves, quote unquote, uncovered a better way of building software and really took it upon themselves to reorganize in a more effective and efficient manner to deliver working software. This has worked fantastically for team level Agile and arguably at the program level, right? From scrums to scrums as groups, whether they’re, scrums to scrums let’s call them, organically formed to handle higher level coordination and communication between Agile teams. But organic Agile only works when everyone is Agile and at some point teams have to coordinate with non Agile teams or they have to convince non Agile teams to become Agile or they have to work with non Agile functions in the portfolio, product or finance organizations or they have to convince those folks to adopt an enterprise Agile approach.

That bottoms up approach will kind of hit some blockages if you’re relying entirely on the teams themselves to reach up into the organization and bring product, portfolio, and executive teams on board. By the same token, if executives that are eager for the benefits of enterprise Agility, if they take a top down approach and sort of wave their magic wand and decree that everyone should be Agile, well the teams don’t like that, right? Because the true benefit of Agile at that point isn’t really deeply and natively ingrained in the DNA of the participants, right? Agile itself is a grassroots things and it’s very organic. The thou shalt be Agile approach just by the very essence of Agile is, that won’t work. So, in truth, Agile transformations need to be both top down and bottom up, and also middle out, where the benefits are acknowledged, championed and realized by people at all levels of the organization.

Its important that people at the top of the organization take accountability and responsibility for the things that they can contribute to the overall transformation. As an executive I’m responsible for defining our strategy, for establishing goals, for setting the priorities for the organization to execute against as a team, I’m responsible for establishing a predictable cadence, establishing spend, contributing results to the organization. I think in general, if you can approach it as an Agile transformationist for both the top down and the bottoms up and also if you happen to be in the middle, right? Just sort of starting there and then explaining and extrapolating the benefits to the organization, you’re going to be in a much better spot. At this point, I probably well bled into one of the secret weapons so Kreisler, I’ll turn it back over to you to share some specific tips on people can address these challenges.

Kreisler: Thanks Scott, yeah I think this ugly truth to me really resonates with just if you think of your organization, it’s a large complex living organism really with many moving parts. So, you can’t really just start from the top down or from the bottoms up, you need to work through all levels and frankly take everyone on the journey together, that’s what I like to say and listen emphasized throughout all levels. A lot of people just want to be heard and have a stake in the transformation, so that’s really key as a leader. The last piece, which is something really powerful and really big, to me is as an executive, making it a safe environment to fail in the transformation.

This reminds me of a transformation probably a good five years ago that we were running. It was a large multi billion dollar global retailer and the retailer was trying to enter the e-commerce market, the Chinese market, and so you can imagine this was a top priority for them. It wasn’t very large, couple hundred folks, we were actually piloting Agile in this program as well, but the role was really key around making it a safe environment to fail was within the first two weeks of the program kicking off, we had a VP of products and a VP of engineering get in front of everyone and it was a bit unreal to me and I still think about it as if it was just yesterday. They just said hey, team, we trust you’ll work your hardest and we’ve got your back if things go wrong. We’ll take ownership of that and accountability to the board of directors. It was just really big executives being honorable for the team and saying we trust and its okay to fail. I think from thence forth on, I could see just the body language of everyone, the facial expression on everyone, knowing that they were fully bought into this transformation and delivering this program. Very powerful stuff and frankly I’ve only seen that a handful of times in my career. Now that we know a little bit about the top and bottom, the next ugly truth is more about a ceiling actually.

Scott: Yeah. That does bring us into ugly truth number 3, which is at some point in your transformation, you will hit a glass ceiling and you may not see it coming. Breaking through that ceiling is not going to be easy. I think there are probably dozens of different kinds of ceilings and would love to hear from folks if you want to reach out to me after the webinar to hear about your experiences but three common ones that we’ve seen are what we will call the bi modal ceiling, the finance ceiling and then the management ceiling.

To quickly touch on what these are, the bi modal ceiling is really common, right? It comes into play when as you are scaling either your Agile transformation out to additional teams, or up into the program and portfolio level, at some point you will encounter people that are enmeshed in or married to or don’t want to see a way out of a traditional or waterfall way of planning. This may be within the development organization or product or portfolio, you don’t really know where it’s going to come from. Either the benefits of Agile can be stymied at that level with a lack of collaboration which effectively creates silos or you’ll need to figure out a way to break through that by either stitching together Agile execution with traditional enterprise waterfall planning and establishing collaboration between those two organizations, right? If you’re delivering 50 story points a sprint and somebody looks at you and says I don’t even know what a story point is, are you on budget or not? That’s a ceiling right that you’ve got to fight through and so that can be a problem. Usually that’s an easy one to see as you embark on a transformation because you’re intending to transform those kind of behaviors and drive folks to a more Agile enterprise, Agile approach.

The second ceiling which is also sometimes easy to see coming is the finance ceiling although typically that’s one that people tend to say well we’ll just deal with that later or lets do as much as we can before we have to deal with the finances of it. Actually at some point you’ll hit it and so when you look at things like Agile capitalization of story points and lean Agile budgeting from a portfolio perspective, those are concepts that aren’t necessarily natively understood by the finance department. Unlike your development organization which may be willing to take a flyer on a couple of Agile programs, at large companies, whether public or private, there is very real financial reporting that has to adhere to very standardized gap practices. So getting the finance folks on board to adopt more Agile practices can be a tough thing and its something that you’ll need to be aware of as you plan your transformation and really look to get the absolute most benefit out of the transformation.

The third ceiling that we’ll talk about briefly is this concept of a management ceiling. This comes into play when there are mid level managers, right, directors, VPs, in the development or product organization that have trouble envisioning what their world looks like once the organization has transitioned to a more Agile way of thinking. They may feel threatened by job titles or insecurities so they enforce traditional practices. You may get questions like well if I don’t allocate resources to all the projects that I have, how will I know that its going to be completed on time? So you guys can do what you want at the program level from an Agile execution standpoint that’s great, but I’m going to track it this way, right? Because it’s the only way I can think of to communicate to my bosses and the people I’m responsible to what our progress is.

This, in reality, can be the most insidious ceiling to break through because it’s so deeply ingrained within the development or product organization and you as a transformation agent or as a developer or scrum master is looking to champion the benefits of Agile. If it’s your boss that’s stopping versus somebody more abstract in finance or another part of the organization, it can be very difficult and we’ve seen this in a couple of organizations. I think for sure it’s the fastest way to derail if there’s not strength of leadership coming through the development organization helping to break through and reorganize the management responsibilities in a scaled Agile world. With that I will turn it over to Kreisler to share some of the specific tactics that you might be able to use to break through these ceilings.

Kreisler: Thanks Scott. Yeah, this is a difficult truth in a lot of organizations and what we like to think is you have to meet the ceiling where it is and slowly raise the ceiling, if not eventually break that ceiling. Our first secret weapon is just, as Scott mentioned earlier a bit, meet me in my model. What we mean by that is time for that transition phase of having potentially two models in place allows for some experimentation and to make smart improvements. For instance, if you’re running a high value stream for instance and then compare that to a waterfall project or program or similar size. You want to make that comparison or help finance build a ticket or they’re doing lean budgeting for one program versus traditional budgeting for another. You want to allow the teams to make those comparisons in the groups and then from there, look at the results. From our experience, time and time again across hundreds of organizations, results speak for themselves and that really takes the emotion out of the. You have to meet it in the middle, allow time and then get the results. That really drives that conversation through the scaling Agile transformation conversation forward.

The last secret weapon we like to use is using an organizations informal network. What I mean by that is if you look at your company’s intranet right now, you’re probably going to see a more formal network of mapping titles, so all the way down from a VP to a senior director, director, down to managers, so on and so forth. That is a very formal network of your organization. But what you don’t know is that a lot of things are done via the informal network. A lot of people have a lot of political power and it really doesn’t come from titles. It comes from either respect or just area that they control or expertise that they have. What you want to do is look for those folks in your transformation, map that out or even have them included in your Agile coalition that we mentioned earlier and use that as a way to drive your transformation forward, that informal network.

Really this weapon reminds me of a war story we had when we were doing a transformation of a fairly mid. size org, around 2,000 folks and we had a group of middle managers who were digging in their heels around the transformation. The funny thing was this set of managers only owned about 20% of the product set of the entire organization which they built. The challenge there was they made a lot of noise, highly opinionated and were really digging in their heels around giving up their sense of command and control structures. Again, telling the team, hey this is exactly what you are going to do and by what date, it doesn’t matter what you think. Right. So not really having that Agile mindset. What we did was after some soul searching was that these managers stopped speaking in private 101, what we realized was it was just a sense of fear, right? These managers of what do I do? How do I manage in this new world? Will I lose my responsibilities for instance? Will I lose my title? Which is completely not the case in this new model.

So long story short, we ended up with a bi modal model for this set of managers, almost like bi modal managing where we allowed them to retain some of their powers but we also allowed them to give some autonomy to their teams so they can practice more of the Agile mindset and then next we also used the secret weapon of using the organizations informal network. We had a number of their peer managers in other groups that had moved over and were fully bought in, have them coach them informally around how they’re supposed to behave, how they’re supposed to work, how they’re supposed to start to work with their teams and really provide that service leadership that we see very common in Agile. So, a temporary bi modal model is really a means to an end. When you think about it, it really is a form of self-optimization as you’re entire organization isn’t being Agile quite yet. Speaking of self-optimization, that’s takes us to ugly number four.

Scott: Great, thanks Kreisler. The fourth truth that we want to talk about today is that historically looking at Agile as probably a decade and a half, two decade old, practice at this point, teams have been locally optimizing since the beginning of Agile, since the first transformation started. System optimization is much tougher. If you just think about the way, Agile is a very organic thing, teams want to be the most effective and efficient as they possibly can, right? They work to optimize their velocity to get to an aligned or standardized cadence so they can drive predictability, right? They want to and drive towards standardizing the length of a story so they can be as effective as possible. They’re not necessarily aligned to some of the other system’s thinking. For example, do teams self optimize to reduce the tendencies? Do team self optimize to contribute the most value they can to large order of magnitude items? Or are they largely optimized towards delivering as many stories as can be done in a given sprint? Now, I’m being a little facetious, right? Teams obviously want to contribute to what matters most to the organization and depend on others that are at the program or portfolio, or within the product organization to ensure they stay aligned with what they are supposed to do but organically and in of themselves, teams will optimize towards a local optimization.

One sort of mathematical way to think about this, it’s maybe the case that if I have ten teams in my program and each team does fifty points at peak performance, the teams can do 500 points. If there’s value we get that’s coming out of the work that the teams are doing, and because the teams aren’t coordinated or they’re not working on the right things or they’re not spending enough time making sure that the work they’re doing is tightly coupled to and contributing to the same things that other teams are doing, they may only get 300 points worth of value out of the back end of that process, at the end of a planning increment, program increment. What happened to those 200 points? Well, it may be the case that if each team just did 40 story points a sprint and delivered 400 points throughout the course of the program increment that its a much more and efficient way to build. It delivers more value, each individual team, instead of delivering 50 story points a sprint did 40 but those 40 points were fully realized by the organization, unlike when the teams were delivering 50 but only 30 were realized by the organization.

Now whether that’s a clean cut example or not, or a highly relevant example or not, I’m not sure, but I think the point here is that teams have got to take a systems based approach, they’ve got to recognize that they’re part of delivering something as a whole and I think that the image that we have here and on the next slide kind of captures that where you’ve got a team and the individuals on that team, they’re not rowing in different directions, they’re not all over the place, they are all going in the same direction. The boat here is optimized to going as fast as possible but once you start to incorporate this team and look at it in the context of a larger organization, that might not be the optimal thing to do. With that, I’ll turn it over to Kreisler to sort of talk about some of the secret weapons that can help you drive that alignment.

Kreisler: Yeah, Scott. Exactly. The imagery on the second slide speaks to what Scott was just mentioning about the rowboat example. Now the image we have here is really, in order to save a life or handle an emergency response environment, you need to require a team of teams that are moving together, that are in alignment. Secret weapon number one here for this ugly truth is you want to paint the big picture. Focus on the whole, have continuous conversation about continuous alignment of the goals, what’s our purpose, what’s the mission statement of the organization, what are we trying to achieve. I like to think of it as metaphorically, what some teams have a hard time understanding, I like to use a freeway account. When I’m driving and getting from point A to point B, I’m trying to go the fastest I can, which usually I am. I may break early or I may speed up too fast, and again I’m optimizing for myself, but again that doesn’t optimize for the entire system. As we know, they’ve done studies on this, exponentially when somebody breaks early on a freeway. For instance, it has various ripple effects that you don’t see throughout the freeway system. You want to paint the big picture.

The second piece, which is related to the big picture, is link the local data to the organizational wide base. So what I mean by that is for instance you have scrum teams, you may have certain metrics like velocity for instance or information atrophy, somethings that are localized to the team and what you have is also larger wider organizational KPI that you want and you want to link the two and so I think Scott was mentioning that a little bit of an example, if you have a team that’s, lets say, overloading their spreadable or for some reason that are [inaudible 00:31:54] and they are just turning out [inaudible 00:31:58] but at the end of the day, you want to make that conversation around [inaudible 00:32:03] because that helps the overall organization or if you’re working in a team of teams. If other teams can’t keep up, is that really helping out the overall goal of the organization or the KPI.

The last piece of this is focused on what we call Agile HR and really simplified, this just means inequalities that’s really the focus and instill more of a culture helping each other out. I think that’s really key, and this might be able to store agile information working with the best teams and if I met team members in the team at the time. They kept telling me you know I understand what to finish as a team or really as an organization but my inner goals or my team goals annually are based off of my director and they don’t necessarily allow the entire organization. Alright. So this fits cleanly with self-optimization for me. I would get HR involved but that wouldn’t help the discussion and it probably would have slowed the transformation down so as just to move forward we got a chance to speak to the director and he eventually, just informally the director was able to incorporate in her feedback form just informal feedback and overview feedback across the teams. So that really helped and was a step in the right direction until we could get more of a formal HR idea of self-optimization. Moving on to ugly truth number five, it’s another form of self-optimization but it’s for very different reasons.

Scott: Yeah. This ugly truth is kind of a difficult pill to swallow. Its one that can be a little more hidden within the organization because teams might not actually be telling you or saying out loud that they don’t think this works. There may be hidden fears or concerns that are embedded deep within the teams. Uncovering whether or not this is the case in your specific organization and then determining what you can do to combat that ugly truth is pretty important. There’s two main reasons that we see teams unconsciously not wanting to scale.

The first is via transparency right? Transparency can be great. When you look at what you’re trying to achieve as an organization and the empowerment that you can deliver to engineer by letting them know that working on it is important and they can see how the story, that they’re working on, is linked to a feature to an epic to a theme to the mission of the organization can be very empowering but it can also drive a lot of accountability. It can reduce freedom for developers to do what they want. Can the team work on tech that they wanted to or the code refactor to the extent that they want to if every story that’s being worked has to link up to a feature to a theme. It may be the case that you’re not going to be able to work on as much refactoring as you felt was important or maybe you now have to go and champion an investment in tech or refactoring work instead of just doing it on the side and you don’t want to have to deal with having the conversation. For sure, that scaling Agile does result in a sense of transparency and does drive accountability, which could be a great thing for the teams but can be a little bit scary.

The other thing that underlies a lot of fear is this well, you know, if we’re transparent then how are we going to be compared. An egregious example of this, which I’ve never actually seen but if you can imagine. If I’m an unenlightened manager if you will and I’m looking to drive the most story points I possibly can throughout an organization, I’m going to measure the number of story points that each one of the teams on my release training deliver, and I’m going to compare it and I’m going to find the team that delivered the fewest story points and they’re going to work the weekend and make it up. We’re going to continuously drive the teams until every team is delivering four more story points. Well, we know that’s a completely ineffective and unenlightened use of metrics.

If the teams feel that the folks that are using the metrics are using them for ill guidance reasons or an unenlightened reason that are used for comparative or punitive practices, then they’re not going to want to be transparent or sure we’ll be transparent but they’ll game the system. Now everything that used to be a 3 is now a 13 and that’s how I deliver more story points. Its this concern that if I get compared, what’s going to happen. Are you using the information to drive the system performance and improve the optimization of us as a whole because we trust each other or are you using it to punish me or compare me. Getting to the root of that and really having those very enlightening to very raw conversations can be a difficult thing, but it is the truth and teams may say they want to scale but you’re really get to the heart of it and ensure that what they really want and the fears that they have aren’t driving or prohibiting you from scaling as a whole. There are some specific things that you can do to account for this.

Kreisler: Yeah, it’s a sad day when competition and transparency become a means to penalize rather than to motivate. The first secret weapon is you want to collaborate with the teams and explain why being transparent is important in helping assure alignment with the rest of organization. A key conversation that we like to have is explaining the trade off to the team. For instance, if they’re less likely to be transparent about what they’re building or what they’re working on or how fast they’re doing it, there’s a good chance that they will be misaligned with the entire organizational goals, their quarterly goals, their annual goals. I’ve never met a team or individuals who want to work on something that might not be used or even isn’t that important to the organization at least immediately.

The second secret weapon is to build trust between executives and the teams. If you have an environment that Scott mentioned where executives are comparing metrics, using a form of low optimization, using as more of a punishment, I think again explain to the executives this is really stressing the wrong incentive for system wide optimization and in just thinking about it now, I have a good example of a VP of engineering once I was working with would do that, would actually chastise his team in front of all their peers. I’m talking about a town hall meeting of 80 or 100 people and ask teams what their velocity was. That really took a hit for us and the morale in terms of the transformation and moving forward.

We had to a lot of talking with this VP and explaining, not once, this was multiple times over a month or two, around points aren’t meant for comparison. The means to an end, but you really want to focus on and what should be really important to you is about predictable, consistent, value delivered. The predictability of every single spread. That’s what you want to focus on and so positioning that conversation really had the light bulb turn on for him was re-positioning that conversation again around predictable consistent value. That’s really what to focus on. The second piece was we just had the VP frankly stop asking these questions, these very tactful questions in such a large audience and ask more different questions around the certain leadership around how are my teams doing? What can I do to remove roadblocks and impediments? Then as soon as his [inaudible 00:39:52] teams started hearing that, we started picking up the transformation a lot faster and adoption was a lot easier. So that wraps up the last ugly truth and the secret weapon.

So to summarize, I’m just going to go through a key segue for the key secret weapons we like to use is number 1, use the Agile coalition, build that strong cross functional coalition that has teeth to drive conversations and discussion. Two, start from the top and the bottom, don’t start just one way, again you’re organization is a really complex living organism so you need to attack it in multiple ways. Three, plan and meet me in bi modal, so plan for that, plan for that model, its not going to be cold turkey overnight, its going to be a process so once you do that comparison, the results will speak for themselves. The next secret weapon is paint the big picture and you’ll have to do this continuously, I think a lot of times I see confirmations where they’ll say we’re going Agile transformation and then you won’t hear anything else for months on end, so you want to continuously make that big picture. Lastly is building that trust across all the different groups. I think that’s key as one, everyone emphasizes and understands each other’s work functions and how well they relate, people will move forward in the transformation. That wraps up the key parts of the webinar, so I will pass it back to Ben for Q & A.

Ben: Guys, thanks so much for that session, it was super helpful. We’ve got a bunch of questions that have already come in so I’ll go ahead and do that. Because we still have a few minutes, for those on the call, if you have additional questions that you want to ask, feel free to send them our way and then I will be sure to ask them. The first question that I have is there a specific scaling Agile framework that will cover some if not most of the scaling issues or ugly truths that you guys presented today?

Kreisler: So Scott, feel free to jump in, I’ll take a first stab at it. To me, I think all the frameworks, are I think if you notice we don’t really focus on the frameworks because to me they’re agnostic. I think the frameworks, all of them are good starting points because they have been time tested through the years as well as different patterns and motivations. There are common patterns you want to start with but again it’s just a framework, right? Its a starting point and so the ugly truth regardless of what framework you choose or end up choosing or experimenting with, you’re probably going to run into an ugly truth and you’re going to need a secret weapon regardless of which scaling framework you’re going to choose.

Scott: Yeah, I totally agree with that. The ugly truths themselves are framework agnostic because they are things that are kind of core to the organization. SAFe is obviously one that’s got a lot of commercial adoption, DaD and LeSS are well known frameworks. There are folks that we see adopting various aspects of the modified model but I think the point holds that regardless of the framework you’re using, you will run into these things and leveraging aspects of the framework and also some of the secret weapons here can help you break through.

Ben: Terrific, thank you. What types of deliverables or artifacts due to like to use to paint the big picture to an organization or group or even some type of a team?

Kreisler: I’ll take this one too as well, first stab at it. I think what I like to use is just if you’re a product serving organization, I think the key mission, the vision they’re building, depending on what type of product thy are trying to build, align that with the product road map as well as KPIs or levers  that the teams can see is very important. I think that’s, again painting that big picture, it also helps not just development teams but when you go to different functional teams like even finance, marketing, you want to use the same artifacts, whether it be a product road map, favor that. There’s another piece to that I like to talk about is, more and more which seem that scrum is, imagine if I didn’t subject to the picture, NBOs is a fairly old management style. We’ve been playing around with OKRs, objective and key results which a lot of the tech companies use such as Google or LinkedIn, that also helps align quarterly goals and we do that for our confirmation so that we make sure that everyone is moving in the same direction as well as they’re all bought in to the same metrics.

Scott: Yeah, we use a lot of the same artifacts and I think that’s, for us, those artifacts are native to Agile Craft so if the enterprise software platform that contains mission, vision, values, themes, strategies, road maps, success criteria, values, objectives and so even though many of the things are built organically by the team as it breaks down the stories and features, we’ll leverage the product to show the linkages of strategy to execution and align teams around a broad vision and roadmap. I think of one key thing that tends to do that, it tends to be a delivery road map that shows what’s being built and when those things are coming and how those things are nested into the strategic direction of the organization. Thank you, great question.

Ben: Cool. How do you effectively work with the operations teams and a bi modal team, is it hard enough to have them adopt the Agile transformation let alone the scaling of Agile?

Scott: I can field that one. When I think of an operations team, I feel that it may be a team that’s not necessarily delivering new products but I would interpret that as we’re addressing breaking issues or tickets or things more of that nature and so those teams, if that’s the intent of the question, those teams a lot of times actually can be fairly kanban or lean and so we see its maybe less scrum and more lean from those types of organizations. If its really addressing other parts of the development organization that simply haven’t adopted Agile practices, we do see a lot of horizontal bi modal where teams of Agile developers and non Agile developers can work together and there’s another webinar we run which folks are welcome to look up called Help, my teams are Agile but my Execs are Waterfall, where we talk a lot about the bi modal capabilities and bi modal challenges that organizations have and how to get those teams to work together to collaborate. Please have a look at that and I’m happy to follow up with anybody who is interested in learning more.

Ben: We have another question that comes in that asks how scaling of Agile scrum differs from scrum of scrum to SAFe 4.0?

Scott: Sure I can answer that. I think in general SAFe and SAFe 4.0 with the latest release and the incorporation of specific artifacts like the value stream and capabilities and solutions, I think it’s at this point, SAFe is a more established commercial framework that has kind of a core body of folks who are iterating against this and driving a roll out and evolution of the model itself. I think that versus scrum to scrums, I think it tends to reach a little bit higher versus SAFe 4.0 will have a program, a portfolio, a value stream at enterprise level and it will prescribe or give guidance for how to handle all those things across a product portfolio and development organization. While I think, well scrum to scrums can certainly reach up into some of those areas, it tends to be more focused on the program level and how do specific teams come together at the program level to coordinate the execution of work. Basically what we see as the main difference. It depends on how high you’re …

Kreisler: Yeah, and now I’ll add to that one is what we’re seeing overall most of or a lot of our engagements that we’re looking at with clients is a lot of them are looking at SAFe and the reason why, is it describes, hey these are some of the key roles, even not development roles, out there because that’s a common question we get a lot when we scale Agile is what about the rest of the business groups? How do they insert themselves in on that? It gives the description model, guidance as Scott said, you’re more than welcome to change it around, hey this is how it could  work and when you think about it, going back to a number of our ugly truths about self-optimization, frankly you go faster. If you only have scrum to scrums, you work a little faster, you deliver better quality but again its self-optimization. If you look at your entire organization, we want everyone to be willing to take the direction versus just the development org. I think that’s why SAFe is getting a lot, it resonates with the market, because it’s uprising to the entire system.

Ben: Terrific. I’ve had a couple of questions about the same thing so I’m just going to try to summarize these. The ultimate question that’s being asked is how can you reduce the Agile jargon or make translation easier so that people aren’t hearing things that they don’t understand and tune it out or fall into some type of rejection?

Scott: Great. We cover that a lot because [inaudible 00:49:41] standard traditional terminology to Agile terminology. In some ways it can be confusing but in some ways it’s really straightforward. I think the key there and we’ll refer back to this bi modal concept of aligning the terminology. I’ll give an example. In Agile, a story may roll up to a feature, may roll up to an epic. In a traditional sense, requirements roll up to projects, which roll up to programs. In those cases, whether you’re doing waterfall or Agile, the same things need to be done. I still have a strategic project that has to get funded and approved by executives, I have to break down the work into requirements or features or stories. Typically, if you sit folks in a room and you literally say okay you’ve got a program, that represents something really strategic that you’re doing over the course of multiple years and you funded projects and now you’re just going to break down those projects into requirements. I say well we have that same thing in Agile, we got this theme, which represents something strategic we’re doing over the course of multiple years, we’ve got epics which are things that are funded by the business that’s really no different from a project. The teams when they break the work down, they break it into features and stories, not sub requirements and sub requirements.

It doesn’t really matter what we call, we’re talking about the same thing. Then when you tool these things and you actually put things on paper, if you can use a transition period where you sort of refer to the things by the dual name, so this is our epic/project, reminder it’s the same thing. This is our program/theme, reminder it’s the same thing. It can be really helpful and then you can wean off the traditional language and standardize on something as you move forward. At least that’s what we’ve seen some organizations that really struggle with that to break through.

Ben: Terrific. Another summarization of a couple of questions. Basically the point that some people are making is that there’s a lot of focus on Agile and scale that Agile in the IT department but not necessarily for other business stakeholders, and so its kind of two part. One, why is that the case and the second part is, is it important to try to spread this throughout the entire business?

Kreisler: I will try to take that first. I think just inherently when we read about Agile, you go to the Agile manifesto, just terminology, speaking of words and semantics, the word software is used. But really you can replace the word software to products. But again, because of the background of how it came up through this environment, I think that’s why a lot of people I regularly work with, a lot of clients that I work with or executives or business executives, will tell us well that’s an engineering thing. I really don’t care. So I think that’s why and to get through that, I think this is a trickier area. But what we found is using one of the secret weapons is having an executive even highlight something that’s low risk for them, that they’re worried about changing the model for them or going to this new model, and having some of their key business people that want to be involved or that are excited about working this new model, be brought into that. Or using one of the secret weapons we mentioned, tapping into that informal network, finding some people that are passionate about it on the business side and are willing to take a small little calculated risk, a pilot, and see how that works for them. I think that’s what really what key, what we found successful; we want to take the business on the journey with us through this transformation.

Scott: I think looking forward, it is eventually inevitable that the concepts of scaled Agile will permeate the entire organization and go beyond the development. We see that all the time, there’s Agile for marketing, Agile for operations, Agile for finance, different organizations are experimenting with team level Agile concepts. Going back to the very beginning if agility has become a business imperative, and its a key driver of competitive edge, that will never just hold to the software organization. Other parts will want to generate and get the benefit of being able to be more Agile and so I believe that the frameworks and the tools, like Agile Craft will evolve and adopt to subsume more parts of the organization. I think it’s just a matter of time.

Ben: Terrific. Guys, thanks for answering all those questions. We’re going to wrap up right now and give everybody a couple of minutes back. I wanted to just thank both Scott and Kreisler for the presentation and for all of you for joining us today; we hope that the session was helpful to you. We will be sending along the recording and the slides so that you can again review anything or share them to any of your colleagues. But we also have a quick survey so as your logging out if you don’t mind giving us a little bit of feedback. Its always helpful to know if these sessions are helpful and give us some other ideas as to other things we can help you with. Again, thank you so much for your time today, we really do appreciate it and we hope that you enjoy the rest of your week. Take care.