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.