In this episode of the What’s Your Baseline podcast we are changing up the format a bit – this is the first of many interviews that we will have in the future.

Our guest today is Mike Idengren, who has 20+ years of experience combining EA, BPM, and agile solution development methodologies to unleash cross-functional teams’ potential to deliver on digital business transformation expectations. He is a TOGAF-certified SAFe SPC and instructor, applying “agile at scale” — going beyond theoretical teaching, and delivering results by implementing “just enough” tools, organizational structures, and processes.

We are talking about the following topics:

  • Mike’s background and how he got into Agile
  • (Scaled) Agile as a discipline and its “big goal”
  • The layers of Scaled Agile and the roles that architects play in each layer
  • The value context: improving product quality, lowering risk together, and improving sustainability. 
  • How to implement Scaled Agile: leadership, start small, scale
  • Doing Agile in a remote environment (vs. traditional “team is in the room” approach); which tools to use and which type of (consulting) resources to bring on board
  • Governance and the LACE (Lean Agile Center of Excellence)
  • Mike’s patent-pending “Lean Agile Blocker Index” concept
  • Lean Scaled Architect’s offerings

Mike can be reached by sending a note to mike@leanscaledarchitects.com and you can learn more about his firm at www.leanscaledarchitects.com.

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Ep. 6 – Agile and Architecture: Mike Idengren – What's Your Baseline? Enterprise Architecture & Business Process Management Demystified

Additional information

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

  • CP1 (Welcome)
  • RakeBeatChords (Interlude 1)
  • Be Loved In Return (Interlude 2)
  • South Wing (Outro)

Transcript

(The transcript is auto-generated and was slightly edited for clarity)

 Roland: Hey J-M, how are you doing today?

J-M: Hey Roland, I’m having a great one. How are you doing?

Roland: I’m doing fine, because we have a very very special guest today in our show.

J-M: My goodness.

Roland: We have one of the most experienced architects that I know on the line. His name is Mike Idengren. Hey Mike, how are you doing?

Mike: Hey Roland, and thank you for that overanxious introduction. I definitely appreciate it.

J-M: Well, we’re really excited, Mike. You know you’re our first guest ever on the What’s Your Baseline podcast. Aren’t you honored to be our very first?

Mike: I am and I really hope I don’t disappoint.

J-M: Ah, well, we’re excited to hear your opinion and thoughts. And of course all your expertise that you guys are here today to talk about. So let’s talk about you and let’s talk about what we’re going to do. So, first and foremost, I think our listeners would love to get to know you a little bit better. So tell us about yourself, Mike, who are you and what do you do?

Mike: Sure. I’m a software developer by trade, and I’ve spent, you know, since the late 90s, early 2000s. I grew up as a Webmaster and in the early days of folks who did web development will remember things like Alistair Coburn and Object Oriented Development and the birth of those things. And we all got really excited about those things and we started doing the agile thing, and were like: “let’s everyone do user stories and cool stuff like that and power to the people”. And you know that went well in small teams and whatnot, for a long time. And I started getting involved in things like business process management and enterprise architecture and things like that, and eventually left the utility company I was working at and started advising for clients such as Boeing and some other large organizations. Oil, gas and banking and telecom. And I eventually got to the point where I said wait a minute, I’ve been doing so much enterprise architecture, BPM. What about that Agile thing? That was pretty cool back in the day. It wasn’t so heavy. It wasn’t so. I feel like you could go in different directions faster rather than talking about governance all the time. And I said, man, there’s gotta be a way to combine all this stuff together. And that’s what I hope to share with you guys today.

J-M: Oh wonderful, well that’s really cool to hear your background in a little bit of the experience and your vision for how things can come together. Well, Roland, how do you know, Mike? Tell us your war stories!

Roland: Yeah, we’ve known each other for more than ten years by now. So when he was fresh and joined Software AG back in 2011, he had the pleasure or displeasure to work with me on one of the larger projects that we had way back when in Florida, which was interesting to say at least and then out of this professional relationship, I think emerged a friendship and for whatever reason he followed me then to KPMG, and now he has his own firm. Mike, tell us a little bit about your firm.

Mike: Yeah, yeah, just sort of continuing on with the theme of combining together BPM enterprise architecture and Scaled Agile. I founded Lean Scaled Architects (leanscaledarchitects.com) and what we really want to do is walk the talk. Really figure out how we can combine those three things – three typically not going well together disciplines. And how do we make the most of them? Get folks to say we need a little bit of all three and kind of balance across them. So if there is a word that I like to use quite a bit, it’s balance.

Roland: Before we get to it, Mike, talk a little bit so that the audience gets to know you a little bit better, talk a little bit about what you’re doing outside of work. What are your hobbies and interests and bucket list items?

Mike: Yeah yeah, so much like yourself Roland, I really enjoy the travel thing back when we used to travel all over the place and I got to see most of the States, and J-M, I know you’ve seen quite a bit of the country as well. You know, US and Canada. These days I find myself in Boston and Provincetown, mostly, and one of my things is biking every single day and in the trails. And it’s one of my favorite hobbies to do.

Roland: And have very explicit coffee tastes. So whenever you get the chance to go to Starbucks with Mike, be prepared for a treat because I think he orders everything that’s on the menu and then puts all those pastel thingies in there.

J-M: Roland doesn’t judge folks, except on their coffee tastes.

Roland: Yeah, of course. Coffee and motorcycles, you know, J-M, that’s that’s how it goes.

J-M: That’s the way! Well, tell us a bit about bucket list items. What are your dreams and goals in life, my friend? I know it’s a big question, but I think our listeners would love to know just a little bit about that.

