Let us talk about agile, and Agile, in the project management world. This is a series of short videos about Debunking the myths about Agile Project Management. At this time, we have ten videos, and we will add them to this post, as we go live with them.
Let us talk about agile
In this first video, in the series on debunking Agile Project Management, we discuss why we are launching this series. Keep in mind, Agile Project Management is a myth.
In the summer of 2017, my publisher and I were deciding on the title for my latest book on CAMMP™. We chose a bold title to reflect the need to go beyond the annoying, frustrating, one-sided debates on agile and waterfall. However, a year later, today, the situation is worst. The online platforms, like LinkedIn, are cluttered with questionable posts on Agile and Waterfall.
Why do we say one-sided & questionable?
Because all of them are to promote Agile and often by people who do not know what Agile or Waterfall mean. We hear things like “Agile is eating the world”, “the Agile Revolution”, “trust me, let’s go Agile”, and even the silly “have an agile day” from a person who promotes emotional intelligence and agile. Some of these people even call themselves Agilists, making this thing as a religion.
Therefore, we decided to do this short-video series, 1 to 4 min, on the subject. To keep things short, these videos will build on each other, and each will clarify one point.
Click on the picture for the video.
We would love to hear your feedback on this whole series.
What is a project?
In this second video, we start by discussing what is a project since the definition of a project is essential to understanding why Agile Project Management is a myth.
Maybe some will think it is silly to start with defining what is a project, don’t we all know?
We think the core challenge that we face in the project management community today is that we think we know what a project is.
Then, what is a project?
Well, it depends on who you are and where you sit. Are you a project owner or are you a service provider? In other words, are you working on a project end-to-end or only a phase of the project?
Since projects are done to satisfy a business need, we would look at a project and any change initiative in organizations, an investment, to deliver the capabilities to realize a beneficial outcome. It is anything we create from scratch or a major change to an existing system. I could expand but this is enough.
Therefore, a project is started in response to a business need and to deliver the capabilities to realize benefits!
What is a project management method?
Once we define what is a project, it would be necessary to define what is a project management method. Again, this is critical to understand why agile IS NOT a project management methodology.
We do not want to get into a discussion on what is a method versus a methodology, so for today, use interchangeably.
A project management method should be a method to help us manage a project. Per our definition in the earlier video, then the “management” should be to manage the work from C2C; Concept to Closure. That means projects must follow a project life cycle that is subdivided into phases, stages, or both; let us use stages here. Every stage must deliver an output that we need to use in the subsequent stage. However, at the end of every stage, we must have a stage gate, to verify completion of the prior work, before deciding whether to continue or not.
In closing, projects should be managed end-to-end, using a PLC method, with stages, deliverables, and stage gates.
What is a project life cycle and how does it relate to a DLC?
We established in the previous video that a project management method must follow a project life cycle approach, end to end, concept to closure. Consequently, what are the PLC and DLC and how do they relate to each other? Why is this relevant to agile?
PLC’s or project life cycles vary from one industry to another. Ideally, a project should have a concept stage; a feasibility stage, requirements stage, SOMETHING IN THE MIDDLE, and a close stage.
That SOMETHING IN THE MIDDLE could be to produce the output:
- In one piece; following this sequence: plan — design — build — handover (or something like it). This is what some call waterfall and would be for the whole product scope and deliver one product, the whole thing, at the end!
- Incrementally: one can follow the same sequence but for small increments and deliver the product in pieces; if the pieces are of value on their own. Iterative would follow a similar sequence but for each iteration.
That something in the middle is, what some call development work, implementation, etc. Some also refer to it as the Development Life Cycle.
In closing, we can see that the DLC is part of the PLC; a subset. In other words, the DLC is NOT for the whole project; it is for a phase of the project!
Listen to the next video.
What is agile?
In this next video, we talk about agile with a lower case “a”.
What is agile? The emphasis here: agile with a small a.
The dictionary defines agile as the ability to move quickly, being nimble. In the business world, some view agile as: Not rigid or set in stones; flexible; dynamic; and adaptive to change.
Agile, with a small “a”, as a concept, can and should be used in all aspects of work, personal or business. Even at the strategic planning level, we talk about deliberate strategy versus emergent strategy, which can be a form of agile. Consequently, agile, with a small “a” is good and applicable in various scenarios.
What is Agile?
In this video, we talk about Agile with a capital “A”. What is it and how is related to the Manifesto of Agile Software Development? Once again, click on the picture for the video.
What is Agile? The emphasis here: agile with a capital A.
To use the buzzwords, Agile is a “mindset”. Most of what we see and read today relate to Agile as in the Manifesto for Agile Software Development.
There are four values and 12 principles. We do not want to go into the details, you can find them online. What is the core message of Agile, per the Manifesto? Early and continuous delivery; in small increments; 2 to 8 weeks; face-to-face interactions; adaptive to change; etc.
- To our knowledge, nowhere in the manifesto, they mention Agile to be a methodology,
- The manifesto is specific to software development, and
- I am sure, the approach can be used outside of software; later video.
How do we compare agile with Agile?
Now that we have defined a project and a PM method, we know what is a PLC and DLC, it is time to compare agile with Agile.
It is time to build on the previous videos and we can conclude with the following:
Agile with a capital A
- is NOT a project management method,
- is not even a development method,
- Agile values and principles can be applied to projects, but only on a phase of the project, not to manage the whole project life cycle,
- Remember the Manifesto, it is for Software development
- Can we use it outside of software, possible (next video)
Agile with a small a
Being agile (away from the manifesto), as in being nimble, flexible, adaptive, is and can be used on anything in life, including projects; BUT —- BUT not as a project management methodology.
Can we use agile/Agile outside of software development?
Now that we know what agile and Agile are, can we use either one outside of software development?
What have we established so far?
- We already established that agile (small a) can be used anywhere but not as a project management method.
- We also established that Agile (capital a) is NOT a project management method but Agile Values and Principles can be used on the development stage of a project, using concepts like incremental and iterative.
Can we use Agile (with a capital A) outside of software?
Yes, why not?
If there are situations that can benefit from partial releases, or releasing the products in chunks then of course. However, two key warnings here:
- The first is that the “chunks” do indeed add value to the customer (more on this in another video).
- Again and again, we must stress, we can use these concepts to develop a product; not as a management approach to managing the whole project, C2C.
In closing, I am working on a few similar (non-software) projects now,
- On the first project, I am using sequential approach (one release),
- For another project, I am using partial incremental approach, and
- Finally, the 3rd project will follow a full incremental approach.
I will report on the findings of these project in the future.
Is Agile “fake news”, a myth, or a hype?
It is time to take off the gloves and be direct and blunt. No political correctness here!
We cannot close this series without talking about Waterfall.
Notice, that in all of these videos I did not refer to waterfall because to me it is not relevant. The whole world of project management is not either/or. This is why my latest book title was project management BEYOND Waterfall and Agile.
My story about climbing with knives.
The problem today, in the project management community is like my story. Agilists cannot offer good arguments or case studies to back up their claims on why we should trust them and move to Agile or how is Agile is truly eating the world; so to promote Agile they often use one of the following tactics:
- They steal good practices; good, “traditional”, mature project management practices and claim it as Agile practices. So if it is good, it must be Agile; never mind if it is a stolen concept.
- Every failure or bad thing, it must be Waterfall. In other words, not accepting the responsibility that people and organizations are failing in applying good project management.
- In other words, is failure and success due to the approach or the people? Remember PM is about people, process, and tools!
Can we use agile/Agile in capital, or construction projects?
Building on the previous video, Agilists also claim that Agile works everywhere, including in construction and capital projects. The irony is that some of those people probably have never been on a construction site or know what a resource loaded schedule is. They back up their claims saying “we build the project piece by piece.” We say: What a piece of crap, ignorance and dangerous incompetence.
Remember Agile concepts follow this cycle, analysis – design – coding – testing – release …. The key here is release to the customer value added increments that can be put to use. How can we do that in construction and capital projects?
Let us use an example of building a house; the simplest form of a capital project; and C2C.
- Are we going to do the architectural design, engineering, procurement, and construction for each piece of the house at a time? One room at a time? One bathroom at a time?
Then they say but it works in construction and here is a PMI paper to prove it.
- Do these people realize that by the time we reach the construction stage, many stages would have been completed? In other words, construction is only a stage in the House Project Life Cycle!
- However, I will humor them and let us stick to construction of a house. How would Agile work; the incremental release? Let us say we built the foundation, can we release it to the customer? If someone says yes, what would the customer do with it? Go sit on the foundation or piles?
- Same with the slab, columns, beams, roof, and other elements. We cannot complete or release in pieces.
I am sure you got the point and no need for further elaboration.
I must close by telling the Agilists your incompetence is dangerous and you have lost credibility! Learn agile well, know its powers and limitations then come teach us! Until then, I hope you can find a table to go hide under it!
Bottom line; agile, as in being flexible, dynamic, responsive, adaptive is a good mindset and can be used in most scenarios, projects and general business. However, Agile, as in the Manifesto, is limited in use to certain situations like software development and similar projects, BUT only within a phase and not a management approach!