by In industry forums and academia there is a notion of agile project management. I think this is harmful to the Agile movement. Our argument is based on theoretical, operational, people and culture, and capacity management objections. For the purpose of this article our scope is the development of software products and not other types of projects. Also we will use Scrum as an example of an Agile methodology and our Project Management framework will be based on the Project Management Body of Knowledge (PMI).
Theoretical Objection
Project Management implies a start and end date, while Scrum in contrast focuses on sustaining a product.
The Project Management Institute (PMI) defines a project as “temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.”
The Scrum guide defines Scrum as: “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” The guide defines the purpose of Scrum as: “a framework for developing and sustaining complex products".
Operational Objection
In practice I have seldom seen a software product being developed with no ongoing maintenance after the project has finished. The modern trend as espoused by the DevOps movement is that the team that builds the software also runs the software. In the past we normally developed a software project using a project management methodology and then an operations team took over the maintenance and operation of it. Traditional IT models divide implementation and support into separate teams, sometimes referred to as “build” and “run” or “development” and “support”.
The results of this divide is to isolate the people building from any problems they create. It leaves the people who run the system with little ability to make meaningful improvements as they discover problems. Because the most valuable learning opportunities come from how a system is used in production, this dev/ops divide limits continuous improvement. This topic has been discussed in more detail here.
From a pure project management perspective, it would be very hard to do resource allocation using the same team to do the “project” work as well as the production as the project schedule is rather rigid on start and end dates. The Scrum approach would be to use the same backlog for features as well as system enhancement and production issues. Resource allocation is then far more dynamic.
People and Culture
Project Management implies a project manager. This is not the case in terms of Scrum which only recognize three roles: scrum master, developer and product owner. The resourcing assumptions in project management are very different to that of a Scrum team. They key question is: what is the role of a Project Manager in Scrum? It does not exist.
Maybe a more contentious issue is that of culture. The PMI states the role of a Project Manager as: “change agents: they make project goals their own and use their skills and expertise to inspire a sense of shared purpose within the project team.” Implied here is that purpose comes from the Project Manager. My reading here gives me a sense of top down control or in an weaker sense top down inspiration.
Scrum in contrast is more focused on self-organisation. As the Scrum Guide states: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team”. This gives me a different cultural feel to that documented by the PMI.
Capacity
More and more organisations are moving towards a fixed capacity model. As an example from a portfolio or investment perspective the organisation might decide they are only allocating a certain budget to a department or team. The product owner then needs to decide how to prioritise the work to fit the agreed capacity budget. This is a useful approach as it forces prioritisation. It doesn’t exclude more money being made available in exceptional business cases.
Even though fixed capacity resourcing is not inherent in Agile or general Project Management it affects the two methodologies. From my perspective it is easier to prioritise small incremental developments using the daily Scrum and Product Scrum processes than the Project Management process that is predicated on more formal business cases and longer development cycles.
It is from a practical perspective easier to manage to fixed capacity using Scrum than traditional project management.
A possible critique
A concern can be raised that I am comparing Scrum with Project Management rather than Agile with Project Management. This is a valid but not a practical concern. The Agile Manifesto is too conceptual to allow comparison. What I see in practice is mostly Scrum as the lens to look at Agile. The Agile at scale methodologies like SAFe and LeSS are also build on variations on the Scrum construct.
Conclusion
Based on the argument above, and it is probably not exhaustive, I think that that there could be harm done to the Agile movement by forcing it into a project management framework. The Agile movement can be strengthened by using project management techniques but Agile should not be adapted into the Project Management discipline.
Great too see another mind reach the same conclusion!
The #NoProjects movement has been pushing many of these topics and the incompatibility of “Projects” and “Agile”.
I’m finishing a book called “Continuous Digital” on the subject https://leanpub.com/cdigital/
And Evan Laybourn is working on one too, http://noprojects.org/
I worked as a “training developer” aka instructional designer for approx 5 years.
The build process was quite smooth; however the “support” process was quite troublesome; getting resources (previous project collaborators) to revist a “closed” project confirm details or do “damage repair” was challenging because their agendas were being managed and “active build” projects were priority. Additionally challenging was convincing top managent to “re-open” or assign a “new project / sprint” and await “processing” bureaucracies for a required update or fix.
I agree that trying to shoehorn agile into existing project management frameworks is a bad idea. However we won’t get rid of projects or project managers any time soon, nor do I think we should. Agile also doesn’t address many of the problems that project managers have to deal with.
Project managers need to understand agile: and not just read the manifesto, but why it works. Project management needs to go through the same transformation as software engineering has over the past decade.
The article does not address an important aspect. In management terms, we differentiate between supervision and management. SCRUM has proven itself as an excellent agile supervision method to drive results according to the agile philosophy. It successfully drives the achievement of short-term objectives. How would the author plan to achieve medium to long-term objectives, i.e. what is the alternative to project and program management in this sense? Also, how do we keep all the different delivery components aligned to what we need to ultimately achieve? I am not arguing that this should be achieved through traditional project management, which is way too intrusive and would stifle progress, but the article does not provide a credible argument to address these two aspects. This would make for an interesting extension to what was presented by this article.
Good comment, in my opinion it is not one OR the other. Long term en more horizontal focus is for project en programmanagement which can contain scrum(agile) teams as wel as traditional teams. Scrum master has a servant role to the team, productowner has a business responsibility and the scrum team delivers. A project manager makes sure the complete environment, multiple focus areas, finance and controles are aligned. The PM has an overall responsibility (or at least could have) only from a different point of view, especially during transition phases or a compination of traditional and agile processes (programmanagement)
Agree 100%. Organisational size and culture also impact this as well as the type of project – not all projects are software development. I struggled to implement pure scrum in my current organisation but when I shifted the framework to Agile DSDM which basically recognises that most product owners don’t want to deal with much of the admin a project manager does and also recognises that developers are not always the best people to interpret stories from users for implementation so it keeps these roles – PM and BA – albeit modified. Not command and control.
In my opinion, service introduction should be part of the release. And to ensure the support is thought through, there should be service introduction stories. The people who will be accountable for supporting the application should assist in defining the acceptance criteria for the service introduction stories. If a beta release, then perhaps in parallel the overall support solution should be defined as a separate effort with the stories defining the specifics on how the app plugs into the support model.
Hi Josef, I’d be really curious to get your take on the PMI agile certification ACP. It seems to be PMIs answer to addressing Agile in the lense of traditional project management techniques. Do you think it does any good, or is it useless to force project management and agile together?
Interesting article, a few good points. A key point in the argument set forth is that just designing and writing software is all there is to getting software done. There is a huge amount of other work outside of Scrum, or other Agile software dev process) that are requiredl. The Agile movement is fine, and has it’s strengths and weaknesses covering software development. And it is always the goal of a business to be more agile. But there is lot of other “stuff” going on beyond the creation of the software that the PM does that doesn’t fall to the PO, SM, or scrum team. There are legal items, vendor contracts, business cases, hardware purchases, cost management, executive updates, customer negotiation and updates, release management (including updates and prep of training team, support teams, and professional services teams), security and performance 3rd party audits, and a host of other tasks that are not the area of expertise nor responsibility of a development team. This is always the core problem when people debate PMI “rigid” project processes vs Agile “free flow” software development processes. You’re looking at one part of a bigger picture.
PMI also focuses on non-software projects, so their processes do tend to focus on what I would call real projects vs what many people in software call projects. A new release every 3 months of an existing software product or application is closer to an operational process than a project. Could there be a need for better integration of standard project best practices and Agile software development processes? I would argue strongly that this is an absolute goal. To argue that it’s either one of the other, as if they are mutually exclusive, is an incorrect premise. To argue it is harmful to try to be agile, regardless of the process, goes against the general goals of an organization.
I will close with one final point. Project management processes seem rigid and excessive because over the years people have contributed to the body of knowledge to improve on the original set. Agile development processes are seeing the same addition of steps and tasks to address limitations and weaknesses. This is natural, you always see very useful products or processes bloat as people request and get new things added to meet varying needs and wants. What do you think “scrum or scrums” and SAFe are if not adding things to Scrum to address the limitations? As this progresses, things will start to converge and look like other mature best practice frameworks like the PMI.
What a well put together response. I agree that this article has many holes, and also many opportunities.
Thank you for your enlightened response.
The article and the discussions confirmed my doubts on the applicability of PMI principles and PMBOK to software projects (the discussions above even created doubts if they should be called projects at all). PMBOK was created for the projects in the industrial world where projects produce something that is physically present and cannot be changed/redesigned unless it is absolutely non-functional. If redesign has to be done, it is a new project. It appears from the discussions that is not so in the software world. Software projects seem to have infinite life. In the industrial world, a lot of thought and input are put into the planning, design, procurement and construction stages so that the final product will not grossly disappoint the users/owners. It seems the users of the software products have big complaints against the project teams producing the software. Am I wrong? I have never used Agile/Scrum but used PMBOK principles and practices in refinery/chemical plant projects.
Spot on! A traditional project model should not be applied for IT-related development. Especially if related to fast paced business development, driven by a globalized market competition. As is the case for most businesses today. Get the structure and capacity needed to drive constant change in a continuous value stream, measuring value against actual results, supported by short term planning to be aligned to a long term vision. Instead of trying to define and allocate resources for an unforeseen but in detail described future state upfront. It is different managing change when solution context undergo constant change.
I agree in the main with the article, but wish to point out some differences in my opinion and the author. I do feel that PMI is trying to “develop” or create a Project Management structure for Agile and it’s methodologies, why?, I’m not sure, but perhaps to keep itself relevant. For the Operational concerns brought up, Agile has a concept of installing, i.e. running what has been developed, remember, one goal of a sprint is a usable product. If the product is installed and used, that should allow the clients and users to provide feedback, i.e. requested changes to the P. O. and Dev team for addition or rejection from the current backlog, thereby keeping the knowledge and expertise in place until either end of project. Any later or postponed changes can be used for later projects. As for handling Capacity concerns, they can be handled in the same manner as budget or schedule restraints, and I have handled them as such without major issues or problems. Remember the point of Agile was adaptation to change without getting bogged down in procedure. i.e. Get the best possible product delivered as best cost and least strain on staff.
Project Management, and other disciplines and models, has always promote the idea of a “Project Lifecycle” selection as part of the Project Planning process. One of the most known lifecycles is the iterative lifecycle, so, maybe Scrum should not be use in a Project, but a Project, definitively, can be Agile. 😉
The “Agile Movement” is just a cult term for “The Rational Unified Process” which was just a cult term for parallelization (multitasking).
The best example of the failure of Agile is the F35 project which became bogged down in bi-directional change requests. This was caused by over-parallelization of the traditional assembly line into multiple concurrent segments.
It is a fallacy to insist that an inherently serialized process can always be made more efficient via parallelization. It sounds great and looks great on a power point slide, but it usually results in meltdown.
While I can agree that Agile isn’t going to resolve all things it’s still best for projects we can recognize as having “chunks” to deliver on.
I’m not familiar with the F35 project but we can imagine all kinds of things that may have gone wrong. It all starts with a great SCRUM Master and adherence to Agile methodology.
Such a project will be technically very complex and involve interruptions that are not assisting an iterative process. But, I can imagine it could be even worse using traditional means of the 60’s. And, I’m not always in support of Agile for even half of my projects.
Not another ‘Agile is All’ article!
Been doing it for long enough to know that at least 50% of agile outcomes are late and cost more than anyone wants to admit. It often becomes a show about ‘Hey we’re doing agile’ rather than DELIVERING. Celebrations have become mandatory with little consideration of value delivered.
I still come across teams that write pages long stories before starting development and yet claim to be agile.
If project management was such a bad thing none of the systems that are the backbone of everything we see would exist. NASA would not have got a man on the moon.
Focus on delivery and not whether youre agile.
I worked with a SAP delivery not long ago that was waterfall with a PM. They never missed a committed date and quality was always the best.
Dont call it project management if you dont like it.
But do you really believe that great outcomes are achieved without a leader, someone with their eyes on the cost, goal and guiding the team?
Amen!
well said Chandra
+1 from me Chandra, my experience exactly. Be outcomes-based and use whatever methodology (or mix thereof) works for the product being delivered.
Scrum agile does work well for existing IP products to be enhanced. In real life if you are rewritting a software where infrasctructure is involved or when an architect and DB designer have to build the base structure then it becomes less evident to build a shippable product every sprint.
And if you are dealing with a client that doesn’t believe in agile then a hybrid methology would be a good alternative.
Interesting article. Having been both a Project Manager and a Scrum Master, there are definitely strengths and weaknesses to both models.
Agile is great at reducing “product” risk. Building small iterations of the product definitely helps make sure that the product is as closely aligned with the client needs/expectations. However, I have found that it falls short in 4 areas.
1. Most product owners don’t understand the concept of MVP. Instead of focusing on the 3-5 must have features for the product, they tend to demand a product with more features that take more time to build.
2. Some products, while simple in concept, have a lot of interdependencies with other systems/companies. Someone needs to coordinate all of those interdependencies and quite often a Scrum Master and/or Product Owner are not willing to take on this role because it falls outside their job description.
3. Management is always asking the question – when will it be ready to ship. When I put on my delivery hat, I cannot bring myself to respond with “well, we’re agile so we’re not really sure”. Getting a product owner to write all of the User Stories for a product, grooming those stories, breaking the stories into smaller stories, etc. is very time consuming and becomes very much like waterfall. There is a delicate balancing act to being agile and having enough useful “requirements” that developers can begin work in a smart way. It is very challenging to keep a team agile, but then be able to answer management’s question.
4. I have worked at many companies. It is extremely rare to come into a team that is self-organizing. Most people have their own interests and goals. Many times, when left to their own devices, these personal interests/goals do NOT intersect with the company’s goals. One could say it is up to the company to communicate it’s goals and find people that want to live up to those goals so teams can be self-organizing, but that’s too complex a question for this.
Question is: are PMI’s definitions right ? If you look upon projectmanagement from other angles, PMI’s definitions may appear to be superfluous, or simply wrong. That would also mean that this discussion is superfluous, for the basis of the argument rests on a non existent dichotomy.
I have managed iterative and cyclical projects for more years than I care to remember. Organisation level objectives are rarely agile, they are prescriptive and measurable. They require a process of management to ensure they are achieved. Like others have commented, a Scrum team don’t want or need that level of autocracy.
I have also worked in/alongside/with and for Agile teams as both a PO and a PM.
Managing a project or programme does not have to interfere with the Scrum/Agile process, but it does need to be there.
Otherwise the organisations objectives ‘might’ be met, but only by pure chance and not design.
DevOps is evolving, Agile is evolving and guess what, project and programme management is evolving alongside – what suits most of the people, most of the time will be what evolves into the polished framework. IMHO
Interesting that whenever we talk about Agile it is as applied to IT. Consider that most of the non IT assembly world is moving in an Agile direction. Most car makers are developing products as machine builders are developing the machines that build the product. Two intertwined projects developing at the same time.
Great post. The real change will happen when organisations contract with their suppliers based on the fixed capacity model. Too often individuals and their legal departments reverting to “was the spec signed off” “I never wanted that”. Our IT industry locally can benefit from procurement and sourcing playing their part.
Very interesting artcle and very engaging content that is shared, lots of room for debate.