Mike: Yeah, one of my biggest professional dreams is just to make a difference in the community – to really contribute something that is recognized as really helping organizations, whether they’re nonprofits or whether they’re for profit, corporations or government, really use their resources more efficiently to produce better things that are higher quality. And one of the concrete ways I am doing that is to embark on the journey of publishing a patent called the Lean Agile Blocker Index and I am about 70% of the way there. That is one of my major goals that I hope to be accomplishing soon.

Roland: Which we definitely will talk about a little bit later in the show when we come to the topic of how, but maybe we get started a little bit for those guys on the line who haven’t heard anything about Agile and Scaled Agile. Can you talk a little bit about what that is for laymen?

Mike: Yeah, I sure can. And you know what, before we get there, I want to talk about the very big goal as to why we talk about any of this scale, the actual EA or BPM. Because we can do cool things and we can say we’re going to use cool technologies or whatnot, but I want to bring it back to the one big goal which is for any organization, whether it is government, nongovernment, whatever, the big goal is timely release, operation and maintenance of quality assured products and services in a cost effective way.

J-M: If that’s going to be your big goal, there seems like a few different things you’re talking about there. First and foremost, you’re talking about something that might orient to a project or to a development framework and methodology, so timely. What do you mean by that? What’s your first qualifier for that statement?

Mike: Yeah, yeah, there are two major big pieces on how we will attack that statement and how we’re going to make that happen. The content, so technical and non tech, so development of software and BPM practices, so that’s managing the actual content of the projects. And then there’s the “how” which is the project management itself, and I will replace the phrase project management with “Agile Program Management” in the future when we talk about that. That’s our upgraded term for that, which leads us into your question talking about Scaled Agile. When we first opened up the podcast, I was discussing how, you know, I started small and we were talking about cool stuff like object oriented and small team development and that worked well for a long time before we realized “wait a minute when we’re putting in things like massive ERP programs, these techniques really don’t work as well when we’re trying to coordinate these large teams of efforts.” So we started talking about “how do we scale up” and one of the big frameworks that started getting developed around 2010 is Scaled Agile. scaledagileframework.com is the open, freely-revealed framework for anyone in the world to use. And of course the Scaled Agile Inc. company sells training and some services so they can eat, right? So it’s become a really big convenient way to combine a lot of complex pictures together. And when we talk about Scaled Agile framework for enterprise, we are literally talking about taking these concepts of agility and applying things like an architectural runway. That will allow us to put in just enough structure and investment so that these teams who know the business who know the technology can be unleashed enough to produce products and services, quality-assured products and services, in a cost effective way. That’s the goal.

Roland: Yeah, but before we get to this, and I know you have an answer for this because when I did my SAFe certification (you were my coach), so I know that SAFe obviously is more. Can you talk a little bit about what the word “scaled” in this context means before we get to the role of architects in that concept?

Mike: Of course, and that’s a really good lead-in because in this to get to that big goal we will be talking about things in the context of SAFe a lot more. Then we’ll be talking about details of BPM and EA. BPM and EA will be a means to an end. SAFe, scaled agile framework for enterprise, has what’s called a big picture. It’s literally a cornucopia of all of the pieces of software development and program management and DevOps that have been vacuumed into this one picture over many years. It’s at scaledagileframework.com, so I’m not going to go through all the little pieces of it, but it basically occurs in three layers.

Portfolio is the top layer which talks about: how do we take organizational strategy and align it to the big budgets and portfolios that we’re going to authorize that we’re going to fund for programs to happen. 

Second layer underneath is a large solution layer. That layer is the implementation of the program’s large solution released trains. We will talk about trains in this program as well. 

And beneath that is where everyone starts. It’s the essential level. Used to be called the team level. It’s where the rubber hits the road. It’s where software code gets written. It’s where business processes get defined. It’s where we have backlogs and user stories, and scrum and XP’s and it’s where most of the action happens, right? 

So those three layers together, with the essential being the one that is essential for everything at the bottom layer, those three layers are how we scale agility?

Roland: So Mike, when you talk about those different layers, what is the role of architects in those different layers and do they still exist in Scaled Agile?

Mike: Yeah, this is a really good question, Roland. So in order to answer it, we’re going to expand or we’re going to qualify what kind of architect is in context for those layers. At the essential layer, where we’re dealing with the mechanics and the building of the products and services, and a team with a team level and dealing with agile release trains, we’re talking about system architects. Generally those folks who are focused on entire systems, whether they are operational systems or billing systems finance, whatever they are. 

At a layer above the large solution layer where we might be putting in, for example, an autonomous driving vehicle which has lots of systems, both software and hardware, right? We’re talking about a solution architect who is needing to bring together lots of different teams from different agile release trains in order to make a large solution work, and including essentially, suppliers. In customers together and those are very very large programs. 

And then at the portfolio layer we’re talking about enterprise architects. Enterprise Architects focused mostly on investment and overall standards for the organization, especially when it concerns policy layer compliance-type concerns.

Roland: So what does it mean when you look at the “average architect”, and that we all know that this thing doesn’t exist and it’s obviously an abstraction? But what does it mean for the training of architects? Because when I think about how people typically get into enterprise architecture or business process management for that matter, they just get exposed to it and curiosity kicks in. But I can assume with SAFe or Scaled Agile as a framework behind it, they have to learn a little bit more than just doing the technical or business stuff.

