Implementing Agile Values and Principles: Chapter 1 (3rd post)

A few years ago I wrote Understanding Agile Values and Principles (https://www.infoq.com/minibooks/agile-values-principles/). I’m working on a follow-up book about implementing them entitled Implementing Agile Values and Principles. I will post draft parts of the book on Medium.com as I finish them. I would certainly be interested in hearing people’s opinions about the draft material which I will certainly consider in making revisions as I work toward the final version.

This fourth post is the draft of more parts of the first chapter.

Faster, Cheaper, Better

People often assume Agile adoption should be expected to produce results faster, cheaper, and better. Of course, every new approach says it will and is expected to do this. However, if you look at standard definitions of the words “Agile” or “agility,” the term “faster” is not mentioned. But neither are words like “balance” and “stability,” though some may feel they are implied.

You might view the ability of mountain goats to traverse nearly vertical mountain sides or the balance beam gymnast’s ability to perform as good examples of agility. However, if the mountain goat kept slipping off the rocks or the gymnast kept missing moves or falling off the beam, you would likely not view either one as demonstrating agility. An important aspect of achieving agility, therefore, is the ability to maintain balance and stability while moving quickly.

This applies to individuals and teams working in an Agile fashion. An important aspect of their work is to be able to maintain balance as well as moving quickly. This is done by frequently assessing the stability of the work being produced. That is, being able to frequently assess how well the work meets expectations, both technical and from a customer satisfaction perspective, i.e., the quality of what is done.

Joshua Kerievsky, in discussing agility, has pointed to former UCLA basketball coach John Wooden who applied ways of training players to produce agile athletes. Wooden said to be quick, but not hurry. Wooden believed, “There’s a real line between hurrying and rushing and being quick.” If you hurry or rush, you make mistakes or are prone to making mistakes. Quickness is a result of skill, practice, and not hesitating. He also felt “You cannot be quick if you don’t have balance.” Being balanced and graceful go together.

As Tom DeMarco has said, “The companies I have come to admire most show little obvious sense of hurry.”

Sooner

I prefer to think of Agile delivery’s goal being “sooner” rather than necessarily faster. If you have a year’s worth of work to do, an Agile approach is not going to magically deliver the work in, say, 10 months. However, delivery of incremental parts of the whole will occur sooner affording early and regular opportunities for feedback from the customer. This can even allow the customer to make actual use of such sooner deliveries before all such incremental deliveries are completed.

Look at the situation in terms of when you get something of value that, at least, could be shown to stakeholders even if not put into production. In a traditional phased-sequential (i.e., waterfall) approach, you may wait until almost the end of the project before you even see, let alone can use, anything of value. In an Agile approach, you should get some amount of observable value at the end of every iteration, so “sooner” than traditional delivery would occur.

It is left up to stakeholders to decide how many such incremental deliveries of value are enough to put the accumulated results into production. Though they have value sooner, everything they want is not there, but, potentially, enough high value might exist to make it worth putting into production. The goal would be that, when possible, each iteration would offer something of value could be put into production.

All of this, of course, is a business decision which is not controlled by waiting for everything before anything could be used. Value is achieved “sooner” and delivered in highest-priority order. This is a significant change in how a business might currently view planning and structuring new work in releases many months in the future. The Agile way challenges them to think of shorter releases in high-priority order.

Cheaper

Regarding an Agile approach being cheaper, that can occur if practices help avoid wasteful rework either because of pure operational errors or misunderstandings surrounding requirements. Alistair has pointed out that an Agile approach might be “more expensive than a super cost-optimized version running under stable circumstances” Of course, he has noted that in many cases that kind of stability isn’t present. However, life-critical systems will put significant importance on stability and strive to create such circumstances and not allow requirements changes at the last moment.”

While it does not eliminate the desire for changes, the frequent, iterative opportunities for feedback should surface such requests sooner than a traditional development approach since stakeholders see working results early in the release cycle as opposed to waiting until near the end. Change should cost less and be less risky given frequent opportunities to surface such needs.

Alistair has further pointed out that “These days, there aren’t a lot of places that have stable circumstances.” Where a project’s safety and success factors are of prime importance, people will strive to create that stability, however, even when it does not naturally exist.

Alistair also had his own “framework” ideas at the time the Manifesto was created which he called “Crystal Methods.” The diagram illustrates the structure and relationships of these methods. He did not go into detail about these (except the “clear” approach), but it is the relationship structure that matters here. Alistair said that one could envision a matrix of “methods” based on the possibility of loss (from comfortably small to life critical) and the number of people involved in the development effort. As one climbed the loss axis, increasing levels of verification and validation formality would be required. As size grew along the other axis, increasing levels of communication formality would be required. To me this suggested early on that it was not just an Agile versus waterfall dichotomy but that there were many possible approaches that could exist, tailored to the specific intersection of loss and size.

Alistair has also said that:

• Frequency of communication and coordination can make an Agile approach more complex. [Although perhaps a conventional organization might find it so because they still try to operate with the many levels of approvals and authority in their existing way of working. Pushing decision-making down might make such communication and coordination easier and smoother.]
• Greater expectations for skilled team members can make an Agile approach more expensive. [Personally, the “skills” an Agile team member needs seem to me to come from handling interpersonal relationships better. Though there are technical practices people would possibly need to become more proficient at and willing to try.]
• Smaller increments of development can make an Agile approach take longer. [I’ve seen this happen because the incremental delivery opens more frequent opportunities for change as that is something an Agile approach wants to offer customers. If the customer wants all the changes as well as everything else with no scope flexibility, that will add time to the work before everything gets done. Unfortunately, customers (especially internal ones) may want it all within the deadline and the existing budget. This typically produces dysfunctional approaches to achieving that.]

Also, adopting an Agile approach needs to allow for time so teams can develop experience with the new practices. Some companies feel that sending people to framework training prepares them to “hit the ground running.” Or they may feel sending a few people to certification classes means they can then “train” everyone else, eliminating the time and cost of everyone else getting the training.

A traditional approach may be better when:

· requirements are clear and no substantive change is expected throughout the work effort,

· the budget is fixed based on expectations for requirements and limited change and there is no flexibility for changes,

· there are time constraints with no flexibility in increasing deadlines, and

· there is limited complexity in the work as it is well understood what needs to be done and the technologies needed to do it.

Of course, as Alistair noted, this is not the common situation these days. Organizations may want to plan and operate this way, realizing the costs (in time and money) if they cannot. The Standish Group has noted for years in their surveys of project successes and challenges that most traditional projects miss the schedule, or the budget, or some aspects of requirements due to changes that occur and misestimations that were made at the outset because of the unexpected changes. A traditional project may be able to meet the constraints noted above, but very often that can result in some form of dissatisfaction with the results due to requirements misunderstandings discovered too late and work pushed through without totally adequate verification of the quality.

Indeed, under pressure to hit a deadline and get everything done, either forced overtime is required or corners cut, both of which can negatively impact quality. Long periods of overtime will wear people out, resulting in things being missed and even losing people during the planned work schedule. Practices intended to improve quality may be reduced, or even skipped, to save the time they world take (e.g., peer reviews, unit testing) hoping QA department testing will “catch things.” Of course, those departments may find that their expected time to do adequate testing has to be reduced to make the schedule. (Later in the book, I’ll comment on my view of the appropriate way to envision QA and the role of such analysts/testers on Agile teams.)

Better

Finally, there is the subject of an Agile approach producing a better result. I absolutely believe this should be true, as noted above, both in terms of pure technical quality as well as satisfaction of customer value expectations. So many actual practices, and Agile principles, seek to help teams and organizations achieve that (to mention a few):

· Frequency and directness of communication between customer(s) and development organizations is an important way to avoid divergence in understanding of requirements expectations.

· Use of incremental development to get frequent feedback from the work itself, letting everyone know appropriate quality expectations are being met.

· Technical practices that encourage communication and clarity in understanding about the quality of the work, e.g., continuous integration and testing, design standards, and for collaborative work such as pairing and mobbing.

An Agile approach should produce more satisfactory results because the adoption of such ideas can result in:

· defects being discovered earlier, delivering a system more “fit for use” (to use a classic definition of quality);

· delivered functionality more clearly meeting stakeholder needs at the time of that delivery as well as being more satisfying as a user experience; and,

· future desires for enhancements being delivered sooner, less expensively, and with high quality because the existing work has greater intrinsic design integrity making change easier and more reliable.

There should be no doubt that a focus on quality results needs to be a primary consideration working in an Agile fashion. I’ll have a lot more to say about all of this as I go through each value and principle in upcoming chapters.