Dean Leffingwell is a consultant, entrepreneur, software executive and technical author who provides product strategy, business advisory services and enterprise-level agility coaching to large software enterprises.
Related Podcast and Transcription: Leffingwell on the Lean Agile Train
An excerpt from the podcast:
Joe: What are the keys to building a Lean-Agile software enterprise?
Dean: Working towards my one annual presentation, I do one trade show a year. I go to the Agile conference every year. It used to be Agile XP, and that has just grown tremendously and it’s a high-value conference. So I’ve been reframing the way I describe the way I see large enterprises being successful around five basic keys. Now I’ll describe those keys here. It might be a good way to approach the things we’re talking about. Key number one is, not everything is a user story. A user story is a really great invention. It came from XP, the user voice forum, which is, as a user; I can perform this activity so I can get business value. This is just a fantastic breakthrough in our thinking. But user stories are small because they fit inside iterations, and there are lots of them. So at the enterprise level they don’t scale very well and that’s why you see in my book “Agile Software Requirements” a three?tier, three?approach of user stories, features and epics and even a fourth year if you will which is the investment themes that drive all that.
So my first bullet thought is got to be smarter than just taking everything to a user story. The second key is at enterprise scale the way we’ve rolled out Agile historically which is a team entered a time or a Scrum mastered a time is simply too slow. So, I like to think in terms of Agile programs and not just Agile teams.
Agile programs are oriented around this construct that I’ve roughly described as the Agile release train, which is a synchronous set… Or a team with a synchronous set of iterations all timed together, working together, doing their planning, their commitment, or execution of their feedback together as one fractal above an Agile team, which has exactly the same pattern.
Thirdly, architecture emerges in Agile. It’s part of the manifesto, but I got to tell you at enterprise-class scale it can emerge in some really bad ways. And if you’re sticking together an entire portfolio or you’re doing enterprise-class business applications you can’t expect any one team or any half?a?dozen teams to have a real view of how that all needs to work together or what types of governance needs to be applied to those systems.
So, as I wrote in “Scaling Software Agility,” I’m a big fan of architecture and system architecture in the enterprise. And I call that intentional architecture, which may be flies in the face a little bit of some of our thinking. There’s some of the agilest thinking about architecture, but it can’t be strictly emergent in my view. So enterprise systems record potential architecture and I have a model for that. That was brought to me by others that I had the great privilege of working with a couple of enterprises that were quite Agile and also needed to re-architect their systems. I call that re-architecting the flow. So that’s item number three.
And fourthly if the teams are Agile and the programs are Agile, but the enterprise isn’t, if the portfolio is still being treated with fixed budgets where people must be assigned to tasks. And in month nine, in order to justify keeping them on your program or the portfolio function is driven by those who understand requirements independent of implementation and communicate that and make commitments on behalf of the teams and programs, then you’re not going to be very Agile either. And there is a set of legacy minds that are there that I think we have to cope with. So that’s item number four.
Lastly, and this is where I’ve been spending most of my time lately, and so many things are obvious in hindsight. I think we’re all brilliant in retrospect. It’s just the going forward part where we question our sanity. Lastly, your enterprise is going to be no leaner than the executives thinking and no matter what you try to do at the team or program level, until your executives are totally on board.
Not with Agile so much because Agile for them is good, sounds great, but they don’t do Scrum. They either think their teams are already empowered or maybe that’s just not a big concern of theirs, depending upon their cultural bias and mindset and history. So, we don’t have a lot of tools for them in Agile. You can’t take them the manifesto. It’s useful, and they’re interested in that but it doesn’t drive their lives.
It’s tough to communicate with high-level executives about Agile practices in a way that’s meaningful for them because they don’t do any of it. But Lean, they can think about and understanding the value stream and understand how certain, let’s just say, governance items really caused delays in the value stream and understanding that the total tack time, the touch time, we put on a system is a small percentage of the total delivery time; getting them thinking about delays in the value stream and what causes those delays and what they can do about it, is just a better approach.
I’d like to think in terms of two sub-aspects. One is Lean education and I have one go-to source now, which is Reinertsen’s new book that I like to use with executives and have them read it and sit down and discuss some of those key principles. Then lastly, you’ve got to show them how their enterprise is going to look like after the transformation, and I call that the Agile Enterprise Big Picture or the scaled Agile Delivery Model. If they don’t know how it’s going to look later they’re not going to be very comfortable with a totally self-organizing complex dynamic system that’s just all going to work out.
Even though that’s largely the case, I think the pattern of how teams and programs get organized and how values flows; how they’re involved as fiduciaries of the enterprise level; how the governance model works; how they drive the portfolio, is critical to them. Because if they can see and after they know the current picture, they know how it works now and they know there’s some challenges but they wouldn’t be reconsidering it ?? but if they can and after it just makes their life a heck of a lot easier. I call that Lean Education in the Big Picture.
So those five keys, not everything’s user story for sure, think in terms of Agile programs not just Agile teams. Admit that our large scale systems require intentional architecture. Think about some of the legacy mindsets we’ve had in portfolio management and how to address those. Then also understand that we’re going to be no leaner than the executive’s thinking. Those are the keys that I currently keep in mind whenever I approach a barbarian at the gate of the not as Agile an enterprise it wants to be.
Lean Sales and Marketing: Learn about using CAP-Do