Mike: Oh for sure. In Scaled Agile, there’s some prescribed training which conveniently brings together all the different roles in some training so that everyone speaks the same language. And in other trainings such as SAFe for architects class, it’s talking about how to be an architect, how to lay, and how to balance laying enough architectural runways so that you can have enough governance but not strangle the innovation of the teams. So that’s that broad training, to answer your question. And then there’s the more detailed role specific training that’s available from a scaled agile context, not including specific tools and programs and DevOps kind of technical training, which is done in addition to that. 

So it’s always important to look at the organization and where it’s at in its maturity curve, where the kind of tools and processes are needed, and think about gauging the training. To that level.

Roland: Makes sense.

J-M: That sounds amazing Mike, but I know a question that a lot of our listeners are going to have is about the value of Scaled Agile and I want to have you set the context behind how you would get that value from implementing a framework like this and from having a mindset that looks at Scaled Agile as part of how you operate your business. How you think about and conceptualize BPA and how it all fits together. So tell me: where do I get value from this approach?

Mike: Yeah, fairly good question, J-M, and let me take that in three pieces. So the value context is going to talk about improving product speed to market. Improving product quality and lowering risk together. And improving sustainability. Because we don’t want to just release.

J-M: Can you dig into those three things for me? Those seem like really ambitious goals, but how does this framework specifically target each one?

Mike: Sure. So when we talk about the first one, improving product speed to market, we’re looking at less reinventing of the wheel. By improving process reuse and chunking bits of work to improve collaboration among developers and product owners. This is bread and butter agility. We talk about chunking the things that we want to deliver (remember those products and services) into large epics, features and user stories. Epics are the biggest, features are in the middle. User stories are the smallest bits of work that produce value, right? And that’s that there’s a lot more detail to it, but at a high level, that’s how we chunk and improve that product speed to market.

The second piece is improving product quality and lowering risk. And if we want to think about the most tangible benefit of bringing together business process management and scaled agility (SAFe), this would be it. Folks who invest in BPM will appreciate the ability to say: “look, you know there’s a project going on. We want to be able to advise the project team this is the way things really happen around here, and these are the GRC impacts related to this process. So if you’re going to develop this product and service, please take these safety concerns into consideration. Please take these financial controls into consideration”, right? 

That’s always important for any project, product service, and it is doubly important and scale agility when we’re talking about allowing teams to have more flexibility and freedom, we want to make sure they are well informed. We want to make sure that when they’re developing test cases in the context of BDD, behavior driven development, and TDD, test driven development, that when they’re writing those tests that they are actually accurate tests. ‘Cause you’ll often hear the phrase shift left, which means that we do testing. We find bugs earlier. But if you want to cover and dig a little deeper in that, you’ll find that folks often are writing tests that might actually not reflect reality. When you combine a good BPM practice that has relevant processes, risks, and controls documented, what you’re doing is you’re feeding those frontline project teams with really high quality, pieces of data, pieces of controls and risks that are necessary to produce accurate tests which are going to result in faster and higher quality release of products and services that are lower risk as well.

The third piece is improving sustainability. And one of the misconceptions of Scaled Agility is that it’s all about product development. It’s all about the big release. Actually, an agile release train is a construct used to encompass the teams in the product, the services, and the systems that are developed when a train is launched. It continues throughout the life cycle of the product or service. Everyone boards the train. Everyone boards a train, creates the software, creates the product, creates services, and then it runs so that the team (a part of it) will be responsible for sustaining it in the future, which includes the operations and maintenance of those products and services as well. 

And as part of that sustainability, it’s important to make the right investments and the tools and technologies, so enterprise architecture, to make sure that we control our technical debt over the long term, right? And cloud services to make sure that we have the flexibility, from a technology perspective, to quickly use the best products and services and not have to make massive investments – large investments that take a long time and take away from our product and service investment portfolio, right? So this is all right and come back to the architectural runway concept. Being able to put in the right amount of enterprise architecture and BPM. It really impacts our product quality and lowering risk because we can use processes as part of writing test cases, enterprise architectures using improving sustainability because we can do those things like rationalized application portfolios to make sure that we are using the most cost effective applications and services for our products and services going forward.

J-M: I’m not hearing a lot in this about things like organizational design or software development. Does this concern that, or is it an independent layer on top of this?

Mike: That is another layer down below. How we do the things that I just discussed and those are specialty topics that are outside of scope of our discussion here. So for example, I’m not going to bore the audience right now with how to set up a continuous delivery pipeline or do DevOps and detail and building software. Or how we bring in the top talent on doing Scaled Agile projects? Those are important, but they are details of the higher level goals that we’re discussing today.

Roland: Agreed that that we don’t go into detail for this podcast here, but for the listeners out there, there are obviously also very interesting concepts about how to structure your organization to become more agile, so I will put a link in the show notes about the  “Spotify model” that basically goes away with the traditional organization that you see in organizations, which is a hierarchy.

Musical Break: Rake Beat Chords, Jeremy Voltz

Roland: But Mike, that’s a good segway when you say “how do we implement this”. So say you convinced me that Scaled Agile and SAFe is a good thing. So how do I make this happen now? What are the steps that I need to have a look at if I want to get my feet wet and take the first steps on this journey?

Mike: So we’ll talk about how to do it in three big pieces. Number one is leadership. Number two is doing it small and number three is scaling it up. We always start with leadership because there has to be a commitment from the organization, right? There has to be a commitment from somebody, whether it is a line of business leader or the enterprise CEO or or some area that has enough responsibility and authority for products and services to say we’re going to do this. We are committed and we’re going to put people in the right roles and support them to do this. And that includes training. Scaled agile framework for enterprise,  they call it a tipping point. They call it a tipping point where a large organization, whether it’s again in line of business or enterprise as a whole, says we have to do things differently.

