I would call LeadingAgile a boutique consultancy; we are an Agile transformation firm that is focused on medium to large businesses. Our “sweet spot is” really in transformation, Agile Programming Portfolio Management, we definitely do all the Scrum Team stuff and training at that level, but we like to focus on really the flow value of crossing entire enterprise before the Dev Team gets it, while the Dev Team has it, what happen afterwards… Making sure that the organizations are able to consistently do what they say are going to do and help them meet their commitments.
Yes, it’s absolutely just run folks to the Scum Master training in your own good, right? It’s kind of a hard topic talk about what actually having your deck in front of you, but in general we believe that some of the most common Agile practices that we teach and talk about, while really effective at the team level don’t necessarily scale up into the enterprise. So what we’ve done is we’ve developed what is in effect a competency model, which rather than walk into an organization and say something like: “You need to have product owners, lets train the product owners”, what we talk about is the ability to have product ownership, so can we define the product vision and can we articulate that vision in terms of initiatives and can we break those initiatives down into users stories that the various teams can consume.
We have a model that’s centered around competencies and we have a process where we look at those competencies at different levels of scale within the organization, so whether it be single team, multi-team, program, portfolio, enterprise and then we look at those competencies in terms of frequency, so different competencies get expressed different ways whether we’re thinking about the iteration or the release or maybe the strategic road mapping view. So what we do is basically we’re going in and help an organization to create a road map that systematically walks those competencies along the scale and frequency boundaries, and then put together a plan that helps a company iteratively and incrementally introduce Agile at various levels, the teams in PMO’s and just systematically go through and build the organization in chunks, and to make sure that we’re very safely and pragmatically helping the organization sustain business agility.
One of the things that we found, sorry if I’m going on to much here, but one of the things that we found is that for a transformation to be successful you have to approach it on three different legs of a stool. So you’ve got the structure of the organization in terms of where teams are formed and what are formed around, whether it be features or products or components or services or what have you - business capabilities. There is also the practices that you teach them, that is where we get the expression of the competencies at different levels of scale and frequency. Then the third one which is the hardest is culture. You kind of think of it as almost a cycle where we change a little bit of structure, we change some of the practices and we start working on the culture and then we go grab the next piece of the organization, introduce some practices, work on the culture, and then we don’t abandon the team’s we just did, so you got to go back and you got to continuously iterate on those guys and help them improve.
So there is a structure-practices-culture, cycle that’s going within a framework of competencies and scale and cadence and it works, and it’s super neat when you can go into an organization and really make a meaningful difference and come back a year or two later and it’s stuck, is not like we just teach them and it goes away, it actually works and is sustainable and is something that you can actually meaningfully do in a company, very rewarding.
3. So what are some of the challenges of adopting Agile at that sort of enterprise and large space?
At the root of every struggle that we have is some sort of, you hate to say “people issue” right in a minute is almost cliche in the consulting field but we have matrix organizations; people have been doing certain things for a long time, a lot of times people in power have been doing things for a long time, sometimes we’re brought in from an engineering perspective and the product management group is really resistant or we can’t get things in alignment with a financial accounting or governance model or something like that. Getting people to see how they can do things differently and how they can improve the system when on the surface it might not be in their best interest, is a struggle.
So one of the things that we really try hard to do as part of the transformation strategy is to put in in effective kind of change management strategy to help people understand where they are today, how they are going to get safely to the next place and how they can be successful in that place, and frankly it doesn’t always work. Sometimes you get an organizations where there are people in power that don’t want to do things differently and it can derail, and in those situations where you can systematically touch the things you need to touch, those are the kind of the companies where often times you find people doing sprint planning or some of the basic Agile practices but they are not getting the value out of it that they hope. It really takes all of those different aspects that I talked about to create sustainable lasting change in a company.
Shane: And that doesn’t happen over the night.
No, is doesn’t happen overnight. Usually even like in a moderately sized company, let’s say something relatively small - sub three hundred, usually within a quarter or two you can get the first pass to the organization done, but there is so many different pieces that you are trying to influence. Most companies about that size a year, a year and a half, we have some clients that we work with it that were on the journey long before we got there and we are helping them through this phase of their journey and I think it’s going to be an ongoing process for them. I mean it’s something that, again cliché, it’s a journey not a destination, you are continuously improving, you are continuously trying to get better at it. In a lot of ways I think what we are talking in the Agile Community is somewhat congruent with human nature and the sense that, I think people tend to want to be responsible about what they can change and they want to do their piece good and call it a day. And Agile transformation is really fundamentally a systems thinking problem, all the pieces have to come together to deliver an integrated whole, and that is hard for folks sometimes, and frankly is not often how engineers think, it’s not how engineering organizations behave and getting them to a different place takes long time sometimes.
4. How do you that, what are some of the tricks of the trade perhaps?
The model that I was talking about today is, I mentioned it’s structure, it’s practices, it’s culture, I use this metaphor, is hard to envision if you have not see the picture that I have, about a guitar making company that I visited recently. They would cut all the different pieces and they glue them together and then they wrap them up and they calling that a “guitar mummy”, and the idea was that, while the guitar was setting they needed to keep it in exactly the same place, so the glue could dry and everything would be in the right order. That metaphor has been running through my head a lot, because we tend to think about, let’s get people trained and let’s get them in the right mind set and then agility will emerge.
Being an Agile enterprise is not just about the cultural aspects, it’s about the structure, and it’s about the discipline, and it’s about good requirements management, it’s about precision of execution and it’s about the technology, and so what we tend to do, is we tend to determine the pieces, the teams, get the teams formed, teach them and practices, work on the culture, understand and even define the interrelationships between all the entities in the organization and then do that kind of “guitar mummy” thing that I was talking about, where you have to bind that for a while and you have to hold firm and you really need a solid senior level champion on the team (not the scrum team but the enterprise team) that is going to hold the organization accountable for behaving in this way and you have to let the glue dry.
Now tough metaphor for Agile, because we don’t want rigid organizations but at the same time if we get a good reference architecture in place for the enterprise and we can let it set and we believe that it would list help us achieve our goals initially, then once it’s in place then we can start going “ok, let’s figure out how to improve it”, “what we can loosen up”, “what do we need to harden out”, ”what do we need to change”; but I think it has to be held together for a while until it becomes just the way that we work, and at the point that it’s just the way work and it’s ingrained in what we are doing, it’s like Alistair Cockburn’s “Shu-Ha-Ri” thing: We need one way to do it right, and then as we gets better we can find other ways that work as well, and then we get to mastery, then we can abandon the prescriptive ways and we can do it in a more fluid manner. I think a lot of times we want to think “We’re just going to teach people the stuff and they are going to achieve mastery right off”, we need one way initially that this organization can function in an adaptive manner and then as we get better that we can start pulling some of those pieces apart and doing things differently to achieve better outcomes.
It was kind of funny how it played out because I submitted those two talks and the conference put them in the right order which is kind of cool because I had the Transformation talk today, the Agile Program & Portfolio talk tomorrow, I think that was a coincidence unless somebody was really, really paying attention to those topics. Even as I was putting together the decks over the past couple of weeks, the relationship between them is actually pretty uncanny. So the transformation model is about getting an organization to the right structure to be able to operate in an Agile way. The Program & Portfolio Management talk is really about the operational model that is going to enable us to manage the flow of value.
And so in a nutshell, you know one of the things we talk about in the transformation piece is that enterprise Agile requires more just Scrum to be successful, so we are blending Lean and Kanban, we are blending theory of constrains, we’re using aspects of RUP and traditional project management. So I’m really going to introduce in that talk, is usually a three tier model, sometimes it’s two, sometimes it’s four, kind of a governance framework for how you drive project work through an organization.
One of the things that I’ve started to do with clients is really kind of four primary views that I like to see to manage an effective portfolio. First you use kind of the team level view that all are custom to velocity and burndown; there is a road map view that I like to use where really try to get three to six months rolling wave of users stories, we start looking at architectural road maps, we start looking at product road maps, so we can understand what pieces are important to the business and when they are important to the business, we talk a little bit about budgeting versus estimating at the portfolio level, and then the third view what I call like a flow based view, that is where we wrap the portfolio and kind of Kanban/Lean/theory of constrains language.
In the last view is actually probably the most non-Agile looking view of them all where we show percent complete progress. So from a team’s perspective, it’s just Agile, just backlogs, it’s two week delivery cycles, it’s produce an increment of working tested and software at the end, but what team level Scrum doesn’t do a good job of explaining to us is “where does the product owner get the backlog from”, how does the enterprise manage the coordination across what is often times very complex product architecture, how we visualize that, how we make decisions, universally organizations do that very poorly.
So if I can get the team view and then augment it with the road map view, the progressive elaboration, a flow based Kanban view to really drive what gets broken down and when, and then be able to communicate out in a more traditional kind of percent complete model it works and it’s neat. But the tough thing is that the portfolio model only works with the right kind of organization, and so that is why the organizational piece and the portfolio piece go hand in hand, this is how we want you to be, this is how I’d like to you to operationalize and actually demonstrate value and predictability and all that kind of good stuff for the company.
It depends on what you are trying to accomplish, so if you are going to that sub-three hundred person organization where you have access to the C level folks and you can change everything, you can do great things, because you can get the structure of the organization and the practices and the culture can grow with the operational model and that is like Nirvana of this stuff. Quite often we have some success going into a super large organization where we have about a three hundred person division of that organization, so that is a different kind of thing. Occasionally you are going to an organization where the structure and the culture and everything is not in alignment with what we are trying to do, but we’ve got a pretty good level of influence over a significant piece of work, where even though the organization is somewhere transient, it’s stabile enough and funded enough and large enough toward you can almost create the structure that you need to within the program.
And so as long as you define the appropriate interfaces, with the legacy organization, that piece almost becomes like a sub-organization within a large organization, you can be successful there. You just have to realize that when you do something like that, it’s not a transformation event at that point, it’s a program or a large project that is being run using Agile Program & Portfolio Management Techniques. That is ok, that it’s a perfectly reasonable outcome as long as you understand that as soon as that project is deconstructed, then everybody is going to go off and do things away that they used to, because you don’t have a persistent delivery capability within the enterprise.
Shane: Mike thank you very much for taking the time to talk to InfoQ, we really appreciate it and good luck with your talk tomorrow!
Thank you very much Shane!