Back in 2001, when the 17 developers gathered around and argued and discussed and came up with the "Agile Manifesto", there were a lot of things that they didn't agree upon and a few things that they did agree on. Certainly those 17 people, and those they have trained, can talk more in depth about Agile specifically than I can. Although I have taken "Product Owner" and "ScrumMaster" courses my own experience of Agile comes more from trying to ride herd on groups of developers (and managers) trying to make the transition from waterfall to Agile (SCRUM, as the specific variant goal). And some of their discussion and points are rooted in some of the things that I was exposed to starting 25 years before their gathering.
Be aware that, although the Agile Manifesto was done in conjunction with software engineering, it can apply to any project -- including home remodeling or building that paper maché model for high school or putting together an anniversary party.
One of the things that they used in discussion at, and I tried to learn from prior to their gathering, was the experiences of "The Mythical Man Month". Although the technologies used within may be considered prehistoric by many, the approaches and mistakes have certainly continued to the present day with Agile approaches attempting to divert people, and projects, away from such catastrophic results. Within this project, as relayed in the book, there was a mad, accelerating, scramble to try to bring a project back onto a schedule with proper quality and without bankrupting the company.
There are three major aspects of projects -- resources, time, and quality. Resources can include the number of people, the amount of equipment, square footage, shoot -- basically anything that has a limitation but can be expanded (resources can extend to mental/specific expertise availability and limitations). Time is rather straight-forward (thought the general topic has been thrashed out for centuries by philosophers and scientists). Quality is a slippery object but it is usually defined at the end by agreeing whether it came out as useful as desired. (Defining acceptance criteria will almost always help to determine whether the quality goals have been met.) Although (as far as I know) they never called these aspects the "three lodgepoles", I think that it is a good description.
Lodgepoles are really just long, straight, sturdy poles. However, if three or more are bound together, they can form a sturdy structure for support of other things (potentially a habitation as was done with the First Nations of the Americas). They can be used to support a kettle over a campfire to cook a soup in. Three will succeed. Two, or one, will not be able to be sufficiently sturdy to hold that kettle or structure.
So it is with "the three lodgepoles of Agile". You have these three aspects that provide the support for a project -- but you can only try to control two of them. If you try to control time and quality then you cannot control resources (the primary discovery within the Mythical Man Month). If you try to control quality and resources, then time is unknown (this happens with projects that never arrive at their goal). Or, if you try to control time and resources then achieving desired quality may be an illusion (note that most of the time what happens is, as the illusion of quality fades away then the time and/or resource restrictions start being revisited and expanded).
When moving over to an Agile structure, this limitation is very difficult for management to understand -- and overly frustrating to other workers who are doing their very best to satisfy.
Take a "typical" project. You decide what you want to do, how many people are available (or you can afford) to do it, and say when you want to have it done. OK, the date arrives and it isn't the way you wanted it to be -- quality has given way. Or you are continuing to work on the project and keep saying "it will be ready in just another two weeks ..." (over and over) -- time has given way. Or the quality isn't where you want it to be and that anniversary date is coming up fast (difficult to change an anniversary date), and you start calling everyone you know to see if they can help -- resources have gone out of control.
In our conversion process towards Agile, that "time" component kept being a problem. In part, this was because the marketing and sales division was NOT moving towards "Agile" (for marketing and sales, there really needs to be some type of ongoing delivery system with steadily moving different dates with features -- such as a subscription model for software). So, huge amounts of resources kept being used to keep track of "time" -- although everyone participating knew that they couldn't really control all three lodgepoles. Delivery dates, software completion dates, etc. And that brings us back to that Mythical Man Month -- resources were allocated to doing what couldn't really be done -- which leads us back to the frustrations of the 17 people at the Agile meeting.
Life is interesting.