Roland: But yeah, before we get to this point, say you just learn about it. You’re relatively low in the organization’s hierarchy. How do you, or what are good techniques to make your superiors aware of this to get this leadership commitment?

Mike: This is a good point and the tipping point that we just discussed is kind of -how do I say this?- it’s a bit of a unicorn. I’m just going to admit that right out front. Traditional SAFe teachings will say that there has to be a big tipping point among leadership, and then the rest of the organization gets training and then everyone does the right thing and then all of a sudden we’re agile. 

It does not happen that way. It is a long battle, so when I talk about that second step, doing it small. I encourage limited experiments. I encourage smaller tipping points within smaller areas of leadership to maybe develop one product or one service to try to show leadership because folks need to be shown. You can’t tell them to build some credibility to say: “this actually works.”

J-M: And you want to start small, get wins and then be able to grow it from there and get the value you talked about before. Can you get that at a smaller level before you scale it to the whole enterprise? Does this work well in different varieties of contexts?

Mike: You can if you set expectations properly, which everyone here knows (I’m talking to a bunch of consultants) that expectation setting is key. So when we do something small and we say we’re going to maybe improve, make some small improvement on a product or service that’s already released to market. Or maybe an internal product or service for the organization we want to talk about, be able to succinctly produce marketing material, internal marketing material to educate folks on: How did we do this? Why did we do it, and what would be the benefits if we did it bigger? And those are the things that we need to go to – the concepts of education that we need to go into when we’re doing it small.

J-M: It’s something that you got a leadership question earlier. Does that mean you are also looking for a champion? Someone who’s going to represent this methodology specifically?

Mike: Yes, when we’re doing it small, that first step applies. We are looking for a leader to allow us to do it small. Whether it is a department, a division or or whatever, it might be because the next one up might be a line of business, right? Don’t generally try to tackle the enterprise layer with all of its complex finance across departments and security and compliance concerns. Pick those areas that have less compliance, needs that are less security sensitive. Because those will be governance battles that will be front and center. They will quash any kind of agility, progress or proof of concept that can be made.

Roland: So thinking about all the steps that you just mentioned, what would be a realistic timeline that you’ve seen in the past?

Mike: I would say six to six to nine months for doing it small, and I know that might sound like a lot. I would try to keep it under a year and I would say don’t try to do anything less than six months because there’s going to be some training among the folks who are trying to do this small, limited experiment right? There’s going to be mistakes. There’s going to be life that interferes with people who are in key roles, and you want to make sure you stay focused on that internal marketing message. This is not to change the world / change your organization’s future direction. This is to convince people in your organization that this is a better way of delivering products and services, right? 

And when we’re doing that, we’re focusing on people and laying runway. From two perspectives. From a people perspective, we’re looking at building cross functional teams. We’re trying to break a department mindset, and this might involve a little bit of negotiation with other departments. If your leadership and your permission to do the experiment is within one small department, there might be, hey, can we borrow XYZ person for a few months or maybe 10 hours a week because you’re going to want folks and key roles from different areas to be able to help you spread that marketing message, when this is going well, right? And you’re going to want to have that cross-department cross-functional representation on the team because it’s going to be a key message in and of itself: that we have to do things that are bringing together different folks from different backgrounds and experiences into the same team.

Roland: That makes sense. Do I have to bring all those people now in one room and lock them in? Or how does it work in these wonderful COVID times that we live in?

Mike: The whole industry has had to adapt to that and Scaled Agile itself never really liked to do or there was no such thing as remote Scaled Agile training before COVID, there wasn’t. And now it’s all remote training. So in itself Scaled Agile became agile and figured out how to do it with tools like, you know, Google Meet and Teams and whiteboarding stuff. I use Mural quite a bit, and I find that in delivering Scaled Agile training, I actually find it to be advantageous in many ways because everyone is sort of on the same page. They can have access to the same live digital material. We’re using pretty cool tools like Mural for example, and when we do it, it really gets it done. I really do find it to be as effective, now that I’m doing it.

Roland: That’s good, yeah, good to hear. What is the impact, then, if you look at the people you build those new rules, those new skills. You have set up the stage with the tooling, which obviously every IT person loves. What are the next steps that you would have to look at to do this? To do small steps correctly?

Mike: Yeah, so we talked about doing it small. We talked about, you know, making sure that you’ve got cross functional teams represented. You’ve laid enough runway with respect to processes, governance and tools. So when we say tools, we’re talking about basic Kanban, scrum tools, Jira, existing or lightweight software development tools, existing cloud enabled BPM or EA tools. 

This is not the time for massive investment. This is the time for using what we have in trying to use it effectively and building a runway from processes and governance. So when we talk about processes and governance in any program, any context, we’re usually going to come up against policies and governance boards, right? And that’s why one of the things I’ve mentioned is a recommendation for doing it small is try to pick something that is not going to be as security intensive. Not going to be as privacy, data privacy compliant. Consider that will not always be possible, but just just try to do things that will keep the processes and governance lightweight for this experiment to work.

Roland:And just to be very clear, you’re obviously still using your architecture tool, and you create the diagrams and matrices and all those other artifacts as you would have done before. Or what are you doing here?

Mike: Yeah, that’s right. So if we’re creating an application system where we’re going to document the as-is and to-be using whatever mechanisms that currently exist, even if it’s Visio, we’re going to do a current state and future state. We’re going to use whiteboards, electronic whiteboards these days as necessary. We’re going to do small, lightweight things, but we’re going to practice good fundamentals in doing so, right? That’s the key in doing: small context.

