PM Blog: Alan S. Koch

Customer Focus

2008-04-29T13:48:26-07:00

The Essence of Agility
What makes a project "Agile"?
Part 2 of 4

by Alan S. Koch, PMP

Is the team "Agile," as they claim, or are they using that term as a cloak for a lack of discipline? One way to know is to observe what drives their activity: do they do what is cool, or do they do what the customer values? In this article, we will continue to explore the types of discipline that are the essence of being Agile. This time, we will focus on how the team relates to their customer.

Agility and Discipline

In my last column, I discussed the importance of discipline to Agility. Kent Beck, co-author of Extreme Programming Explained, put it well in his foreword to my book: "Agility in software requires iron discipline." (If you did not see that installment, you may want to read it before you continue with this one.)

Differentiating true Agility from undisciplined behavior is a matter of observing the team to see if they exhibit the behaviors that are essential to Agility:

Learning and adaptation
Collaboration
Customer focus
Small self-directed teams
Lean principles
Progressive requirements elaboration
Incremental delivery
Iterative planning and adaptation

In this second article of a four-part series, we will discuss the third of those behaviors, Customer focus. As we discuss this, it will be useful to refer to the Agile Lifecycle.

Customer Focus

It is all about our customer. All! An Agile team will do everything in their power to maintain continuous (or at least regular) contact with their customer, because that contact is essential to their ability to produce what the customer needs. An Agile team doesn't trust a Requirements Specification to tell the whole story. They know that if such a document was written, it contains errors, interpretations, and key omissions. They also know that even if it accurately represents what the customer thought they needed when they signed off, things are likely to change before the product is complete.

In order to ensure that they deliver what the customer really needs (and needs today), the team includes the customer in team activities as often as possible. The customer's input is important in each phase of the Agile lifecycle (as pictured above).

Initiate Project – Of course the customer's participation is needed during this phase. But the Agile team will also be involved with them. It is not enough for the Customer to say, "This is what I want, and that is when I need it." Of equal importance is the team's understanding of why each feature is important to the customer, and the customer's understanding of which parts of the project are difficult, time-consuming or technically risky.

Ultimately, defining a project that will best meet the customer's needs requires collaborative planning, with critical input from both the developers and their customer.

Plan Iteration &ndash Although planning the details of the work the team will do in a short iteration is their own job to do (see Small Self-Directed Teams, in the next installment of this series), the team needs critical input from their customer to do it well. What is the goal we are trying to achieve in this iteration? Which features and functions are tied to that goal? And what are their relative priorities? The team's customer must play a central role in these parts of the plan.

But even more important is that the detailed Iteration planning may reveal that the team will be unable to do as much as had originally been thought. The customer must be part of the discussion about how to adjust the scope of the iteration to make it an aggressive, yet achievable plan that will bring real value to the customer.

Develop Product Increment – The customer's role during development cannot be over-emphasized. Regardless of how well requirements have been defined and in what form they have been documented (we will discuss Requirements in Part 4 of this series), the team will have many questions as they actually do the work. Instead of guessing about the best way to implement each feature, an Agile team asks lots of questions of their customer. "If I do it this way, it will have this impact on the end user; but that way will result in such-and-such a limitation. Which way should I do it?" "What precisely were you expecting when you said that you need the system to do this?" "Take a look at this. Will it do what you need?"

An Agile team will not just forge ahead; they will seek feedback from their customer whenever they have a question. Obviously, if their customer is not available to interact with them in this way, the team's ability to be Agile will be hampered. But that will not keep them from asking!

Review Iteration – The point behind the Iteration Review is to get the customer's feedback on what was built during the iteration—either acceptance or specific guidance on what needs to change. This feedback is central to the Agile approach; it is why the product is built incrementally.

After each step in the project, the team will demonstrate what was just built to their customer and actively seek the customer's feedback. If their customer is willing and able to do full Acceptance Testing, that is even better! And putting the product into production is best, because this will result in the richest and most important feedback the team could get!

The more feedback the team members can get from their customer during development (as just discussed in the prior point), the fewer surprises there will be in the Iteration Review. Nevertheless, even with excellent access to their customer during development, the Iteration Review establishes an important milestone that the Agile team cannot continue without.

Adapt to Change – In the first part of this series, I discussed the importance of learning and adaptation to an Agile team. This phase of the Agile lifecycle is when much of the adaptation takes place. Based on all that has been learned as we went through the iterations so far, what should change about the project?

Because the project is all about the customer, these deliberations cannot take place without the customer's participation. The team can articulate the impacts of any changes (cost of that new requirement, impact of a risk realized, expense of changing an already-implemented feature). But only the customer can decide how the project's progression and deliverables should be adjusted to account for all of this.

An Agile team will not simply soldier forward in the face of unachievable expectations. Neither will they make these key decisions themselves. They will present the facts of the project to their customer (and management and any other stakeholders who must be involved), and look to them to make the hard decisions.

Becoming More Agile

We will discuss the last five behaviors of the Essence of Agility (small self-directed teams, lean principles, progressive requirements elaboration, incremental delivery, and iterative planning and adaptation) in parts three and four of this series. But becoming truly Agile can begin today.

We can involve our customer in the workings of the project regularly and continuously. We can articulate the costs, limitations and risks in the project, but leave it to our customer to decide the best use of the project's limited resources. And we can get feedback from our customer as often as we possibly can.

To make this happen, we must engage our customer to a degree that they have probably not been engaged in our projects before. This is a significant time commitment on their part, so we must make it clear that they (and not the project team) are the main beneficiaries of any additional investment of their own time in the project. This investment is insurance that the project will delivery the highest possible business value to them in the face of constraints, changes and all of the surprises that will come up.

This will help us to become a bit more agile. But these behaviors will be difficult to achieve without the other parts of the Essence of Agility. So stay tuned!

