Getting it done: The three lodgepoles of Agile

 

     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.

Being Agile: In software and life

     In February of 2001, seventeen people met to talk, have fun, and find common ground. They were concerned with the reality that there was so much software being produced that was of low-quality, overly-complicated, and overworking people to a degree that was not reasonable. Out of that gathering, they released a document called "The Agile Manifesto". The four core values are usually summarized as:

• individuals and interactions over processes and tools;
• working software over comprehensive documentation;
• customer collaboration over contract negotiation; and.
• responding to change over following a plan.

     There are a number of books that go into depth about various aspects of this philosophy. I am just going to delve into a couple of the primary differences and obstacles when moving from a "waterfall" process (one thing follows another in a given order and rhythm).

     If a person, or group of people, is working on something that has been built (or something very similar) hundreds, or thousands, of time (think of a factory line or processing a standard form) then it is fairly simple to know what is needed, when, and how long it will take. Most software projects are new -- it has never been accomplished before. There is no complete knowledge of what is needed or how it should be designed. There is no knowledge of how many people will take how long to complete it at a reasonable quality level.

     Traditional methodologies say "OK. We don't know. Guess. But we will hold you to that guess and you will build what we have initially agreed to build. When something goes wrong, expect 70-hour work weeks and it will be released even if it doesn't work." One major software company was famous (infamous?) for releasing software with major problems -- using sales from the first release to work on fixing those bugs in future releases. (In general, the software eventually became very usable.)

     Most people would agree that documentation is useful. There is external documentation -- how to use the software or how other software modules should interact with the software (called an Application Programming Interface -- API). There is internal documentation -- how is it programmed and how the code works. Both are useful and both are reasonable.

     Since there is no way to know what the final product will be, documentation should be done in phases. A skeleton -- sparse but sufficient information to start with -- should happen at the first. Having a fully "complete" document at the beginning is a waste of effort and may be counter-productive leading to an inferior and non-competitive product.

     The API should be as clear as currently known -- and changes sent out to all people/groups that need to know as they occur. How to use (the User Interface (UI)) should follow the same process, initially as it is and notifying the testing and product marketing people whenever it changes. The design and features may need to be modified according to current market conditions or feedback from potential customers. Internal documentation should start off general and become more and more specific as the process continues with the final documentation reflecting the real state of the software.

     One situation in which the Agile methodology is frequently crippled is when the marketing/sales area does not follow along in the methodology. If marketing/sales continues to have releases at predetermined times with feature sets advertised well in advance of those dates, much of the Agile methodology with the developers will not be achievable.

     Huge amounts of overhead will be created. This overhead is involved with keeping track of delivery dates and the current state of features. This is contradictory to the original design, and purpose, of the Agile methodology which understands that dates of "completion" of features/products, of acceptable quality, cannot be predetermined. Dates will be missed and/or quality will suffer.

     The movement towards "subscription" software (which is often associated with "Continuous Delivery") could ease this desire to hang onto fixed releases dates and contents since subscribers will always get the best currently available as it is released. Alas, even with subscriptions, marketing/sales needs to reorient the way they present the product.

     So, how does this apply to life? In most of the technological nations, life is ruled by the clock. There are deadlines. The trains run on time (or try to). Schedules determine the work day. Reservations are made. We make plans that may be very detailed.

     But problems occur. Things don't go "as planned". There is extra stress to the point of not being healthy. Flexibility and the ability to go with the moment are methods that can be of great help within our world -- even to the point of changing society to be less clock-oriented. Being agile helps.