J-M: Yeah, you’re trying to just ease people into this mental framework and into this way of being. Practice your encouraging. And I would say with everything we talk about on this podcast, one of the first questions that comes up is how do I get started and what’s going to convince people to do this along with me. And it sounds like you’ve said, involve fewer barriers to entry, involve fewer complexities so that your wins can come early and can be sustained and grown with a business case to expand it, am I hearing that right?

Mike: You are right on, and this brings us back to setting expectations, and it is so important to just keep on that marketing message because you have to convince humans. That is the next step when we start to go, and the reason we’re doing this is so that we can have permission to scale it up.

J-M: I was gonna ask: how do you do something small and then take it cross functional – take it across the enterprise. Take it across a business unit where you’re achieving value and getting a better way of operating a way of working at the level that you’re working at. But organizations want to see the transformation. Really, they want to see the business value – a large ROI, a large impact to the organization. If they’re thinking about a tectonic shift like this in mindset, then what are you doing? How do you scale it up for the whole enterprise? What’s necessary to take it there?

Mike: Yeah, so scaling it up is going to involve larger investment is going to involve larger risk and is going to involve risk for executives who frequently do not like to take risks in the context of an industry where there’s a their lunch is getting eaten because of technology advancements in the industry or or tectonic shifts and the industry. From a competition perspective, then there’s already going to be that push built in. 

When we’re talking, you know more of a bottom up context like we have been, which is many organizations that aren’t feeling that fire. We’re thinking about:how do we ease into a “scaling it up” scenario where risk can be taken, but it can be limited by executives? 

So let’s talk about how we scale it up. Now that we’ve had some experience, we’ve got a marketing message, internally. We’ve got folks kind of understanding what we mean by agility and what we mean by building products and services and bringing together people from different areas. Let’s talk about scaling it up where we say instead of you know, six to nine months we’re talking about year timeframes, year 1, year, 2 year 3. So we’re thinking about picking a cross-department product or service, or one that directly affects customers setting bigger goals, adding more people, laying more runway. So we’re going to talk about the same things people and runway from a tools perspective and runway from a processes and governance perspective. And we’re talking about scaling. 

So we think about the context, scaling it up. Everyone is familiar with large projects that are done at companies such as an ERP. We’re going to replace our ERP. We’re going to put in new finance, new operations modules, whatever it might be. I still find these to be convenient ways to rally the organization around a large goal and investment prerogative in enabling change through that vehicle. Because for leadership to say we’re going to do something different on this kind of scale, there generally needs to be the investment and the commitment to match and expectations by the organization to get there. So in this way, I find that organizations will have an easier time. Moving into this new paradigm of scaled agility, and in applying these good practices if they can find a partner who is already practiced in these kinds of things, a large implementation specialist that’s going to take an ERP or some operational component of their business, and they’re going to say we’re going to push out these new products and services, and it’s going to affect all of these internal processes. They’re going to be different, and we’re going to do this in an agile way. And that is a really convenient way for an organization to bring in folks who’ve done this before and help side by side training and mentoring of their own folks internally to say “this is how we are doing this” and then it becomes more institutionalized going forward.

J-M: Yeah, I feel like we’ve talked about this on the podcast before, but these technology implementations are also really just a catalyst for change, right? Like, you’re using the excuse in some ways of a system landscape upgrade or an ERP implementation to make a practice change in the way in which you approach things. The only concern that I have, and I’d love to get your opinion on this, is the use of external partners and support the difference between sort of body shops and role-filling versus thought leadership and strategic consulting. Talking about where you’ve seen the differences between those and the effect they have on the efficacy of programs like this.

Mike: Yeah, it’s important to pull from the right to balance the right kinds of consulting advisory that is needed in these kinds of large programs, so you will need consulting advisory at both ends. You will need the folks who have been there done that with respect to how it is delivered with respect to the content of the products and services that will never change, right? It will also be needed when we’re looking to scale the delivery of the products and service components themselves and we’re cranking out the features and the stories that are going to comprise the software processes that are implemented. We’re looking at folks who have the ability to deliver software globally, right? 

So we often find that there are consulting firms that are pretty good at being able to say, “look, we have a cross functional team already that can deliver this kind of software using these cloud services right in this entire continuous delivery pipeline”, right. And also we need to plug in your experts into theirs, who are going to be the process experts. We’re going to be the product experts, right? And when we bring those folks to the same table, we see that we’re using the expertise of the folks who’ve built these kinds of products and services, who already have a continuous delivery pipeline who already have investments in Microsoft Azure or Amazon AWS. Have those teams that have worked before in this context, right? And what we’re doing is we’re bringing in the organization’s experts from the product perspective and training them on how to do their IT Department’s on how to do that incremental delivery of software using those cloud tools. Working with those offshore teams. 

By the way, this blends in nicely, plugs in nicely with that previous question. How has COVID impacted everything? Well, guess what, if we’re trying to deliver software in a global context with folks who are not in the same country? Right then we’re looking at doing remote collaboration anyway. It’s just that now what we’re doing is we’re doing global collaboration with everyone, not just the software developers, which kind of puts (from a cross functional team perspective) everyone on the same page. It puts everyone in the same communication bucket in terms of how we communicate together, which can help.

