PMI Agile – Debate or Learning Opportunity?
Vasco Duarte over at Software Development Today has launched a grenade at the PMI Agile organization with his post PMI vs Agile, what is different, and why you should care. He was responding to Lynda Bourne’s post Agile: The Great Debate. I started writing a comment that became really long so I decided to put this up as a blog post.
First, I must admit to having an advantage over Vasco in that I know Lynda Bourne. She is a talented and smart project manager who focuses on issues of engaging people in the right way. People in the Agile world would appreciate her sense of humor, empathy, and focus on treating people the right way. I don’t know Vasco. I like what he says on his blog for the most part, I see his tweets and comments on Twitter, and I think he is an intelligent experienced guy with a valuable point of view.
This conversation fascinates me for a number of reasons. First, one of the tenets of Agile is to value people and interactions over processes and tools. This manifests itself in respect for people and learning. One of the things I teach in my project conversation work is the importance of holding the other person as valid – believing what they have to say matters. Yet in this Agile vs PMI conversation there is a lot of not holding the other person in a very positive light. Another is seeking first to understand, the common approach is to point out what is wrong with the other persons world.
In her post, Lynda points out that there are three areas for discussion between PMI and Agile.
- How do Project Management practices differ when interacting with Agile development vs. Waterfall development?
- Can traditional Project Management learn from Agile?
- What triggers choices between operational maintenance, development and projects and waterfall vs agile techniques.
I think these are good points for traditional Project Managers to understand as they make decisions about how to support a project with an Agile software component.
Vasco took offense about two points Lynda made in the first question regarding a PM moving to Agile from Waterfall. Remember as you read this that she is writing on PMI’s website to PMP’s.
- The need for robust change management and configuration management to track the evolution of the Agile project
- The critical importance of developing the correct strategy and architecture at the beginning of the Agile project
Vasco says these points reflect a lack of understanding at PMI regarding Agile. He claims her explanation to PMP’s that Agile projects have a strong dependency on change management and configuration management indicates she has no understanding of Agile. However, her reference to change management is in the same sentence as one to configuration management. She is absolutely referring to code. Since many PMI managers aren’t software development manager’s they likely don’t understand the critical nature a robust CI/CM infrastructure. In fact, many “agile” projects fail to implement these and this leads to project disasters. I feel her point is completely valid and Vasco’s retort is not helpful.
Vasco then says she is asking for BUFD. She didn’t say you need a Big Up Front Design. She said you need an Architecture and a strategy for delivery. Even the link Vasco refers us to agrees with Lynda. The first slide asks, “Architecture is a heavy-weight activity, and the magic of Agile makes it unnecessary to bother with up-front design, right?” Their response is, “False.” The presenters point out that this is a common misconception even among Agilists. I believe that Vasco’s retort reflects a bias against bad PM he has faced and does not reflect the validity of Lynda’s post.
Agile (Vasco refers specifically to Scrum) is about Software Development. In most organizations, software development is about 25% of the solution. People, processes, and management practices have to be addressed as well. And not just within the development and delivery of software, but across the entire organization. Project Management deals with this bigger world. The big opportunity is to learn from Agile how to align with and improve delivery outside of software and how to support Agile so the development team can deliver value to the organization with a minimal amount of friction.
I am not suggesting that PMI and all PMP’s have a clear understanding of Agile and how to implement it. I agree that there is a lot of discussion that needs to be held to make the two perspectives meet. I do think it is important that the perspectives meet. PMI is reaching out to the Agile community. They are making an attempt to understand and be understood. There is also a real need for us to bring these areas together in a way that drives value through our businesses.
Tags: Agile, PMI Agile, Project Management, SCRUM
As a PMP that made the move to agile, I think both approaches have their place. Every project is unique. Some projects would benefit greatly with an agile approach, others will do fine following a more traditional approach. It’s up to the project manager to decide what approach is best and having the tools in his/her toolkit to solve the problem at hand.
Thanks for the comments. I believe you raise important errors in my arguments and I’m willing to accept that my post is indeed a grenade.
Thanks for taking it and answering it. Let’s keep the discussion ongoing. This should not be the end of it as there are a lot of mis-conceptions (some of which I alluded to) in the PMI community.
When we talk about project management it is important to understand that most project management that is done in IT is about “software” and how that is developed. Most of the knowledge codified in the PMBOK is from other industries, *NOT* from software. The whole point of the agile movement is that even if there are similarities to other work software is indeed different and requires specific attention.
Cheers and let’s keep the debate going!
Bob,
Thanks for your comment. I agree with you the every project is unique and you need to bring the right tool to the problem. I spent the 80’s and the first half of the 90’s as a software developer, application architect, development manager. I then became a project and program manager, earning my PMP in 1999. I have been leveraging Lean and Agile approaches to software development in all of the projects I have managed in the last 10 years and completed my CSM course this year.
I have a lot of tools in my tool kit, am always learning more, and agree that no single approach is always the best one.
Vasco,
Thanks for giving my comment a fair hearing. I have been involved with PMI for over 10 years. I moved over from software development and architecture because I saw a need for PM’s who understood software. I disagree that the processes documented in the PMBoK, especially the fourth edition, are not important in Software Development. I agree that the practices must be performed differently for software development then for an infrastructure project, etc. I also agree that they way they are typically practiced (and commonly understood) does not lead to productive software development. I look forward to continuing the discussion.
I would like us expand and discuss the original dilemma Ken Schwaber run into. Software development is not a predictable process. Building the 10th home based on the same blue prints is. Software development, empirical process, needs another kind of control, continuous feedback to be managed. The predictable process needs a plan and control to stick to the plan and maybe adjust it a little bit when needed. These are very different domains. Using the wrong control method for the wrong problem results in problems.
Somehow at the front of the religious wars people tend to forget this basic difference which Ken discovered. It is very important.
Also, I have seen hardware development processes. They are also empirical, not predictable. I claim it is not only software development that needs agile. It is development in general. When you are doing something for the first time, look into empirical process control methods. At best its best, agile software development should be that.
Jukka,
Thanks for your comment. I absolutely agree that software development is not a predictable process. Having spent some time in the construction industry I will tell you that weather, permitting, contractors, defective materials, and a dozen other factors make building homes less predictable than you understand. Most software is not a completely creative process either.
I am of the mind that there are at least four big categories of projects. Very well defined projects like construction projects. Research and Development projects that are performed to learn something or discover something. Very high formality projects with no room for error like the space shuttle. And projects to create something new. Most software development projects and organizational change projects all into the last category.
These happen on a spectrum of understanding and predictability. The PMBoK Practice areas are important in all. The methods of performing the practices need to be of appropriate ceremony and application for the situation. Agile provides an implementation of pm practices, a focus on engineering practices, and an approach to leadership that are appropriate for development projects.
Configuration Management is crucial to successful Agile.
It isn’t about batching everything up and moving files around once a release. Ideally the infrastructure supports a Continuous Integration solution to support rapid code deployment.
If you want to go a step further and bake in Lean Startup concepts, every member on your team should know how to deploy code! You’d also have a Cluster Immune System in place to prevent rapidly deployed code from adversely impacting site performance and user experience.
These concepts are often overlooked, so the fact that she even acknowledges Configuration Management is a plus in my book…
David,
Thanks for your comment. I think that is exactly her point. If you are a PM with an Agile development component on your project, you better care about the CM/CI capabilities. These are enabling capabilities that allow the rapid deployment of working code to be performed reliably.
Dennis, thank you for your answer. Very interesting categorization of projects. Sorry I at tempted to say it is not very useful to this discussion. All the three latter types you name are projects where something new is developed. I.e. they are empirical, not predictable.
A question outside the scope of this discussion: is construction work really predictable? Maybe not.
I have worked in safety and security critical software projects. As a problem, they are just the same as other software projects. Evidence of what was done is needed at the end on paper, but this requirement does not change the fact that the project is trying to solve a problem that has not been solved before with means that have not been tried before. Often they also include pure research as part of the project. Planning these projects far ahead, freezing their requirements always fails or results in less than optimal outcome.
In my experience, iterative and incremental development works also in safety critical projects. You need tools to provide clear visibility to the current status of the project at all times so that you can react and adapt. Visibility and adapting is the key. Detailed plans on the long term are practically useless. It turns out, they cannot be followed anyway.
I also had a colleague who worked on the space shuttle. Guess what, the software was done incrementally and iteratively. The software was continuously integrated with mock ups for parts not yet implemented and the aim at least was to address all problems early. Testing was not done at the end, only.
Getting your strategy and architecture right always helps, yes. Some of us have accepted that no matter how hard you try, you are likely to fail. Even if you are developing a space shuttle. The point of agile is that you accept this 99% likelihood and develop means to see it early and efficient means (dare I say agile means) to change them when you see the need. If you need to fill in 10 forms, have 5 committee meetings and 8 approvals for every change, you are not agile. That kind of formalism does not benefit safety. It endangers it because it does not allow the project to learn after something is “frozen”.
Jukka,
Yeah. That was kind of my point. That all projects need the same project management practices but that the implementation of practices should vary as appropriate. I understand NASA and DoD follow an incremental delivery model. Small bets are a part of Agile. They also have a robust architecture and strategy defined at the start of the project. I don’t see how anything either of us said is in conflict with Agile concepts or the PMBoK practices.
Does PMBoK have a requirement that you have lots of forms, committee meetings, and approvals for changes? Does PMBoK require the project definition to be frozen? Is learning prohibited on a PMBoK Project? Did NASA build the space shuttle by shooting from the hip? I am missing your point.
Dennis, we violently agree.
I have seen that when “formalism” is required, some, not you, think this means freezing requirements, approving and sticking to plans, everything signed by 5 people at least, etc.
If I must try to find something to argue about, and I really shouldn’t, I still see only two kinds of projects: predictable and unpredictable. I don’t think it is very useful to analyze them to more categories if dividing projects to these two is already too hard.
A few quick points:
1. The future is always unpredictable – if anyone could actually predict the future bookmakers and casinos would be bankrupted. The issue of project controls is discussed at length in Scheduling in the Age of Complexity see: http://www.mosaicprojects.com.au/Resources_Papers_089.html. This is an issue for all projects and all types of planning and design and a major cause of the GFC!
2. Determining the optimum approach to any activity is crucial. Particularly in IT the boundaries between operations and routine maintenance and project work is blurred. As is the optimum processes for developing new code. The problem is not the degree of uncertainty rather the unrealistic expectations of key stakeholders. Given unrealistic expectations are unlikely to be fulfilled; IT practitioners need to learn how to influence senior manager’s expectations if their projects are ever going to be successful. There are a range of posts on my blog discussing various aspects of this conundrum, see: http://mosaicprojects.wordpress.com/
3. Lynda has put up a post on her blog at http://stakeholdermanagement.wordpress.com/. Naive attacks on processes and executive management decisions won’t help the Agile cause. The only reason there is an IT industry is because organisations use IT, practitioners need to learn the skills needed to communicate with the ‘hand that feeds them’ if the value of IT is to be properly realised. In most circumstances, IT is an enabler not an end in itself and the IT component of a project needs to fully integrate with all other aspects.
Pat,
Thanks for your comment. You agree with your points. Lynda’s post is excellent as well. It is particularly important that IT practitioners, Project Management practitioners, and Executive Management work together to optimize the way organization’s deliver value to their customers. There is benefit in the small in the way Agile improves delivery of technology. Without a coordinated approach that respects the socio-technical realities of delivering technology integrated change in organizations, the conflict leads to trashing, value destruction, and broken promises.
Pat and Lynda have a lot of valuable research and applied experience documented on their web sites, http://mosaicprojects.wordpress.com/ and http://stakeholdermanagement.wordpress.com/.