Can Agile Conquer the Physics of the Triple Constraint?
I recently saw a presentation from an advertising agency that claimed it would be able to do what no other company had: It had figured out how to deliver complex projects (in comparison to other digital advertising projects) inexpensively, on spec and faster than any other firm in the pitch. It was more of a tag line, so there was little by way of explanation behind the claim.
I held my tongue during the formal pitch, but made a point to ask the presenter a few questions after the meeting. Primarily, I wanted to know if he had heard of the triple constraint. The "iron triangle" as some refer to it, defines three pillars: cost, scope and time. It asserts that you have to prioritize the three with an understanding that trying to have all of them at the same time compromises quality.
Some assert that several additional factors come into play when discussing a project's success. I agree with this, but I disagree with removing the triple constraint model from training, as I believe it's such an easy concept to teach, understand and enforce.
My confidence in the triple constraint made it hard for me to believe that anyone had truly convinced themselves they could beat what is, essentially, physics. But sure enough, I got a very firm response from the organization: "We are able to deliver this service because we take an agile approach in our production processes, making us more efficient and thus able to deliver more value for the customer."
Confused, I pressed a little further.
"As I understand it, agile as a methodology does not allow you to overcome the basic physics outlined in the triple constraint. Agile simply prioritizes the tradeoff as one of scope rather than time or quality," I said.
Of course, it wasn't a discussion I was going to win in this setting. Looking around, I saw that the speaker's entire management team had bought into the theory and were smiling proudly at their triumph. I let it go. But it struck me how much confusion still seems to be out there around the triple constraint and the ability of newer methodologies such as agile to overcome it.
How many of you have had your management tell you to explore agile as a way to get your current project work done faster without sacrificing any of the three pillars? And how many of you still use the triple constraint to help you explain the basics physics around project execution?
The classic example was the shift from highly skilled craft based production to the mechanically assisted â€˜production lineâ€™ that fueled the growth of modern consumerism. More recently the automating of business processes using computers has again increased the efficiency of organisations, reduced processing costs, sped up production and reduced errors (ie, increased quality).
The key though is a paradigm shift in the production process (or part of the process). The question you should be asking is what have they changed to gain efficiencies without reducing quality?
One of the tenets of Agile is customer involvement, it their efficiency gain is created by you supplying a full time â€˜client representativeâ€™ to the project team there may be no overall saving, just a transfer of cost from them to you. Banks are doing this with on-line web accounts. You do the work bank staff used to do and the bank still charges you.
Another tenet of Agile is reusable modules. If they have a library of well designed and constructed modules ready to be used in different combinations, the efficiencies could be significant and generate significant efficiencies saving time and money. We have a lot to learn from LegoÂ®.
Your challenge is to find out where the savings are derived from.
I have experienced, Agile, XP, SCRUM, Waterfall, V Model as methods and I wholly agree with your statement.
I have found during Agile/XP scenarios projects or deliveries become time boxed and therefore generally resource/cost boxed as the companies do not have any more to plow into the delivery / it is not feasible to have too many coders / Tar machines all working on the same piece of the project at the same time.
So what gives in these scenarios - Quality / Scope. normally it is rushed / de-scoped so you end up not delivering the full functionality.
Agile is being trumpeted everywhere presently, and I agree it is a useful and effective tool if used correctly but is not likely to be the answer to everyone's prayers.
The thing is, as Nirav Patel said, we can't hit the 3 pillars, actually you chose 2 of them, and do your best to get the 3rd.
In Software Development, deal with Scope Contracts is a little bit boring and hard, once software isn't an entrepreneurship like make a building. The product changes as the customer see what have been constructed, and sometimes the customer have to change it but not to increase the schedule too much.
Anyways... In my experience, we have some projects that Agile Methodologies fit best than PMI practices, and others projects that PMI practices fit best than agile.
As you state, Agile is just a manner to prioritize scope in the framework of schedule and cost. It's the PM's job to get the discussion away from the title "Agile" and towards the fundementals.
It's also a good way to determine if the outside firm has true knowledge or just people that read a few books and re-bundled the wording.
(Being said, I'm a believe in Agile but only when applied to the right problem. It is just a tool for the PM; not a holy grail for all problems)
In an agile environment, we focus on delivering high-value pieces of the project - consider this scope, if you will. However, we go a little further than that, by delivering high-value pieces of high-value scope. Confused? Let me use a simple example - reporting.
Not all reports are created equal - some have a very high value to the customer, and some are "nice to have". With an agile approach, we would clearly deliver the high-value reports first. But what about the high-value aspects of these high-value reports?
Clearly, we need the budget numbers with sub-totals, but do we really need all of the formatting to be perfect before we show them to the customer? Similarly, do we really need every heading to be clickable, so we can sort by that heading? I argue we do not need everything "in the spec", but we can deliver high-value aspects of high-value functionality. This is how we re-define "scope."
Does this "fix" the iron triangle? Of course not, but it allows us - forces us - to ask the question "do you really need this functionality, or is there something more valuable we should work on once we have this 'good enough'?"
A change in efficiency will change cost and/or schedule WITHOUT changing scope. That's the definition of efficiency! In other words, you can change one side of the triangle without changing the other two. The whole premise of this article is that this is impossible.As soon as you realize that the triple constraint is NOT inviolate, this whole article just falls over.
What should have been evaluated is whether agile methods actually improve efficiency as claimed. This article asserts that such an evaluation isn't even necessary. The truth is quite the opposite - the triple constraint is NEVER a valid argument against the impact of a change in efficiency. It's like saying the only way to use less gas on that trip to Phoenix is to slow down - more fuel efficient cars must not exist because that would violate the triple constraint.
The triple constraint triangle is a useful tool, but it's a model, a simplification of reality. That's why there are so many variations of the triangle, because it does NOT fully represent every situation! And a change in efficiency is one of those situations.
The triple constraint is a great way to remind people that shortening schedules takes more than wishful thinking, but as soon as you start calling it "basic physics" you've over-applied and over-trusted the model.
"As I understand it...agile simply prioritizes the tradeoff as one of scope rather than time or quality." There's a heck of a lot more to it than that. There are also attempts at improving efficiency of communication, efficiency of quality assessment and attainment, efficiency of scope definition and change management, etc.
And contrary to popular opinion, that efficiency improvement is not achieved through leaving out certain activities, but primarily through re-ordering them. But the point is that it's all about improved efficiency, which will ALWAYS change the triple constraint triangle in ways the author of this article claims to be impossible.
Again, whether agile methods actually do what they claim is another story, but that's what the criticism should be based on. The triple constraint is irrelevant as an argument against claimed changes in efficiency.
Darryl, I wanted to take a second to comment on your post. You are absolutely right. There CAN be efficiencies found, and I don't want to suggest we should stop looking for those opportunities.
However, the main crux of my point is that clients â€”and management/sales â€” will all too often use "better efficiency" as a way to get around delivering a tough message during the sales cycle. Depending on the industry, there may indeed be a more "fuel efficient car" out there that will help deliver projects more quickly without affecting other elements in the triangle.
However, in 95 percent of the situations I have observed, this is not the case. Any time I observe account/sales/management saying they can overcome triple constraint with "more efficiency," they are typically in denial and trying to close a deal by agreeing to unrealistic expectations.
Now ALL development approaches need to be integrated (or encapsulated within) a project management approach - and I agree that "Agile driven" projects need some special handling in order to leverage the advantages they present. But I fail to understand why we keep attempting to treat Agile as something new and the solution to all our problems.
Cyclical iterative development approaches have been around for a long time; this is one that just happens to be particularly successful in its branding and general acceptance.
It still doesn't address (or provide) anything significantly new in terms of project management - and our original topic - the triple constraint.
Here's my part; the iron triangle isn't a rule; it's a heuristic. And in this case it's done it's job by getting Geoff to ask questions.
"Agile methods" isn't even that. It's just shorthand to refer to a large and complete, body of ideas. So the next step is to ask "how do agile methods help you?"
Get the specifics and assess them in the context.
Those of us that have seen good agile practices are fans, but that's not to say a mediocre agile team will beat a good "other" team. When the agency says they are agile, you need to find out what that means and inspect it in context.
Specifically, management (and other types of leverage like Consumer Off-the-Shelf or Cloud) beyond just the application of people serves as the project initiation document controller within a closed-loop, socio-technical system.
All of this has been recently distilled for you folks in the book "SDLC 3.0: Beyond a Tacit Understanding of Agile." When one learns about the sub-branch of the General Systems Theory that I highlight called Control Systems Engineering, it becomes very clear that the true universal that must be in place to yield an optimal delivery is negative feedback at the correct frequency, with adaptive structure and gain scheduling applied as the system's environment changes.
This was what the folks who articulated the Agile Manifesto and various Agile methods, albeit anecdotally and tacitly, where trying to say.
But no doubt that will be distorted.
|Scott Edward Davidson|
I enjoyed reading your article. I can say that I remember my first experiences with software and consulting firms that were overzealous in their approach to win clients and their business. In the mid-1990's, the hot trend was the "90 day complex software implementation GUARANTEED!" or delivering software that was "smoke & mirrors," meaning it does not work as advertised.
Today, it's much of the same. Firms are always eager to improve their project delivery success. Given Agile has been buzzing for a couple of years, and there are some documented successes, some firms are leveraging Agile in their marketing campaigns.
To answer your question, "Can Agile Conquer the Physics of the Triple Constraint?" my answer would be NO. If it were yes, then we as Project Managers would be out of a profession and Business Owners would have their analysts become Agile Experts instead as the triple constraint would be defeated.
The triple constraint will always be present with any project. In addition, the management of the triple constraint requires a special breed of professional leadership that by their very nature are willing to manage the successful delivery of a project so that it meets the needs of the business/client. This includes every PMP Certified Project Manager on the PMI website.
To answer your question another way, "Can Agile Reduce the RISK of the Triple Constraint?" my answer is a resounding YES. Some responses to your posting suggest that by following Agile you give in to one or more of the triple constraints. I couldn't disagree more as this has never been my experience.
To explain further, I'm sure you agree that a project manager must manage the scope of a project and its triple constraint. In addition, Agile delivers business prioritized functionality at the pace and dosage that the business is willing to accept it. This, in its purest nature, shows that if the business accepts the end product of what was delivered then we are successful in delivering to the scope while managing all three components of the triple constraint for that project. Otherwise, the Business Owner would not have approved the closing of the project.
Agile does have benefits and can be integrated into the landscape of any Project Department in a company. One benefit of Agile is that the business receives some software functionality earlier rather than waiting to receive 100 percent of the functionality at the end of the program. This enables the business to accomplish some advancements early.
It also insulates a business investment if the enterprise project portfolio is re-prioritized during the middle of a fiscal year. If a re-prioritization should occur due to favorable/unfavorable market conditions, chances are the company will still be able to recoup their investment in software development as they have a working product, albeit not 100 percent of the functionality of a program, instead of losing the full investment due to canceling or shelving a non-Agile based development project.
Hope this helps and thank you for reading!
Scott Edward Davidson, PMP
First, Agile is not limited to a tradeoff of scope or quality. Agile can be used in any tradeoff scenario. Agile can even be used on fixed bid projects.
Most folks believe that to be Agile, you must collaborate and prioritize with the customer. Agile does have several practices that focus on this area, but these are only a few of the Agile practices. You could totally avoid working with the customer and still use Agile practices such as collaborative team planning, test driven development, and continuous integration. The correct question is not "should we use Agile?" but rather "what level of Agile makes sense for this customer, this project, and this team?"
Second, I saw a comment about Agile as a new methodology. I guess we could say it is new, but I would prefer to say the new part is putting all of the practices together in one methodology. When I talk to folks a little older than myself they often tell me about Agile practices they used long before we used the "Agile" word. I look at Agile as an aggregation of best practices and principles versus some type of radical new approach.
To wrap up, some level of Agile can be used on almost any type of project, and Agile does not have to be viewed as yes or no.
However, there are ways to add capacity without adding resources. LEAN is the way to go. The underlying theme for improvement is:
1. Figure out the constraint in the process. There will only be one or two constraints that impacts project speed
2. Improve those constraints and you have added capacity, usually, without adding resources
That's how I would go about implementing agile without breaking the laws of physics :)
Please Login/Register to leave a comment.