Roland: So what does it mean when we’re talking about tools, for example? In the past, we’ve obviously seen a siloed approach to it. You know the project management office had their Microsoft project or whatever other tool they had. The architects had their architecture tool and so on and so forth. What does that mean from your perspective in a more agile organization or more Scaled Agile organization? For that, how will the tool stack change? Or if you were a software vendor, where would you see a development need to support Scaled Agile?

Mike: Right, so when we’re looking to scale it up, we’re looking forward. We’re looking to the future to understand that we’re going to need to think about how we’re going to embed. The governance bodies into our projects to make sure that they are compliant. So we’re thinking about IT governance bodies from a security perspective. We’re thinking about governance from a policy and a regulatory perspective. We’re thinking about those things because they are real and they will slow us down. They didn’t disappear, just ’cause we’re doing agility. I promise you they are still there.

So our runway from a tools perspective needs to match, needs to be able to bring those in and think about how we are building out our portfolio of products and services to scale it agilly. 

So there’s generally three areas of investment we want to make from a tool perspective. Number one is to upgrade our smaller user story and Kanban tools into more portfolio management tools. And a good example of this is going from JIRA to JIRA Align. For example, where we’re saying hey we’re going to start taking these products and services and managing them from a portfolio perspective. 

And then the next area is BPMS and EA tools, so business process management systems and enterprise architecture systems (and here’s the asterisk) that have powerful integration capabilities, because integration is the word here. We want to be able to, for example, have a key financial process that gets documented and linked to 10 user stories in five features where it’s relevant. Because, guess what? If you’ve got some great business process management capability and the folks who are building the products and services and the new consultants who don’t know your business. If they can’t access it in a timely, relevant way, then it’s not going to do anyone any good, and it’s going to slow down the delivery of products and services.

So integration is key and the third piece is cloud enabled DevOps toolchain. So using Azure Native WS to really make sure that we can deliver software in small bits and do it in a cost effective way.

J-M: Yeah, I’m hearing a lot of things that are talking about using cloud tools and scalable tools. Does it require the parallelism of using scaling SaaS tools and hyperscalers as delivery mechanisms to align with your methodology?

Mike: Not required specifically to use cloud tools, but it is important to use scalable tools. We need to be able to say “well, you know, we find that our products are really failing to scale due to the number of customers that we have, so we need to add 100 servers right now.” Well, if we don’t have an infrastructure scaling capability, then we’re not going to do very well when we try to release this to the market. So, if we had a cloud strategy to begin with, then we could flip a switch. We could have our system architects and our solution architects take that into consideration when they’re making the investment to begin with, right? So those are the important reasons that we want to have those scalable infrastructure pieces available.

J-M: Because if it’s like six months to get a new piece of hardware in house, you’re not going to scale in an effective manner. You’re always going to be lagging behind, right?

Mike: Right and companies can do internal. They can do internal scaling, so some large organizations say look, for whatever reason, this is going to be important for us to keep this in-house, we’re going to have rack servers and we’re going to expand 50 of them if we need to. It just tends to be for most organizations, it’s more cost effective generally to have a cloud provider be able to do that for you.

Roland: Yeah, that makes sense. Having said that, you always refer to the governance part again. So now we’ve “built our people”, we trained them. We set up our runway and we invested in our scalable tools. What impact do you see on governance? How should that change?

Mike: So those governance bodies are still going to play an important role that already exists from a compliance perspective. I’ve mentioned security and policy from regulatory regulatory perspectives pretty frequently. What we’re doing now is we’re adding another one. We’re adding a new one for most folks, called the LACE. Lean Agile Center of excellence. The LACE. And the LACE is going to be composed of folks who are experts in scale, agility, and being able to make sure that we’ve got the right folks and right key positions. We’ve got system architects, we’ve got solution architects. We’ve got enterprise architects. We’ve got solution release train engineers. We’ve got folks who have been getting the right experience, not just training, but the right experience. We’ve got folks who were cross-functionally assigned to teams so that teams are well balanced. We’ve got the organization and set up in such a way and running in such a way that we have a healthy balance of a portfolio. And as part of that is the cooperation with the BPM Center of excellence with the Enterprise Architecture Committee right, who are looking at investment in long term products and solutions because the Lean Agile Center of Excellence is going to hear it from the front lines. We can’t release this product service because it’s taking too long because our architects are sitting on their hands about the new investment that we’re asking to make. 

One of the typical ones that I’ve heard in going and helping to put in a new architecture and engineering organization at one of the Big Four accounting firms is the constant fight between the folks who are releasing products and services and trying to push out new technology and the IT security folks, right? The IT security and compliance folks who say no, you have to go through these procedures. You have to go through these processes before you release this thing. So the Lean Agile Center of excellence will often find itself being kind of a facilitator to help bring those together to say look, we all have the same goal, but we all want to make sure that we’re releasing products and services in a timely manner that are quality assured. Remember, the big statement that we talked about earlier? Right, that’s part of the quality assurance. So it’s going to be important that that stuff maintains balance and that is what collaborative CoEs and governance bodies are supposed to be doing for us, is helping us strike that quality balance.

J-M: And I would assume if you get senior leadership, commitment and maybe even a mandate, then that equips and powers that center of excellence at LACE, that to be the connective tissue with the authority to ensure all the partners at the table to have that conversation. Because I feel like one of the biggest challenges I see in a lot of organizations is bringing those people together at the table. And if I’m hearing it correctly, that “do it small” value – you can show that kind of value early in single threaded conversations or small group conversations. Then when you get to that larger setting, a LACE for the entire organization, you can prove that point back and incentivize or mandate or both, people to the table to give you the information you require.

