A range of IT commentators are confusing a product development methodology with project management. Agile is not an IT project management methodology any more than choosing to use pre-cast concrete in preference to brickwork is a construction project management methodology.
Agile is certainly a useful product development methodology for many IT applications and would probably be extremely useful in other situations such as developing training materials and many business change projects where most of the deliverables are relatively intangible. However this cannot turn it into a project management methodology.
Project management is the process of defining scope, deciding on methodologies, creating teams, and all of the other project management processes defined in the PMBOK® Guide. If agile is chosen as the product development methodology for an IT project it will certainly influence the way the project is planned, resourced and controlled but Agile itself is not ‘project management’. This is no different to the need to plan and execute a building project differently if all of the walls are delivered to site as precast panels compared to having workers build the walls in situ using bricks or blocks. If a project exists, project management is the overall controlling process not the selected work delivery process.
What is lacking in most commentary I’ve seen on Agile is any sensible discussion on using Agile within a project environment. The critical changes to scope management, change management, cost management and time management needed to effectively deal with the fluidity of Agile, within the constraints of a project, need discussion. Project Management is still about delivering optimum value based on a predefined framework of time, cost and output and managing changes within this structure.
It would seem many of the advocates of Agile are actually suggesting abandoning project management in situations where the client cannot really define its requirements and adopting a different form of management where conversations control the process development in a collaborative environment and the overall team’s focus is on achieving a ‘happy outcome’ for everyone. The primary constraint in this space is the resources capacity to deliver ‘sprints’ and the organisation’s budgeting process is focused on paying for a more or less stable team of people working consistently on improving the business’ IT infrastructure to service its operational areas.
This would suggest there are limitations to the traditional ‘project management’ paradigm (and I have always felt PM was a focused form of management – see Project Fact or Fiction from 2002) and the emergence of a different paradigm. If this observation is correct the real focus of discussion should be where PM works best and where the new collaborative ‘agile paradigm’ works best.
Comments are welcome and I will blog more on this idea later!!
Pat Weaver
Lynda Bourne
Mosaicproject's Blog 
Mike has definitely tackled this area, and has mentioned efforts on incorporating agile into the PMBOK
http://agilesoftwaredevelopment.com/blog/mcottmeyer/how-talk-project-managers
http://www.leadingagile.com/search?q=refactor+your+PMP
Thank you for the links and comment Kevin. Unfortunately the referenced authors seem to be making the same error as everyone else I have read. Project Management is NOT a synonym for IT development.
You can develop IT systems using project management or using a range of other processes. PM is not the answer to everything.
You can make project management a relatively light and flexible process or a ridged structural process. My preference is as light and flexible as practical (see: Improving Schedule Management – http://www.mosaicprojects.com.au/Resources_Papers_081.html)
What you can’t do is call an IT development methodology like Agile a project management methodology unless it could also be used for constructing a new airliner or an off shore oil rig. On your second link ‘leading agile’, Mike Cottmeyer certainly has made a start looking at how PM processes can be adapted to maximise the benefit of Agile development but there’s a long way to go in the general commentary I have seen.
Thanks for the input.
Pat,
Great concept. If you look at the SEI CMMI process areas, Technical Solution (TS) and a few areas around it – those with direct connections to TS are “product development” activities.
Project Management in CMMI is a seperate process group.
So starting with this framework – or any similar – it is easy to see Agile is an product engineering method. Not Project Management.
Pingback: De- Projectising IT Maintenance « Mosaicproject’s Blog
There is a lack of clarity on the various aspects of Agile. Scrum is a set of project management approaches that addresses scope, cost, schedule, communication, and risk management. The focus is on frequent delivery, continuous process improvement, and lots of communication. It places a strong priority on predictabiliy and quality. Glen Alleman might point out that this is just responsible project management and is probably right.
XP and many of the “Agile” approaches, are specifically focused on developing software and typically integrate software engineering practices. They typically integrate all the other product development aspects of CMMI. SEI has a paper called Agile and CMMI, Why not Embrace Both at http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html that discusses this alignment. The Scrum practices are within the PM processes, and the development processes are not.
My goal here is not to defend Scrum, but to keep those of us who are working to improve the project management profession from throwing the baby out with the bath water. There is a lot to be learned in the PM community from the successes that many Scrum teams have experienced – just as the typical Agile community has a lot to learn about managing projects in a responsible fashion.
Hi Pat,
I think agile is very clearly for software development only. Even within that, I would add that is is better for NEW software development, as opposed to maintenance or enhancements of legacy systems (though it can be used for that also).
The whole focus of Agile has been the realisation that software is *different* from, say, civil engineering, and we dont need to build software the way we build dams.
For example, software can be changed mid-way or even near the end in a way that a power plant cannot. Hence the rise of Agile as a way to take advantages of these differences as a better way to build software.
I dont think anyone is really claiming it to be a generic project management solution. In fact its history and roots suggest quite the opposite.
Also, I don’t think the analogy of pre-cast vs bricks hold here. That is an implementation detail – like whether a project should be implemented with Technology A or Technology B. Agile does not deal with that. It deals with the management of the project – what to build, how to plan it, how to estimate, and how to deliver.
However, there are some folks doing studies on whether agile principles can be applied in non-software domains (mostly general organisational management). This is known as the Agile Project Leadership Network. The website is http://www.apln.org/
Project Management is a PART of Agile Development Methodology.
PMBOK sucks for software development. I mean REALLY sucks.
Agile is three things…. software engineering best practice, project management framework, and leadership values and principles.
When looking at Agile from the Project Management angle… you can apply many of the traditional methods from the PMBOK in a more agile context.
To me, it comes down to your assumptions around uncertainty and the cost of change…
If you are in a very certain problem domain, or one where the cost of change is negligible, or willing the cost of change is acceptable to the stakeholders… traditional PM methods work well.
When you are in a highly uncertain domain, you need to adapt your PM approach to less of a plan driven model to more of a rolling wave planning model.
Yes, you can use traditional methods to manage a rolling wave or an agile process… the question is should you. Can you afford the cost of process and the cost of change?
Where time to market is critical, and change is highly likely, and you have to do things as inexpensively as possible… agile as a project management framework makes sense.
Do you still have the five process groups? Yes? Do you still have the nine knowledge areas? Yes? You adapt the PM processes to be applied as lightweight and adaptive way as possible.
Another way to look at this is that project management is all about time, cost, scope, and risk. Agile mitigates risk by fixing time and cost and varying scope.
It also mitigates risk by decoupling dependencies between requirements and building the highest priority requirements first. That way if you have to cut and run to market, you can.
When we take a fixed scope approach, we often lose that option.
The challenge in this conversation is that your approach will be very domain specific and situationally specific. It is not one size fits all.
This is something we’re in the middle of discussing right now in my Fortune 500 company. That is, how to do fixed bid budgeting, yet stay Agile.
Most has to do with the misunderstanding that you have to abandon project management in order to use Agile. We are working out the process of getting fixed bids yet variable scope… keeping the budget folk happy yet staying Agile.
Any suggestions are welcome!
“Agile” is a heavily overloaded word. There are actually (at least) three broad ways the word is used:
1) Agile as in software engineering techniques such as Test-Driven Development, Continuous Integration (for example Extreme Programming),
2) Agile as in method for iterative and incremental delivery, usually of software, but not exclusively (for example Feature Driven Development), and
3) Agile as in framework for learning and responding to change (for example Scrum and OpenAgile).
It is true that in none of these cases is Agile a project management method. However, in senses 2) and 3), there are aspects or practices that overlap with project management such as scheduling, communication, inception and delivery, managing constraints etc.
The biggest difference is that most agile approaches philosophically avoid the following:
– imposed processes and tools
– heavy documentation
– contract negotiation
– following a pre-set plan
(see http://www.agilemanifesto.org for more detail)
This is not to say that PMBoK-based project management always insists on those things, just that Agile makes a value statement about those things that PMBoK avoids.
One consequence of this is that agile methods and traditional project management don’t tend to work well together, even though agile methods don’t directly replace traditional project management.
Outside of software, the first two types of agile (engineering techniques and interative, incremental delivery), may be difficult to apply. However, the third type of agile, a learning and change-response system, work well for almost any type of work. Think of it as a version of the scientific method re-cast for use with non-objective humans as both scientists and experimental subjects. An agile team in this third sense does work and learns from both successes and failures (experiments) to improve both the work and how they are doing it.
Hi everyone and thank you for the comments,
I have posted Michael Michael Dubakov’s comment but do need to reply.
The PMBOK® Guide has ABSOLUTELY NOTHING to do with software development. You are making the same mistake 90% of the people I read sprouting about Agile make.
The PMBOK® Guide is a compendium of generally accepted project management practices that work for most projects most of the time world-wide.
How a business or a person decides to implement these good practices inside a project should depend on a range of factors and the first question to ask is are you doing a project? Projects requires as a minimum:
– A client that knows what it needs
– A defined scope of works that can be budgeted and scheduled
– Clear success criteria
– A clear understanding of risk
– Both the client and the delivery team being prepared to undertake the endeavor applying the disciplines of ‘project management’.
Agile can work in this environment provided the PM processes are properly adapted. Agile may also be able solve the problem PM cannot which is an IT client who has no idea what it wants and no idea what success equals.
Unfortunately a vast number of IT managers have assumed the use of the ‘PMBOK’ will solve all of the businesses problems in IT development. It won’t and it can’t.
Project management is quite a limited process. PM and the PMBOK® Guide are designed to facilitate the efficient creation of a defined output and are about the managing of the processes needed to achieve the output efficiently. This is nothing to do with the way the output is created.
The purpose of this blog and the following blog De-Projectising IT Maintenance is to highlight three critical factors:
1. Agile is NOT project management it is a product development methodology.
2. An IT development is not necessarily a project – there are other ways of achieving a good outcome.
3. It is possible to run a good project using Agile as the product development methodology.
I will be bloging on how project management can be efficiently used to control a project development based on Agile in a few days.
>>The PMBOK® Guide has ABSOLUTELY NOTHING to do with software development.
Exactly! That is the reason why it DOES NOT work for software development. House Building != Software Development. Software Development Project has MANY differences. The main one is that you can’t create explicit documentation that allows you to generate code (so far), thus you inevitably create something that differs from customer’s expectations. Thus you need to iterate to meet the expectations. Iterations are (almost) not required in pure engineering projects.
You are partially correct Michael.
Some software clients cannot express their requirements adequately and iterations are needed. This does not negate the PMBOK provided the appropriate processes are applied properly – more on this in a few days. However, a lack of ‘knowing’ on the part of a client does negate the value of software development methodologies such as Waterfall.
There are software projects that can and are fully defined before one line of code is cut. Some I have been associated with include weapons control systems, building security systems (particularly in secure facilities) and process controls. Critical design requirements such as avoiding a ‘single point of failure’ cannot be iterated, they have to be designed in at the beginning or you kill someone.
In any project the people involved need to decide to manage the work as a project (this is not mandatory), then decide on an appropriate strategy for delivering the required output (including selecting appropriate methodologies to use), then apply the appropriate project management processes in an appropriate way (assuming the decision was to undertake the work as a project).
The PMBOK® Guide pretty much defines the framework for project management other international standards are all closely aligned. Blaming the ‘PMBOK’ for incompetent management and/or for inappropriate decisions on methodology is about as sensible as blaming Ford and GM for car accidents.
In the same way ‘Agile’ is not a project management methodology neither is ‘Waterfall’ – they are both software development methodologies. Most of the ill informed criticism I’ve seen directed against the ‘PMBOK’, generally from people with no formal project management training, should actually be directed to the ‘Waterfall’ software development methodology and its derivatives. If project management is being applied properly it should sit above and facilitate any appropriate product development methodology including Agile and Waterfall.
……There are software projects that can and are fully defined before one line of code is cut. Some I have been associated with include weapons control systems, building security systems (particularly in secure facilities) and process controls. Critical design requirements such as avoiding a ‘single point of failure’ cannot be iterated, they have to be designed in at the beginning or you kill someone.
Anyway there is no way to prevent software from bugs. Software killed many people and will kill even more. Do you think that Waterfall in ‘mission critical’ software works better then iterations? I did not see any research paper on this topic. What if we try to create medical software using iterative approach? Do you know the answer? Maybe it will have less bugs. Why not?
……In the same way ‘Agile’ is not a project management methodology neither is ‘Waterfall’
Definitely agree. Agile is a [software] product development process.
I believe waterfall can work only in 2 cases:
1. you have relatively small and typical project.
2. somehow you managed to create specification that can be directly converted into code.
Otherwise you will inevitably iterate to meet the goal.
I think that a lot of confusion over Agile “vs.” PMBOK is due to confusion about the PMBOK rather than about Agile. Agile is, indeed, a product development methodology, and it contains details of a specific implementation of project management practices. Agile tells you how to do certain aspects of project management.
As the title suggests, the PMBOK is the body of knowledge for project management. It doesn’t specify how to do project management, and is not intended to do so. Instead, it is intended to summarize the knowledge that someone playing the roll of project manager needs to understand in order to successfully deliver projects on schedule, at cost, and on scope. How the performing organization or the project manager implements this knowledge is outside the scope of the PMBOK.
I would argue that nothing in Agile contradicts the PMBOK, or good project management practices in general.
I can think of nowhere that the PMBOK requires, for instance, a detailed project plan from project start to project end. Indeed, the Agile sprint process is referred to as “rolling wave planning” in the PMBOK, and is recommended when the total product requirements and statement of work cannot be defined at the start of the project (as is the case with Agile projects). The Sprint burndown chart is a particular project performance measurement that falls under the PMBOK’s Monitor and Control process area. Scrum planning meetings are used for scheduling; sprint planning and review meetings are used for stakeholder management; daily scrum, sprint planning and review meetings are used for scope change management.
Project management practices, and the knowledge highlighted in the PMBOK, need to be implemented in a manner that is consistent with the needs of the project team and stakeholders. The evidence clearly shows that Agile accomplishes this for at least certain types of projects.
Michael wrote: “…there is no way to prevent software from bugs.”
This is not entirely true. Clean Room techniques have been demonstrated to produce defect-free software. Of course, Clean Room product development techniques only work when the product can be completely specified up-front and adequate time can be allocated to specification and development. There are lots of domains where Clean Room wouldn’t work.
Guys… I appreciate everyone’s passion around this topic… but there is one thing we need to recognize… there is no way to be fully aware of each others context while we are having this discussion.
Each of the points presented here are all partially correct, partial representations of the truth. We are all going to see things from our own point of view and truth is not absolute on this one.
Take a look at Dennis Stevens telling of the parable of the blind man and the elephant. We are all describing aspects of the truth from our point of view….
http://www.dennisstevens.com/2009/03/03/regarding-the-blind-men-and-the-elephant/
I encourage us on both sides to listen more to each other an explore how all these methods and approaches to project management and project development help us deliver better software.
It doesn’t really much what we call or categorize things as long we strive to understand the each others language and point of view. What do we each contribute to the greater understanding of the whole.
Mike
Agile came out initially as a software development methodology. It focused on a part of what we consider as project management but it went deeper. Methodologies like XP or full-blown Scrum organize development in more formalized way than typical project management technique ever would.
I think the reason of confusion is that we have projects which are pretty limited to software development tasks.
There are none mandatory project management techniques which has to be used or one can’t call it project management methodology. If you don’t need that you don’t use that. I’ve seen projects with no budget management or with no stakeholder management. And I can’t say they weren’t real projects.
However when you go with complex custom development project for big company and you have to employ a bunch of subcontractors agile is not enough to cover it all. In this point I fully agree.
Of course that doesn’t mean agile is a wrong choice to cover a software development part of the project either.
I agree with you Pawel. The decision making process for any industry/business should be:
– identify the problem,
– decide how to solve it (choose a technical methodology)
– decide how to manage it (select project management or other options – there are plenty to choose from)
– apply your chosen management techniques to the technical methodology
– hopefully solve the problem.
Project management can be adapted to facilitate effective software projects using Agile as the development methodology (see: https://mosaicprojects.wordpress.com/2009/03/07/managing-agile-projects/) but only if the client and the developers are agreed the disciplines of project management will add value. There are other options.
The trigger for these blogs was a series of misinformed comments that assumed Agile equals Project Management. It does not and it never has. I certainly don’t use project management to develop our businesses web sites or for other creative processes, we use an iterative collaborative process. I would not call it Agile but we certainly don’t pre plan the outcome in any detail. The journey and flexibility are far more valuable.
Pingback: Managing Agile Projects « Mosaicproject’s Blog
Pingback: The Last Planner and other Old Ideas « Mosaicproject’s Blog
Pingback: Linkopedia June 2009 | From the Editor of Methods & Tools
Pat,
I was with you right up to your last post where you said:
“I certainly don’t use project management to develop our businesses web sites or for other creative processes, we use an iterative collaborative process. I would not call it Agile but we certainly don’t pre plan the outcome in any detail. The journey and flexibility are far more valuable.”
You are basically demonstrating the same behavior that you complained about in the beginning – comparing product development methodologies with project management methodologies.
In fact you do use project management when you develop a business web site. It just happens to be very informal, and nothing close to one that exercises the full set of processes found in PMBOK. Step back and think about what transpired which initiated the need, which led to the design, the execution, and some form of completion. It may not have been formal, but it was a project and it got managed.
How you developed the *product*, which in your case is a business web site, is via a development methodology what you called not quite Agile, etc. Just because you didn’t pre-plan everything doesn’t mean you did not manage a project.
I think this demonstrates how easy it is to confuse project management and product development. The sooner we all realize both are needed, just in varying degrees of structure and varying forms of design, the sooner the confusion will go away.
John
Trust me John, after 40 years I know a project when I see one and I have also learned that everything is NOT a project even if it is in IT or web space. Looking after our web sites is just a normal part of routine operations – that’s our organisations choice, others may chose to scope similar work into a project and then chose an appropriate project methodology for the delivery. Projects don’t exist in the wild – they are created by overt management decisions.
One of the other posts in this series looked at maintenance, see: De-Projectising IT Maintenance
At a more theoretical level working out a proper definition for ‘a project’ is work that sill needs to be done. For a discussion on this subject see: Developing a concise definition of a Project
Pingback: Êtes-vous un gestionnaire de projet agile ?
Cleanroom works perfectly fine in an agile context. All the books that came out on the topic were in the late 70s/early 80s, so of course it’s predisposed towards BDUF, but if you take the principles and lessons learned and apply them to the agile context, you’ll find Cleanroom works wonderfully well in a Scrum environment.
Your comment is perfectly correct but ‘clean rooms’ are not a project management methodology either! They are a software develoment technique the same as the different variante of Agile all of which need managing. And if they are being used as part of the product develoment within a project, they need project managing.
Pingback: Is there such a thing as Agile Project Management? Gosh we hope so... - Agile Learning Labs
Pingback: Do Companies Need Project Managers? - Base and Superstructure
Pingback: Is there such a thing as Agile Project Management? Gosh we hope so… | Agile Learning Labs