What makes a project "Agile"?

2008-04-10T09:27:58-07:00

The Essence of Agility
Part 1 of 4
Learning and Adaptation & Collaboration

by Alan S. Koch, PMP

The Agile approach is often panned as an excuse for lack of discipline. I've been told that Agility means, "We'll just wing it, and when we run out of money, we'll ask for more." This and other such statements show that many people don't understand what Agility is all about.

The confusion is understandable because there is a plethora of practices that people claim as "Agile." And unfortunately, some of them are indeed using the term "Agile" as an excuse for lack of discipline.

The Essence of Agility is a set of observable behaviors and actions. We can determine if a project is agile or merely claiming to be by looking for these behaviors and evaluating how effectively they support the Agile Values and Principles.

Agility and Discipline

Agility is valued by any organization. It connotes the ability to withstand whatever comes our way while maintaining balance and momentum. In software development, this translates into maintaining project performance and progress in the face of changing customer needs, business priorities, technology, and organizational dynamics.

Calling undisciplined behavior agile is a misuse of the term. As Kent Beck (co-author of Extreme Programming Explained) wrote in his foreword to my book: "Agility in software requires iron discipline." So how are we to differentiate true Agility from undisciplined behavior?

The Agile methods, as designed by their creators and implemented on disciplined teams, use a variety of tactics to build a project environment that is indeed agile. There is no one set of practices that is definitively Agile. In fact, there are a dozen different methods that are included under the banner of Agile, and each of them includes some unique practices.

True Agility is based on a few distinct principles that are underpinned by a unique value system. (Refer to the Agile Manifesto at www.agilemanifesto.org.) The application of these values and principles results in a few indispensable behaviors that can be seen and judged objectively by any interested stakeholder of a project. It is those behaviors that I refer to as the Essence of Agility:

Learning and adaptation
Collaboration
Customer focus
Small self-directed teams
Lean principles
Progressive requirements elaboration
Incremental delivery
Iterative planning and adaptation

In this first article of a three-part series, we will discuss the first two of those behaviors. As we discuss them, it will be useful to refer to the Agile Lifecycle.

Learning and Adaptation

At its heart, Agility is based on the admission that we don't know everything at the start of a project. Even the things we think we know are subject to revision as the project moves forward and the world changes around us. And we most certainly don't know what surprises we will encounter.

Because there is so much uncertainty, we treat each project as a learning experience. In fact, we structure the project to accelerate the rate at which we will learn. Technical issues? Explore them early. Customer uncertainty? Get their feedback on early product increments. Quality questions? Test early and often. Integration difficulties? Build daily, if not continuously. The sooner we answer questions, address issues, and attack difficulties, the sooner we can adapt to what we learn, and the sooner we will smooth out the road for the project.

Adaptation is the reason we want to learn, and learn quickly. We start each project with our best projection about how things will turn out. But as we learn, we invariably discover that some of our projections were off the mark. Where we expected a smooth road, we discover a cliff! Will we keep marching forward like lemmings? Of course we won't. We will adapt by reassessing the situation based on our new knowledge and mapping a new path to our destination. Applying what we learn is the only way to success on our project. Blindly following the old plan would be absurd!

Agile project teams don't just learn about uncertainties. They also learn about themselves and their methods. At the end of each iteration they perform a mini-retrospective. "What worked well? What caused difficulty? How good were our estimates? Did we produce customer value? Are we progressing toward success?" Then they adapt their methods and plans for the next iteration. "What should we do differently this time?" And at the end of the next iteration they ask, "How did that change work? Should we keep it?"

Through a constant cycle of learning and adaptation, the Agile team produces real value for their customers, and learns to do so more and more effectively.

Collaboration

Learning is a natural human activity, and it happens most effectively in an environment of human contact. Collaboration takes many forms on an Agile team, and each of them is critical to the team's ability to be successful in building a valuable product for their customer.

The first type of collaboration happens within the Agile team itself. An Agile team consists of all of the technical disciplines that are required on the project: architects and designers, programmers, database analysts, testers, technical writers, and so on. And rather than hiding in their cubes and working on their own little corners of the project, these people are collaborating with each other constantly throughout the project.

This supports learning (discussed above), as each team member learns about what the others do and learns to appreciate and respect his or her peers. (Yes, even the testers!) This not only builds a healthier project environment, but it also strengthens the team as each member becomes more knowledgeable and effective. Cross-discipline collaboration also allows the team to explore and answer technical questions and discover technical surprises much more quickly. This provides the foundation for learning early and adapting to what is learned in order to bring about project success.

But the team does not collaborate only with each other. They are also fully engaged with management, their customers, and any other stakeholders in the project. Open communication and transparent disclosure of information allows for quick learning and more effective adaptation. In addition, it engenders trust and defuses the all-too-common "us vs. them" mindset. When all who are associated with the project are collaborating with each other and learning along side each other, the project will progress much more smoothly and be much more likely to produce what is needed. And when the inevitable problems arise, instead of pointing fingers and attempting to evade blame, they will be ready to join together to meet the problems head on.

Becoming More Agile

We will discuss the other behaviors of the Essence of Agility in parts two and three of this series. But becoming truly Agile can begin today.

We can accept the principle that we begin each project with many unknowns, and that learning about those things is good! We can look for ways to learn more effectively, and to incorporate what we learn into the project as it moves forward. And we can reward learning, instead of punishing "change."

To make this happen, we can establish a cooperative environment where all of the stakeholders of the project (customer, management, and each technical discipline) collaborate together for the project's success. Free and open flow of information will foster the attitude that we are all in this together, and promote collaboration.

This will get us started on becoming a bit more agile. But these behaviors will be difficult to achieve without the other parts of the Essence of Agility. So stay tuned!