Mike: Exactly. I will find that a LACE is typically is started in those “do it small” kind of areas because they’ve proven that this works. They’ve established their credibility, they’ve communicated to key folks that this can work, and they’ve found themselves in a situation where they need to bring those other older governance bodies more, more conservative and kind of heavy or governance bodies on board. So make no mistake, you are absolutely right, J-M. The most difficult part of this is getting those governance bodies to communicate together and to stay on the same trajectory. For acting in the interests of the organization as a whole, releasing those quality assured products and services in a timely, cost effective way. It is easier said than done, but it is important that these folks communicate.

Roland: So Mike, that is obviously a very good closure to your initial statement. The one question that comes to mind is: will Scaled Agile replace everything in organization? Or are there for example, activities that an EA department would still have to do that are outside of the project delivery.

Mike: So that’s a good question. In an organization’s Scaled Agile framework for enterprise (because remember that I said that all the products and services are developed in the context of an agile release train, right?), everybody boards the train. Everybody helps deliver, develop and deliver new products and services and then they run that train forever. If the organization is completely on board with agile and everything is done in the context of these agile release trains, then the answer is that all of these governance bodies now exist for the purpose of keeping these trains running in a cost effective way. 

If the organization has separate lines of business and LOB one is the only one on board with Scaled Agile framework for enterprise, then we still have to think about a federated enterprise architecture organization where not everyone is on board with this scaled agile thing yet. And maybe this LOB has a different approach to their part of enterprise architecture in a federated context.

Roland: The question that I have is: do you think agile is something for people outside of IT departments or agile delivery projects? Have you seen that elsewhere in an organization?

Mike: Absolutely I do, and I like this question because it’s so important when we talk about cross functional teams. When we talk about building an agile team. We are always talking about building a cross functional agile team that has the skills and background necessary to completely cover all the aspects of getting a quality assured product or service out the door and maintained and operated. And that includes more than just technical folks.It includes the folks who have built the processes, who understand the customer, who understand the market, and who understand the maintenance procedures and all the different elements of that product and service necessary to build it. 

Because remember, it’s those folks that are going to be writing the test cases from a business perspective to say, look. You can write all the technical test cases all day long, but if they are the wrong test cases from a business perspective, then we can’t push us to market and we’re not going to win in the marketplace. 

So it’s always important and necessary that the scaled Agile team is not just a bunch of tech folks. It is absolutely including everyone with a stake in the delivery of this product or service in context, especially that question I really like for folks to think about. Some of the frustrations they’ve had with their own in their own organizations with developing products or services, making improvements to processes or or getting value to the customer. Where you see that you know this is just not happening because of XYZ. Maybe it’s because we feel like, there’s too much governance, it’s too heavy. It takes too long to get an investment in a new piece of software or the software that we have is not effectively implemented or the people I need to work with are always busy, right? They never have time for me when they never have time for this product or service that I think is the most important one. 

So I’d really like to hear about the kinds of issues and then I’ll definitely be available for email and contact later that folks are having their frustrations are having because there is an answer. It may not be a quick answer. It may not be an answer that can be solved by you alone, but there are frustrations that folks have that can generally generally talk about and get over. So I’d really like for folks to think about those kinds of things and maybe have some questions ready for us.

Roland: And we’re gonna take a quick break and after that we’re gonna talk about all the blockages that might come up in your agile process.

Musical Break – Be Loved In Return, Jeremy Voltz

Roland: Welcome back, so before the break we spoke about blockages that might happen in your agile delivery and I know, Mike, this is one of your favorite topics and you mentioned earlier in our conversation that you’re already writing a patent around this topic, so can you enlighten us a little bit about what you’re doing in regards to lean agile blockages?

Mike: Sure, so every organization has some issue or some reasons (one or more reasons) why they’re not achieving the kind of agility they wish they could get right? And we’ve talked about heavy things such as government, too much governance or not having access to the right people because everyone is so busy all the time, right? So if we kind of simplify this and bring it up a level, we might think of different dimensions of the typical ground conditions that are found in organizations. What we need is a way to quantify what the Lean Agile Blocker Index of an organization is. So often, an organization has 80% blockage from lean flow, but not very lean. If they don’t have it, conversely, if an organization has 20% blockage, their lean flow, they’re pretty lean and they probably shouldn’t be trying to get too much leaner because there is diminishing marginal returns, right? 

In diving a little deeper into that, well, that’s fine. It’s easy to say if we’re 80% blocked, wow do we know that we were 80% blocked, right? So what LABI does is use a set of real ground conditions. Measured from the existing projects. So for example, in a Kanban situation, where there are architects who are answering difficult questions on investments on how systems should be built, and there are developers in five teams in one group of architects. And those developers just want to write code really fast. Get the product out the door really fast. And the architects are having to answer difficult questions and they’re blocking the teams from going forward. The way that is tracked in a Kanban type system and scaled agile is called a program board and you put up these little stickies all over the place. Sticky notes, right, and in the architecture column you have lots of red stickies stacking up and you’ve got strings that are connected to all of the architect’s red stickies. And when you’ve got so many strings, what you’re seeing is that the teams are blocked from progress because they’re waiting on the architects to make decisions for them. Right, that’s blockage.

J-M: So blockage is unaddressed dependencies?

Mike: In this case, it is this one example it is. There are many other examples of different kinds of blockages that can deal with resourcing root causes or technology root causes, and there’s there’s these other quote unquote strings we can pull on to try to find where those important metrics are, but the concept is to be able to take these all of these different blockages together and to paint a picture in an easy metric. To say that we are X percent blocked and we’re going to set a target to be Y percent blocked next quarter, next year, next three years, whatever it might be, right? And this is a quantitative way for us to get there.

