A part 2 of yesterday’s blog postbased on this related podcast and transcription: Leffingwell on the Lean Agile Train. 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.
An excerpt from the podcast:
Joe: When we go into the portfolio management, should that be based on Agile?
Dean Leffingwell: Well, there’s a question because it won’t start that way. First, I want to give credit where credit is due and not just pick on the PMO or the other PM guys that were trained. The PMO’s have built governance models around the waterfall life?cycle model because we taught them that was the way to write software. We have new ways that we’re writing software now, and we have to teach them those too. But in the meantime, their governance models and all of their activities are focused around the milestones and things like design reviews and test plan complete, requirement sign off, and code freezes before defect triage, we taught them all that stuff. We shouldn’t be surprised as agilists when we go to instill and install Agile and they’re saying, “That’s just great but you still have to meet the phase to exit gate which requires that the design is complete.”
Yet, if you go to those teams and say, “When will the design be complete on this project?” They’ll look you straight in the eye and say, “The day we take it out of maintenance.” Not in the phase two milestone review. There are a lot of legacy mindsets that are there, but they’re not there because we have people that think in legacy terms. They’re there because that’s what we taught them.
I think we have a responsibility to educate them with Lean thinking, and I have better luck looking at things like the way milestones… Let’s just say there’s a design review milestone on a program, and the program is late. I ask the PMO, I say, “Well if the program is late does the review move to the left or the right?” Meaning forward in time or later in time and they say, “Of course the review moves later.” I then comment to the fact that what you’re saying then is that the later the program is the less often we look at it, right?
They go, ” Well that’s not very Lean thinking.” Because that’s the opposite of what we should be doing and since we don’t know if for sure it’s late or right, why don’t we just do periodic review on a cadence and we’ll review maybe all the programs on the same cadence and look at whatever they’re doing. But if they’re not creating design specifications for us because they’re Agile, they’ll be creating code. Why don’t we assess the code? Let’s ask them for a few key measures around the code. Let’s ask the product managers or customers or whomever how it is they see that the see that the code is developing.
Let’s look at the facts. Let’s look at the quantitative objective facts of how the code is evolving. Because in Agile, there will be no excuse for not having code. While they may not have some of these other things that you’re used to seeing, they’ll have a test strategy. They may not have a test plan because to write down their test strategy into a plan, number one; they have a model that’s integral. It’s no longer separate activity. Number two, they only write down what they need to write down, and they’re not going to write that down just to give to somebody else. So, let’s just look at the code.
So when you approach the boundary of a PMO, the way I like to approach it is that your governance model got us here. The waterfall development got us here. We’re moving forward. We’re not just going to throw away governance, right? We still need oversight; we need to know how we’re spending our money.
We still need to drive the teams to the right vision and the right programs. That hasn’t changed. But the practices that we’re using have changed materially. So before I just make these milestones go away, let me give you some suggestions for new ones.
How about this; how about each program has a milestone review every 60 days and every 60 days we’re going to look at the current amount of working code, the current defect count, the current feedback from the customers and the current plans for distributing that piece or how it’s doing if it’s already distributed. Get their mind around assessing the actual use of the product or actually looking at the application rather than looking at their intermediate artifacts that we used to create, the code was all being done in parallel before we couldn’t really run much of it. All we had were these artifacts.
The code was so hard to change we had to try and get the requirements right, so one of those artifacts was our software specification. Well, we don’t do that anymore. We do have software requirements. They’re called user storage and acceptance criteria, but we write them just in time.
We want to make sure even though it can seem fairly pointed sometimes, and sometimes the PMO has looked at the mother?ship of all impediments, I don’t look at it that way. I look at it as one of the elements of the enterprise that’s going to be transformed as well. There again, you’ve got to go in with different tools.
They can think Lean; they don’t care about a daily stand up or how a Scrum team works. That’s not part of what they do. So taking them, teaching them Scrum it’s kind of an interesting experiment, but they don’t do Scrum. You got to speak in their terms, and that’s basically the business economics, how Agile and Lean thinking drives business economics and the principles.
Again, some of the principles of product development flow that I like to lean on Reinertsen’s work for that they can use to help improve the overall enterprise performance.
Lean Sales and Marketing: Learn about using CAP-Do