Implementing Agile Values and Principles: Chapter 3 (1st 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 first post is the draft of the first part of the 3rd chapter on Working Software.

Chapter 3: Working Software

The Manifesto says “software” in several places. I believe the Manifesto’s values and principles can be applied to any product delivered to the customer. This could be software, hardware, or services where the latter could include various support functions, educational/training programs, or HR/sales/marketing work. Therefore, this chapter, and really all the book, will consider the product delivered regardless of what that might be.

This chapter is going to address two main topics:

· What does “working” mean?

· If not “comprehensive” documentation, then what?

There will be more said about the latter than the former. There is not as much controversy over what “working” means compared to opinions about sufficiency of documentation.

Chapter 7 will include discussion of how we determine the value of what is delivered. I could have addressed it here as an aspect of what it means to “work,” but, under satisfying the customer, “valuable” is mentioned. It seems reasonable to discuss value there.

What Does It Mean to “Work”

In UAVP, I asked, “What does it mean that it works?” A team should feel their work meets all customer expectations and is, in principle, production ready. While this includes technical quality considerations (i.e., it is defect-free), there are many things that could be “expected.” This includes all necessary user documentation since, without it, the result may still not be usable.

On the other hand, as mentioned in UAVP, a customer might be willing to make use of what they believe is a useful subset of everything, preferring to get something useful sooner rather than everything later. This is an essential aspect of the Agile incremental delivery approach. Doing so, however, means having clear criteria for what constitutes the value to be delivered. One aspect of “working” is that, for whatever increment of value may be delivered, the acceptance criteria (i.e., Conditions of Satisfaction) are met. Defining these criteria clearly helps both customer and development team share a common understanding of that “working” then means. This makes it easier to meet the expectations the customer has for the usefulness of what is delivered.

From the perspective of a classic definition of quality, what is delivered should be “fit for use” according to Joseph Juran one of the recognized quality leaders from almost 60 years ago. For him, “fitness for use” included, beyond working “well” (the defect freeness), consideration of the cost, strength of post-delivery support, and the effectiveness of the actual delivery process. Clearly, these go beyond what the typical development team likely considers in their definition of “working.”

In this book, I’ll stick to what individuals and teams can do to address Juran’s working “well” element of fitness. However, for the larger organization, Juran’s other points should be addressed since they affect the overall experience a customer has which contributes to their likelihood of returning for future value delivery.

Communicating with the Delivery

In UAVP, I asked about effectively understanding what is delivered or planned to be delivered. I called this “communicating” with that delivery. I said that that people could do this by using the content of that delivery in some way and observing how the content responds to such use.

Development teams do this when they verify and validate the content in various ways. For some things, this can be done through forms of direct testing, recording what happens when that is done. Various forms of peer review are another way to do this. Sometimes this is the most reasonable way for content that is not software or some physical product. A further way, involving the customer, are the regular reviews held where feedback is collected.

Customers, or their representatives, can see how something works by using it as they would in actual production situations. In this way they “talk” to that delivery subset and their experience in interacting with it is how it “talks” back. By directly using the delivery they will uncover defects as well as surface functionality changes before they become too difficult or expensive to address.

To make doing this easier for both the team and customer, the Agile approach recommends frequent delivery of small increments. I observed a team that worked very hard to break functionality down into pieces that could be completed in just a few days rather than take a few weeks to get all of it done. This increased collaboration between team members making collaboration easier and allowed for more frequent feedback opportunities within the team. It also resulted in the team spending little time estimating the work. Everything was such a small increment that they estimated everything as 2 points (using the Fibonacci story point scale). They spent their time breaking stories down which they felt was more valuable in being able to develop, test, and deliver frequently, effectively eliminating estimation time and effort.

Definition of Done

Perhaps most helpful in deciding when something is working is to have agreed upon, clear definition of what it means to be “done.” The Definition of Done, along with team working agreements, should be determined before starting any work. Such a definition should eliminate debates over whether a piece of work is done or not. The elements of this definition should apply to almost all the work the team does. For some work, additional elements might be needed. But the basic elements should apply to any type of work.

For example, a general definition could include the following:

· Design (at needed levels) has been done.

· Implementation of the work has been completed.

· Necessary documentation (internal and customer) has been completed.

· All work has been verified and validated (through forms of testing and peer review).

· Acceptance by the team’s product/customer representative has occurred.

For the first three of these, close collaborative effort between two or more team members to do the work can be the “review” approach. The eXtreme Programming idea of close sharing of work allows for peer review to be an integral part of doing the work. While this should reduce the need for many formally scheduled team-level reviews it does not mean that some broader review(s) might not be considered appropriate. For example, in certain cases some specialist might be used to cover an area not regularly a part of the team’s focus or skills. This could include topics such as those related to performance and safety, compliance considerations, or editorial/instructional review.

The goal is to use such “done” criteria to move the work forward effectively and reliably. It also encourages truly cross-functional teams rather than passing work through individually siloed teams slowing down the ability to deliver frequently.