Steve: Sure, so my name is Steve Spearman, I’m an Agile coach and trainer and I work with a small LLC and I associate with a number of companies for finding different opportunities and Richard and I first met and talked about this within that kind of context as we’ll talk about at a Scrum Alliance coaching retreat.
Shane: Great, and Richard?
Richard: I’m Richard Dolman, I’m an Agile coach and trainer as well like Steve, so I work at the enterprise level, work with a lot of organizations of different sizes; am currently a coach with Agile 42 helping organizations both transition too and grow their Agile capabilities.
Richard: Sure, Steve mentioned we get together with a group of other Agile coaches at Scrum Retreat, the Scrum Alliance Scrum Retreat back in December and one of the OpenSpace topics that was proposed, was how as coaches do we deal with the question of scale within organizations. As we got together with that group we brainstorm on a number of problems and a number of challenges. One of the challenges that we identified was there is a lot of information out there, a lot of misinformation out there, sometimes more heated diatribes going on about the various so called Scaling Approaches or Scaling Frameworks, and we wanted to bring a little bit of objectivity to that conversation and create this knowledge base and create a tool that will help coaches and organizations essentially compare and ask the question of “what approach might be appropriate?” for their organization and their needs.
Steve: It turns out it’s easier to say that than to do it, we’ve gone through a couple versions of this, we had initial version that came out of the retreat and we flowed that out for comments to one of the LinkedIn coaching lists. Got some really good feedback and it’s going through several versions since then, objectivity is hard to combine sometimes, but we are trying hard to also be sure that we are being at least as unbiased as we can; we have different experiences with different frameworks ourselves, and then we are always still looking for input and perspective from other as well, so it’s very much a work in progress, it’s definitely not something that we are going to put out there and say: “Here is now the source of all wisdom”.
3. So the product that you produced, what actually is it?
Steve: Yes, we have couple of things, we have the actual what we call the Matrix which is really a simple spread sheet that has a number of parameters on which you might choose to look at Scaling Frameworks, things about what’s it a good fit for, what kind of sizing, how wide spread do we think is uses and a number, a number of other things besides that, and so we try to give you this relatively compact kind of almost fit on one very long sheet of paper, but really also as Richard mention with the intend that you can use the same sort of model and extended it yourself, put in additional frameworks, because even deciding which things really are the frameworks you want to covers, is not as obvious as you might think because there are a few that are obvious and there are others that are controversial that we’ve had on there and taking off, and so forth.
Richard: And the key element to this decision Matrix is first starting, having a starting point in terms of knowing what problems are we trying to solve within organizations, so each organization has their own unique challenges, different sizes and asking the question of “what does Scale mean to us as an organization, what problems we are trying to solve?” I think is a key starting point before we dive in to simply comparing one approach versus another, I think it’s important that someone have a tool that they can first-off, set that foundation and then objectively look at the options, and as Steve mentioned: our goal is that this will be a tool that anyone can take and download, bring it into their organization and extend it based on whatever that foundational need is identified within the organization.
Steve: One of the opportunities we had when we were trying to put this together and make sure that it was as credible as was reasonable to get started. We did reach out to all of the primary authors of the key frameworks and got some very good feedback, generally very supportive feedback from everybody and we are also now trying to find this balance between creating an assessment, a view that shows reasonable perspectives on things, without claiming that it really covers all the space you might want it to, and so one of the ways we are trying to balance that, is we created a supporting website for it, and one of the things we are in the process of putting up, and we have some of the initial ones just now up is verbatim feedback from the authors is now posted, and we hope to eventually also post some of the further sort of the public commentary and such. Now we are just trying to figure out this fine line between: do we put every rant and every flame up or, how do we draw those lines and that’s an ongoing conversation.
Richard: Our website which is www.Agilescaling.org is intended to be essentially a hub for information and a source that anyone can come too and get this information, get links out to other sources so that they can get more of that objective view and be a place for research as well as a place to then use the tool to try to make some of that assessment. And we know we are going to take actually some heat from this as well because just by picking a hand full of approaches to start the conversation from comparison, we know that in another self generates a bit of tension in the marketplace and in our industry which we believe is a good thing to just try to invoke the conversation. But we are certainly not suggesting that the initial models of the initial process that we have started with are by any means, the only options that one can look at, but again we are looking to see what’s the most popular, what are the most prevalent approaches out there, starting the conversation there and then giving anyone the opportunity then to extend that conversation.
Steve: And just as example when we were having some of these conversations we had both email interchanges and some live talks with some of the authors and I had the opportunity to talk to Dean Leffingwell live and as he was sorting out what we were about it and how he should feel about this. He made the comment near the end that “you guys are going to get a lot of heat and that actually probably means it is worthwhile”, so I think we found that to be true and we are agree with that and we’ve certainly appreciated the support from him and the others.
Richard: And I think if you look around the various talks that are happen here at Agile 2014, I haven’t done the full analysis, but certainly are a quite a number of topics around the topic of scaling, and understanding what scaling really means, so certainly there is a lot of interest in the market for this, in the industry and we are just trying to create an opportunity to have that conversation, not taking sides not jumping on any one bandwagon or another, but creating that forum for discussion and giving people a tool that they can then objectively make that evaluation.
Richard: So the initial version of the tool: we started with good old fashion Scrum, just as a simple method to talk about how do we scale one team, two teams, etc. Steve mentioned Scaled Agile Framework so SAFe is included in there, Disciplined Agile Delivery or DAD which is Scott Ambler’s model, we’ve got Large Scale Scrum or LESS which is from Craig Larman, and we even including the Spotify Approach which I don’t think anyone would mistake for a specific framework but certainly it’s gathering a lot of attention in the space, I’m personally getting people asking me about the approach that they use there, so we’ve reach out to Henrik Kniberg and got input from him. So those are the starting points of the conversation and we certainly encourage anyone to add other approaches or other frameworks that they feel or worth comparing against those models.
Steve: And we’ve looked at others like Agility Path so forth that clearly have value to add but there are some orthogonal from what we see as frameworks right now, so not all of those are included in the Matrix itself at this point, but we’ve at least provided pointers to all of them on the website.
Richard: Couple of challenging elements that Steve and I’ve been dealing with is how do we include those things such as Agility Path or what I think Ken Schwaber is now calling Evidence Based Management or Mike Cohn’s Comparative Agility. Those are tools or methods to compare how are we progressing within the organizations, how do we measure our agility and we think those have a place in the conversation, we are not just sure how they lineup for the existing approaches, and then additionally there is a whole conversation around tools, so what software platforms, what ALM’s are going to align to an organization that’s looking to scale or grow, versus one that’s simply needs some good solid structure for their teams, so we see there is a lot of multiple dimensions to consider into this model and we certainly expect that by getting input from the community will be able to have this thing evolve into pretty robust knowledge base for that type of analysis.
Steve: And we really haven’t try to capture much about the ALM aspects, partly because we were trying our best to not seem to have any real commercial interest in this, which we really don’t, but things like which tool work best and such is a good part of the conversation, but we haven’t capture it right now.
Richard: I think it’s important to know, we’re still very much in the nascent stages of evolving this particular approach and we’re rapidly trying to get towards something that we feel is valuable to the market, but in many cases the market and the industry are going to tell us what’s going to drive that as well.
Steve: That is one of the harder questions it turns out and perhaps one of the areas where we get the most interesting conversation to my mind is, there is a view of scaling that most of these approaches take, which is that when you get beyond a certain size you need something more than basic Scrum and XP and Kanban provide; some level of additional stuff, usually involving some structures, sometimes traditional thinking kind of structures like program and portfolio and so forth. And here is where I think it gets kind of controversial, one of several places that’s get controversial, is there is a view that says: “Really don’t scale”, effectively, and it’s a very understandable one that I resonate with the some degree, and when you read for example the Larman-Vode book, one of the first things they say is: “ Well you are here because you want to do software development at large scale” and their first advice is, “don’t do it”.
If you really do really good, true high productivity kinds of Scrum and related sorts of approaches you may not need scale, or maybe we can find ways to stop reading in a more fully distributed environment, I think we tried reflect that partly in kind of the sweep of the different approaches we have in there, including Spotify which tends to get held up by a lot of people as the anti-heavy framework method if you will. Yet interestingly when you talk to the author he would tell you it’s not really intended to be a framework and it wouldn’t necessarily work as is with anybody else, and so that’s that more, find your own agility, find your own agility at Scale kind of a concept, which is very valid I think, but a lot of people, clearly the market is voting for things that provide more direction of that.
Richard: Well the very question of what is Scale, how we define Scale, that’s how we start our conversation at these types of talks, so tomorrow for example when we speak at the conference, that’s the first question that we are going to introduce to the audience is to have that conversation, let’s start to share what those various perspectives are in terms of Scale. To some it means we need to grow from a handful of teams to several or hundreds of teams, to others it means we need to expand Agile beyond just the IT or Software Development department - we need Agile into other areas of the organization, and answering that question I think is really central to be able to then go to the next level of evaluating, “what’s the best approach for us?” I’m one that is often a bit of hesitant [editor's note] to dive in into a particular framework just because there is a lot of popularity around that, I really believe that we should first define the problem that we are trying to solve and then be careful that we take the appropriate steps to find the way to approach that, and to Steve’s point: I’ve had a lot of conversations already this week here at the conference with people who are actually talking about anti-scaling or de-scaling, and so again, just sheer number of talks here at this conference around this topic I think really tell us that there is a lot of bid and a lot of desire to get information and for people to have the right information at their disposable make good decisions for the organization.
Steve: It really is almost an order magnitude higher that I’ve seen in previous conferences, we spoken to this in couple other times this year and having been at these conferences for a while used to have 2 or 3 or 4 maybe at this time it’s tens so it’s clearly hot topic.
Shane: Any ideas why?
Steve: I think we’ve cross the enterprise chasm, is one piece of it for sure, that I think Scrum, Agile in general passed the chasm a while ago at different levels of the sizes of the organization. It’s still relatively recent that enterprises got real serious about it, there it’s been small incursions and different pieces of many big organizations including ones that I’ve work within the past, but I think in terms of true kind of corporate wide enterprise adoption it’s just now really ramping up and we are seeing things like some huge coach seeking things going out in the marketplace right now, where people are converting over tens of thousands of people over in some cases.
Richard: I think it’s also a condition of the world that we work in today, even relatively small organizations can be highly distributed in nature, so sometimes the definition of Scale is: we don’t have the ability to have true collocated teams by the nature of our business, by the nature of the scope of our organization, even for small organizations we may have knowledge workers, developers, etc, across the globe, so that’s a form of Scale that someone may define so I think even small companies as well as the fortune 100 size companies, are dealing with Scale issues that are geographical Scale and just the Scale of the work force. I think it’s just a natural progression of where we are in business and as to Steve’s point, I hate to be a cliché, but we had crossed the chasm; Agile and the Agile Methods and Lean are now part of the common vernacular in organizations today and executive leadership is really starting to recognize that it’s something that we need to bring into organization and it’s no longer simply being relegated to a couple of development teams off in the backrooms. I think it’s definitely permeated the conversation across the enterprise and enterprises are changing today.
Steve: It’s a good point, we’ve tried to capture this one idea of culture in one of our rows, and we were kind of struggling with it a little bit because it’s not, we haven’t found it to be as straight forward to saying: “Well, if you really have a command & control culture, you definitely want to go this way” or anything that simple unfortunately. I do think certain models, because of their, either their completeness or their perceived prescriptiveness my appeal to certain kinds of cultures more than others. For me the interesting thing is you don’t find hardly any model that doesn’t at it’s core say the same thing which is “do the team level stuff really, really well”, and so even things like distributing your team members that Richard mentioned, we would advocate strongly against that if was up to you, but if you are in that situation, now what do you do, and it’s things like “form your teams within your geographies” as a first choice and so all these kinds of coaching sort of angles that we typically encounter, but I do think we are starting to see that sometimes as Agile is beginning to move away from being seen as that thing that development team does down there in the bowels and we don’t have to really worry about it as an organization any more, people are seeing that that kind of adaptability, and that kind of being Agile as a wider organization is key to their success and even their survival, and so I do think that’s another thing that’s causing, I like to believe in the end, culture change in some organizations; and that is always slow and always quite a process.
Richard: Culture for me is really important to understand, not necessarily we are going to be able to drive cultural change, but understanding what the prevailing changing is, what the sub-cultures are; for me it helps me understand how am I’m going to help the organization progress, so how that relates to this conversation, to this type of analysis is again an interesting question and while I believe culture maybe some are transcending to any particular approach or model just like when we compare Scrum or XP or Kanban, we can certainly see from a path of least resistance that if there is a particular prevailing culture, one approach may work better than another. The same thing I think holds true in this conversation as we look to grow or expand or spread Agile across the organization and certainly have an understanding of that is going to be important but I don’t know that any particular model that’s out there specifically speaks to that, and I think there is an opportunity for us to kind of bring that in into this analysis as well.
I mention the Spotify Approach, my term, I see that as largely a cultural dependent way of growing Agile/Scrum within the organization as compared to what Scaled Agile Framework it’s trying to accomplish, very different ways of viewing how we are going to roll out and grow practices across the organization and in my humble view, certainly if there is more of a need for more robust structure and more robust control, that approach may work better than, let’s say, a Spotify Approach, but if we are looking to really organically grow and have true autonomy within the organization and that’s core to our culture, then another approach may align better to what you are trying to accomplish.
Steve: It may and the interesting thing is while there is perception that certain approaches are certain ways, and one of the more of obvious one is people tend to look at Scaled Agile as first of all doing huge movement in the marketplace and therefore attracting a lot of attention, but secondly as prescriptive and while it has a very detailed, “we try to cover all the bases” nature to it, and it also says: “Pick the pieces that work for you and go for whatever sort of the lightest workable things”, so again you know can take ideas from all of these approaches and fit them into different things, including, in some cases I’ve been asked about relatively small organizations with maybe 4, 5 or 6 teams, can we take a few learnings from these things and of course the answer is, you can, in many cases.
Richard: I mean if you compare; look at large scale Scrum, it’s really about the product and making sure that we have a structure that supports good product delivery, Discipline Agile Delivery, just the word discipline to some organizations is nothing more than a talking point, so I approach it as a coach of really going back to your culture question, really understanding what’s the prevailing culture and what’s the organization strong at, what are their strengths versus what are the weaknesses, and at the Steve’s point, looking at the approaches and picking the right elements of that without watering anything down but making sure that we are levering the right elements of that and not over enforcing or over applying any particular approach.
Steve: I think then the very controversial aspect of this that I hear in the conversations is, if you put in place certain of these structures that are suggested by different of the frameworks, will we over time overcome those structures and become even more Agile and no longer require that or will organizations tend to just grab on to them and they become sort of their own fiefdoms and grow stronger, and that’s I think it’s not really a proven thing at this point, we are all kind of waiting to see how that turns out.
Shane: Well gentlemen thank you very much for taking the time to talk to InfoQ today, will make sure that the link to the website is here and well, good luck!
Steve and Richard: Thank you very much Shane!