Dennis Stevens gave a presentation on Agile Development at a PMI Atlanta Chapter Agile Local Interest Group, titled Agile Fundamentals. The early part of the presentation addresses some of the perceived failure modes of traditional project management needed to produce success. I suspect these are anecdotal experiences from the comments exchange we've had.
I have no doubt Dennis has experienced Bad Project Management. But it seems he converts that bad project manager experience into bad project management processes, in support of the suggested process replacement - Agile Project Management.
I'm worried that PMI is confusing software development practices - and Scrum is the best for some software domains - with existing Best Project Management practices. I was going to compose a long post, but instead built a briefing deck I can use in other places where I encounter this blending of "bad personal experiences," "red herrings from the agile community," and possible confusion between software development practices and the fundamentals of managing those performing the software development practices.
My motivation for this approach is:
- Agile software development is entering the DoD IT Acquisition domain. There are several boundaries in this domain, not the least of which is the mandated Earned Value Management for all programs greater than $20M - which in the DoD world is chump change.
- The DoD 5000.02 procurement process defines iterative and incremental steps for defining, developing, deploying, operating and retiring systems. This process is highly developed and mature. And at the same time burdensome and over stated. Dan Ward speaks to this directly. Dan and I share ideas. Dan is not your typical evangelist for change. Dan is an Air Force Lt. Col with "heavy cred" as we say in the acquisition community, with "hands on" program management experience.
- Dan's F.I.S.T. approach is a nice fit "agile" concepts in procurement of complex systems. But critical to the discussion is ow to build on past processes and principles using new processes and principles. This is the old "throwing the baby out with the bath water problem."
- This Baby and Bath approach has started to enter into my domain - DoD, DOE, DHS program management and I want to set to story straight about the current project management processes and how they can be augmented instead of replaced.
The core motivation here is to separate good project management processes from Bad Project Managers. Only then can we look for ways to improve these processes with Agile.
Keep the baby, toss the dirty bath water. This combination of good PM practices with Agile Software Development is the "real" PM 2.0.
- What if you didn't define everything up front, lock it down, and insist on sticking to that specification? What if you defined the end to end outcome of the project in operational terms, in a set of capabilities for the user. Then defined the progressive details of those capabilities and operational concepts in Rolling Waves?What if there were simple ways to make changes to the Plan. Changes that took into account impacts on cost and schedule - it is someone else's money you're spending right? They have the money and you want it?
If you did that you'd be following DoD 5000.02
- What if you didn't just throw projects over the wall to developers but had periodic engagements with all the participants? Maybe not daily, maybe not in the same room all the time, but at least once a month on a large multi-year development project. During those meetings you talked about the technical aspects of the project as well as the cost and schedule performance. You talked about anything that was not "green" in the Measures of Effectiveness (MoE) - this is how the customer sees the project. And you talked about Measures of Performance (MoP) - this is how the developers see the project.
If you did you'd be following DoD 5000.02
- Since you work on teams inside your firm for external customers - that's how the business was organized before you got there, or even on teams for internal customers, what if someone in your firm was accountable for allocating the resources? What if your firm didn't have enough people to dedicate them 100% to your project? What if your suggested method of staffing did not meet the business model - the labor assignment of 100% created too high a cost for the projected revenue? Would you yell and stomp your feet that they are not following agile principles? Or would you put on your business manager hat and come to realize that somethings are just out of your control for now and when the firm grows some more and you can make a business case for dedicated teams, we'll all have to just deal with the situation until then, or maybe forever if we don't improve or sunk cost ratios.
Try putting on your business manager hat. You're handed a budget for someone. You - as the business manager - are tasked with "getting things done." You've simply have got to multi-task some of the staff. Deal with it in the best way possible. Think about practice over principle - with the business hat on.
- You got a Plan - a business Plan. That Plan calls for products or services to be built in software. The Plan is baselined in some meeting between you; and those asking for the products and services in the Plan. They come back 3 months later after a tour of the world with new information that makes changes to the Plan. You - the software development manager say "nope I'm not changing the Plan, you agreed 3 months ago and I'm sticking with it."
Yea, you're doing a really good job of managing in the presence of uncertainty. Nice try, change the Plan, update the schedule, reallocate your resources, make modifications to the processes and eventually changes to the source code.
- Your QA team or your developers using Junit comes to you and says "boss there's a problem." You say "well guys I don't know what to tell you, our problem detection and resolution process says you've got to wait until the management team meets before you can go any further." Only Managers can define defects and propose a solution here."
Does any of this about top down defects make any sense at all? Probably not. It might even be called Nonsense.
- While your going along developing product, your team comes across some really good ways of "making things better." They're simple, they're cheap, and they probably will actually work. You say to them "fellas we're going make corrections to our boneheaded work process when we're done with the project, so just hang on to those until next year."
Does the term NONSENSE ring a bell?
While there are places where these little examples likely take place, they are of course complete nonsense. They are Bad Management. Fix the Bad Management first...
Stop doing stupid things on purpose