Roland: So the idea is to set up something like an early warning tsunami system.

Mike: It is, it is. It’s a way for organizations to pull the right levers because it might not be that we need to invest in a new large platform. Maybe it’s that we need to get better collaboration between our Lean Agile Center of Excellence and the IT governance boards.

J-M: How do you set sequential targets? Obviously if you’re at 80% block and you want to go down to 20%, I’m assuming that’s not an overnight thing. How do you say OK, so this year? Here’s what our goal should be, and here’s the kind of business value we think we can expect from reaching that goal. How do you make those determinations?

Mike: Right, so that’s where we would bring in experts who have kind of tackled these sort of issues before and look at where the organization currently is with respect to their culture, with respect to their product portfolio, and we respect to the resources they have available to them to make a change, and look at opportunities. One of the opportunities I mentioned earlier is to say, hey, do we have an opportunity to bring in a vendor who’s had experience with agility before, right? And can put in cloud enabled services for a new product or service for that’s going to be a major capital investment for our organization, right? 

When we look at those kinds of conditions to see if they exist and try to latch on where we can. And we say OK based on these weaknesses and these strengths, here are the levers we can pull to reduce our blockage and be able to produce products and services faster in the next three years. In the next five years. It is going to be a year time frame typically. It will not be in a month timeframe.

J-M: It sounds like there’s a big assessment process involved in this. Or there could be a relatively substantial assessment across a lot of different places? I mean, you talked about scaling upwards, but still I heard you say the word culture. That’s a complicated thing. I heard you say the word, environment or architecture. That’s also a lot of components to it. It seems like it would be great to bring somebody organization that has this ingrained in how they assess everything.

So what you’re getting out of it has built into its very DNA the structure of the analysis you want to get out, and you have a translation key ready to go towards the value that you could propose from adopting this practice.

Mike: Exactly the first part of this is what I would do is a LABI assessment to understand where the blockers are. Across those different areas, and then we would talk about bringing in experts. So an expert in architecture. An expert in organizational change, to start chipping away at those levers to say we need to do XY and Z in order to help do better internal marketing among our leadership right? And to the organization too. Tailor our products and services to the market in such a way that it’s more going to be more effective when we produce bits and release bits of software, right? 

So there’s going to be different experts to come in to help solve it, but what my organization would do is to help identify those problems and figure out which experts to bring in and how, and even more importantly, how we can take advantage of opportunities to make these accelerate these in an investment scenario faster.

Roland: I’m really curious to see how you bring that to life, and ideally how that will be added into a tool chain that you mentioned a little bit earlier in our conversation. But speaking of which, Mike, how does your organization,how does Lean Scaled Agile help your clients in becoming better on their safe journey.

Mike: So the first way is, as I mentioned, the lean Agile blocker index, which is a patent pending solution we have on the approach to uncovering those problems that are really blocking agility. And then, as I mentioned from the LABI perspective, there are several levers to pull. My organization specializes in the architecture lever and how we actually pull BPM and architecture excellence to be able to say that those areas we need to lay a little more runway, need to improve the training or the tools for organization to be able to be more effective in architecture. I would lean on other organizations and other experts for the organizational change sorts of questions, for example. Right alongside leadership, the first thing we talk about is training. We want to make sure that we are on the same page about what Scaled Agility is and the goals and how we can get there. We’re speaking the same language when we’re building those cross functional teams, and especially when we’re getting those organizational bodies to start collaborating together.

Roland: So you’re offering training for Scaled Agile and BPM and EA?

Mike: Absolutely! We offer a full catalogue of training for Scaled Agile and BPM and EA tools such as Software AG’s ARIS Architecture Tool.

Roland: Yep, that’s great, so thanks Mike for the whole conversation. Where can people reach you if they are now very interested in what you discussed, and want to learn more about you, about your offering, and the topic at hand.

Mike: Sure, they can email me – mike@leanscaledarchitects.com, or go to the website www.leanscaledarchitects.com. Or hit me up on LinkedIn. LinkedIn.com/Idengren.

Roland: And of course we will put all those links into the show notes so you don’t have to take notes of those. 

Well, I think that’s a wrap, Mike. So thanks for being our guest on our show today and our first interview that went without major hiccups. I think everybody on the call was very nervous, so that’s great.

J-M: But we had a lot of fun. Isn’t that what we’re supposed to be doing, Roland?

Roland: That is also true.

J-M: It’s a podcast for fun and for great business knowledge. And Mike, you brought a wealth of knowledge to the podcast and hopefully our listeners both enjoyed what you had to say and you can follow up with Mike both through all the different links he’s provided. And also, as Roland mentioned, finding more information on the website. whatsyourbaseline.com for a lot of the things we need.

65:13

Roland: Thanks folks for listening in to this very interesting interview with Mike Idengren from Lean Scaled Architects and his very interesting concepts about agile blockings and the LABI Indicator. As always, reach out to us for feedback at hello@whatsyourbaseline.com and also you can leave us a voice message when you click on the link in the show notes.

J-M: You can also leave us a nice rating or some feedback on your podcaster of choice, and if you want to review the show, you’ve good things to say, or some feedback we can take and use for future shows, we’d love to hear from you and respond to you as we go. And as always, you’ll find the show notes for this episode at whatsyourbaseline.com/episode6.

Roland: My name is Roland Woldt.

J-M: I’m J-M Erlendson.

Mike: I’m Mike Idengren.

J-M: And we’ll see you in the next one.