PM Blog: Alan S. Koch

Fix It Fast vs. Fix It Right

2009-11-10T08:46:49-08:00

"Root Cause Analysis (RCA) will be our first Quality Improvement initiative." Carl told me. "It fits your definition of 'low-hanging fruit' (within reach and oh-so sweet). Besides, everyone agrees that we would really benefit from doing it right!"

"Carl is a quick study!" I thought to myself. We had just brought in the first two Senior Quality Analysts for his new Quality Office, and now he was ready to get them started on an initiative that would establish the value of the Quality Office by delivering real benefit to the organization!

A few months earlier, when I did their Quality Appraisal, RCA stood out as a big opportunity. They were already doing something (this put them light years ahead of most places), but for a number of reasons, they were failing to get any real benefit from it. This was our opportunity! Take an RCA process that was limping along, and turn it into a quality improvement powerhouse.

Two Responses to Problems

The heart of the problem with their old RCA process lies in the fact they were mixing and confusing the two distinct and different ways that you can respond to any problem that comes along. Your choices when dealing with a problem are to 1) fix it fast, or 2) fix it right. They were trying to do both of them at the same time, which often isn't possible.

They learned how to fix things fast, and so the "fix it right" part of the equation kept failing, even though they were trying to make it work.

Fix It Fast

That Carl's organization is good at fixing things fast is a feather in their cap, because it is not easy to do! There are many moving parts that must come together to get a problem resolved quickly.

First, the fact that there is a problem must be captured reliably. Whether a user calls and complains, or a monitoring system identifies an issue, or a system falls flat on its face, there must be a mechanism to capture not only the fact that it happened, but also all of the critical information about the failure.

Then, there must be an effective triage process that is designed to quickly and consistently categorize the issues that arise, determine which need to be addressed immediately, and identify who should address them. Information about the critical issue must be handed off to the appropriate technical people so they can get to work immediately. In addition, there must be checks and balances to be sure that issues are not dropped.

Finally, the fix must be put into production quickly so the system users can take advantage of it to get back to work. The fix might only be a patch or a work-around, but at least the issue is removed and the end users can get back to work!

Fixing a problem quickly is all about planning ahead and building good systems and processes so that when you are responding to an issue, things just work. Carl's organization had done this, and although they saw some ways to improve that process, it worked!

Fix It Right

Carl's organization was struggling with fixing things "right" mainly because doing so requires a completely different approach. Instead of mechanisms that are designed for speed, an RCA process needs mechanisms that are very deliberate and thoughtful.

First, there must be regular analysis of the organization's data to identify what problems merit analysis. Carl's organization had declared that all "Critical Failures" should be subjected to RCA. This will catch some of the failures that should be analyzed, but not all. And it will waste some of your effort, because not every "big" issue should receive this sort of scrutiny.

Then the right technical resources must be brought to bear to perform the analysis. Often this should include multiple people representing a variety of technical specialties. Carl's organization made RCA one task that the person responding to the issue must do. This practice guarantees that a group does not do the analysis, and may even put that task on an individual who is ill suited to do it.

The analysis cannot be rushed. Getting to the root cause of a problem often requires time as options are explored and data is gathered. Carl's organization decreed that a "Critical" issue could not be closed until the RCA was done. The push to close issues fast meant that the RCA was rarely given the focus and thought that it deserved.

Root Cause Analysis will often identify a variety options for permanently fixing a problem. Each will have costs, benefits, and shortcomings. So the preferred option must be identified and sold to the organization's decision-makers. The RCA process Carl's organization was using did not even consider alternatives. An RCA's action items were whatever the one person thought of.

Finally, when the organization's decision-makers approve the approach to be taken to permanently fix the problem, it must be treated like any other project (or mini-project). It must be resourced, initiated, and managed to closure. This was the piece that Carl's organization recognized was missing! The RCA Action Items were written down and filed. Where they ever acted upon? No one knows!

Fixing a problem permanently is all about taking the time and investing the resources to do the job well.

Blast Problems with Both Barrels

With this information in hand, Carl's Quality Analysts have a template for building an RCA process that will work for them. The key to success is to separate the RCA process from their existing issue response process. Where their current process says that an RCA must be "done" for a Critical issue, change it to "an RCA must be initiated"!

Then they can craft a whole new process for actually doing root cause analysis—a process that brings the right people together, gives them the time to actually investigate the root causes, and ensures that the results of that analysis are actually put to use.

I have pointed them to ITIL for "Best Practices" on doing this. ITIL's "Incident Management" process is all about fixing incidents fast, while their "Problem Management" process ensures that problems are fixed permanently. Not only does ITIL separate these two processes, but it also provides guidance on how to weave them together for the organization's benefit.

Yes, you can fix it fast and fix it right—just not at the same time! Keep these two concepts separate in your mind and your processes, and you will achieve both!

Related Links
Make sure you're getting to the root of the problem with our Root Cause Analysis Checklist, and make an organized case for your solution with our Recommendation Template. For one example of what a problem solving process might look like, review our suggestions for facilitating a group problem-solving session.

Employee Recognition in an Agile Team

2009-09-01T09:04:56-07:00

Fred sent me this question:

I've read that recognition (in whatever form is most valued to the individual) is an important motivator. In the context of Agile team dynamics, I'm guessing that individual recognition could be counterproductive to everyone working well together, but recognition would be a better motivator if it were directed toward the entire team rather than just to a few individuals on the team that stood out. What do you think?

The Agile methods are designed to make the work environment itself a motivator for the team members. But well-placed recognition can be a powerful addition—if it is done in an Agile way!

Recognition Often Backfires

It seems that there are negative side effects in almost every employee recognition system.

When we focus on individual recognition, some very important behaviors are de-incentivized. To receive recognition, I must excel above my teammates. Even when teamwork is one of the criteria being used, I will look for ways to be more of a team player than the others on the team. The bottom line is competition, and despite our best efforts, that competition can turn ugly.

Many organizations attempt to short circuit competition by focusing recognition on the team. That way, it is reasoned, the team members will have to cooperate and collaborate if they are to achieve the success that will garner recognition. My experience has been that recognition systems that only reward teams and never individuals tend to backfire over time. Sooner or later people become unhappy that the underachievers get just as much limelight as the overachievers.

Of course some organizations attempt to avoid these ills by not recognizing anyone. You are paid for your work, and if you do well, you'll get a raise and maybe a promotion (sometime in the murky future). While this is OK for some people, psychology has taught us that it leaves many wondering if their efforts are really valued.

Recognize What You Value

In crafting any recognition system, we must always start with a clear picture of the behaviors that we value and wish to promote. With that clearly in mind, we can begin to look for ways to promote those behaviors without causing other less desirable ones.

What we value on Agile projects can be boiled down to this:

Satisfy the customer's changing needs
through continuous communication and collaboration
in a self-managing cross-discipline team.

The Agile team is responsible for achieving success, so recognizing the team makes a lot of sense. But the team is comprised of individuals who need to know that they are appreciated. My recommendation is to strike a balance by recognizing both the team and the individuals—when they merit recognition. This requires an objective, multi-point approach.

Individual Recognition Based on 360-Degree Reviews

Agile team members should do 360-degree reviews of each other, not annually, but regularly—at least at the end of each project (more often on projects over three months). The results of these reviews should be aggregated over the long term to build a consistent picture of each person's contribution to their project teams. (This aggregation will also dampen the temptation of people to engage in tit-for-tat. "You give me a good review and I'll give you a good one," or, "You gave me a bad review last time, so I'll make you look bad this time.")

This long-term view can provide important insight for the annual performance appraisal. In addition, it can be the basis for individual recognition. (This person's teammates have repeatedly singled him or her out as a significant contributor to the success of their teams.)

This form of individual recognition should be rare. It should be reserved for truly extraordinary contributions on multiple teams over an extended period of time. I would not recognize an individual in this way if anyone's eyes would roll at the announcement. It should be met with sustained and enthusiastic support from the people this person has worked with.

Team Recognition By Their Customer

At the end of every Agile project, the project's customer should publicize the project results (good or bad), identify the team that produced them, and include whatever superlatives he or she thinks appropriate. After all, if "Our highest priority is to satisfy the customer ...," what other recognition matters?

My only warning here is to be sure that the customer does not feel pressured to say nice things. If things went badly, that should be acknowledged (although without disparaging the team). Of course, if the Agile team is functioning as intended, a bad result should be rare.

This will keep the focus on the main thing we value—producing value for our customers. And it will lavish the attention on the human element that produces value—the team.

That being said, I would add this caveat: There will be rare circumstances when one team member goes above and beyond the call of duty to make the team successful. I don't mean the hard work that we often see from good team members when things get tough, but truly extraordinary actions. If all of the team members point to one person who deserves special recognition, then in addition to what the Customer said, the Coach should add the team's thanks to that individual.

Agile Recognition

This kind of recognition mix will keep the focus on what is important: the team, teamwork, and the value they provide to their customer. At the same time, it will not diminish the fact that teams are comprised of individuals who must cooperate to achieve success, and who sometimes go above and beyond.

Related Links
Kimberly Wiefling suggests over 20 creative rewards for team members, none involving a corporate logo. Our Team Rewards and Recognition Guideline encourages you to plan and budget for team recognition while you're planning the project itself—without getting corny.

What Makes a Project "Agile"? Part 7: Iterative Planning

2009-06-23T09:00:16-07:00

The Essence of Agility
What makes a project "Agile"?
Part 7: Iterative Planning

by Alan S. Koch, PMP

Is it Agile? Or is it lack of discipline? How can we know for sure? The Essence of Agility consists of those sets of observable behaviors that distinguish a truly Agile team from a bunch of undisciplined programmers.

In my six prior columns I addressed seven of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, customer focus, small self-directed teams, embracing Lean principles, Progressive Requirements Elaboration, Incremental Delivery. In this last article of the series, I will address the final key characteristic: Iterative Planning.

Can "Plan" and "Agile" Coexist?

With all that we have discussed so far in this series, you may be wondering how it can even be possible to plan an Agile project. In the first installment, Learning and Adaptation, Collaboration, we talked about expecting surprises and making allowances for them when they happen. In the second, Customer Focus, we said that the customer is so important to the success of our project that when they change their minds (or discover their own surprises), we need to go along with them. Next, in Small Self-Directed Teams, we discussed letting the team self-manage. (Can we really expect them to plan?) In Embracing Lean Principles we discussed the value of making decisions as late as we possibly can. (How is that a plan?) In Progressive Requirements Elaboration we described starting the project with only a rough picture of the requirements. (How can you plan?) And last time, in Incremental Delivery, we noted that the customer is likely to change their minds when they see the delivered increments, and we called that a good thing!

Yes, we can plan in the face of all of these things. But the way we go about planning, and the form the plan takes, will necessarily be significantly different from our traditional plans. Like everything else on an Agile project, planning will be iterative and incremental. Let's see how that plays out.

Initial Planning

Every project begins with planning, and Agile projects are no different. There is no point in pressing forward until we set everyone's expectations about what will be going on.

Traditionally, this planning activity is the planning for the project, and it is expected to be complete, and to be the basis for managing the project through its duration. If the project runs into problems, we do everything in our power to bring it back into conformance with the plan. And if all else fails, as a last resort, we re-plan.

Initial planning activity on an Agile project is quite different. It is not intended to be complete. In fact, an Agile plan intentionally leaves many things unexplored and undefined. This plan is broad-brush, predicated on only a rough list of the requirements (with no detail), and based on rough order-of-magnitude (ROM) estimates. The intent of an Agile plan is to establish the boundaries and expectations within which the project stakeholders will collaborate to drive the project to success.

Embracing the plan for an Agile project is an exercise in embracing ambiguity! We don't pretend to be able to predict all that will happen, so it makes no sense to speculate about the details we can only guess about. What we do is to document what is known (or believed to be true) at the time, forecast how the project will play out if those things prove to be true, and commit to work together to bend those expectations to whatever realities we discover throughout the project.

The Agile project's plan is not a way for the customer to hold our feet to the fire, nor is it a way for management to hold the team's collective feet to the fire. It is a basis for all of these players to collaborate to drive the project to a successful conclusion.

Iteration Planning

Of course, a broad-brush plan that is full of ambiguity naturally lacks the information needed to manage the day-to-day work. For that reason, planning is not considered complete when an Agile project's initial plan is complete. The planning continues in step with the iterative nature of the work.

Agile projects follow an iterative lifecycle, and we call each time through the loop one "iteration." Each iteration of work begins with planning the details of what will go on. This task-level plan is very much like the plans that we put together on traditional projects. The big difference is that this plan is for only a very short period of time. (Each Agile iteration represents only a few weeks of work.)

Of course, it is easy to produce a detailed plan for such a short time period. But we don't do it because it is easy. We do it because we need a detailed plan to help us to successfully finish each iteration and produce a sliver of working software. This task-level plan is what the team refers to in their daily stand-up meetings, and it is their basis for tracking their status.

Re-planning

The final piece of Agile planning relates directly to our expectation of change. In spite of the ambiguity and lack of detail in an Agile team's top-level plan, it will still be affected by changes and surprises on the project. For that reason, re-planning is an integral part of every Agile project.

Unlike traditional methods (where re-planning is considered to be a bad thing, and is avoided at all costs), the Agile approach includes re-planning as a normal and natural part of the process. At the end of each iteration of development, the team does not assume that the plan they embraced before is still valid. They explicitly investigate what has changed in the meantime, and discuss how those changes may affect their top-level plan.

We hope that the project's broad-brush plan is not changing continuously. But if we find that it is, then all of the stakeholders engage in a regular reassessment of the plan to keep it in sync with reality. This is the whole reason why the Agile approach is the best way to manage projects with many unknowns. The more unpredictable the project will be, the more important it is for us to admit that we don't know everything up front, and to actively collaborate to deal with the surprises that arise.

Becoming More Agile

With this last piece of the Essence of Agility (Iterative Planning), we have investigated all of the key behaviors that Agile teams display. If your "Agile" teams display all of them, congratulations! Support them and trust them to deliver the greatest possible customer value that they can within their constraints.

If, on the other hand, some discipline is lacking, you have some ideas about how their Agile processes are breaking down. In this case, you can support them by helping them to learn what they lack so they can become a well-honed, productive Agile team.

Related Links
Our Technique Brief covers some of the major approaches to agile planning. Kent McDonald previously answered the question of what an agile project plan actually looks like. If you're thinking of trying out Agile methodologies, use our checklist for trying a first Agile project.

What Makes a Project "Agile"? Part 6: Incremental Delivery

2009-04-14T16:30:04-07:00

The Essence of Agility
What makes a project "Agile"?
Part 6: Incremental Delivery

by Alan S. Koch, PMP

When developers claim that they are "Agile," how can you know that they're not just hacking? Their methods are unorthodox, even weird! Is there a way to see if they know what they are doing? The Essence of Agility consists of those sets of observable behaviors that distinguish a truly Agile team from a bunch of hackers claiming to be Agile.

In my last five columns I addressed six of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, customer focus, small self-directed teams, embracing Lean principles, and Progressive Requirements Elaboration. In this article, I will address the next key characteristic: Incremental Delivery.

Incremental Development

Incremental development is not a new concept. People have been developing systems incrementally for decades. And although Agile projects build the product in smaller increments than we traditionally think of, the basic premise is the same. First, build a foundational framework, and then add functionality onto that framework a little at a time.

This approach to developing systems has withstood the test of time because it mitigates many of the risks of system development. It narrows the scope of each increment to a specific set of problems, making those problems more tractable. At the same time, it limits the integration issues, because only a limited collection of new components are being integrated at any one time.

The only real complication that is introduced by the use of incremental Development is Regression. Every time an increment of functionality is added to a previously working system, there is the danger that it will regress—that functions that worked previously will mysteriously stop working. But we have developed rigorous Regression Testing methods to limit the number of regressions that can escape our notice.

Incremental Development works—which is why the Agile methods use it.

Customer Acceptance

What is unique about the Agile approach is what we do with each increment of the product after it is developed. Rather than just continuing on with developing the next chunk of the product, an Agile team will bring the product-to-date to their customer for his or her reactions.

"This is what we have built so far. Is it what you need? Are we moving in the right direction?"

Agile teams seek their customer's acceptance of the product-to-date after each iteration of development. The team has done their best to build what their customer told them to build. That includes good engineering work, comprehensive testing, and whatever else was needed to build a high-quality product.

But in the end, quality comes down to satisfying the customer's needs. If we miss that mark, then all of the other good work we have done is wasted. The only person who can tell us if we are building the right product is the customer. So in addition to all of our other quality activities, we must regularly seek our customer's acceptance of the functionality we are building. Waiting until the project is over before seeking their acceptance is as counter-productive as declaring that the patient is cured before we check for a pulse.

Because the Agile approach is so customer-centric, it only makes sense that we would seek their acceptance regularly. That way, we can never go very far off track. When any increment of the product moves in the wrong direction, they will tell us loudly and clearly that something is wrong. And that will allow us to quickly get back on track before things have gone too far wrong.

Delivered to Production?

The phrase "Incremental Delivery" mainly refers to the Agile team's delivery of their product to their customer for acceptance. Every Agile project does this at the end of every iteration. But Agile teams would prefer that "delivery" not stop there.

The purpose of incremental delivery is to get feedback on what has been developed to date. Demonstrating the product to one or a few customers and asking their opinion will gain us a certain amount of valuable feedback. But how much more feedback could we get it the product was actually used in production?

It is for this reason that Agile teams look for opportunities to promote their product-to-date into production as early and as often as it can be done. Obviously, there will be limitations on how early or often they can do this. But if the project is planned with incremental release in mind, it can often be done successfully. For example:

Collaborative Users – Pick out a small subset of system users who will be willing to engage with the development team in this way. They must recognize that early releases do not constitute the final product, and that each incremental release is another step toward fully satisfying their needs. And of course, they must willingly provide the feedback we need, or the effort of making multiple releases will be wasted.
Tolerance for Change – How often these users can accept new versions of the product is an important consideration. If they can accept quarterly changes, then releasing after every few iterations would be possible. In the best of circumstances, they would be able to accept a new version of the product-to-date at the end of every iteration!
Critical Mass – Then identify the critical mass of basic functionality that is necessary for the product to be viable for those users. That can be your first release—the basis on which much more functionality will be built. And depending on the size of that critical mass, that first release could happen quite early in the project.

Delivery into production provides the ultimate in feedback as an Agile team is developing a product. A truly Agile team will seek out these opportunities.

Becoming More Agile

If you already practice some form of iterative development, you already have the basis for doing incremental delivery. And adding this piece of Agility to your toolbox can be done before many of the others are in place. It is an important enabling practice for many of the other parts of the Agile methods.

In the final article of this series, we will discuss how all of the behaviors we have covered so far are planned and managed. Tune in next time for our discussion of Iterative Planning & Adaptation.

Related Links
Conducting retrospectives after each iteration allows the team to improve the next round for themselves and their customers. Big, visible charts keep everyone up to date on what's completed and what isn't. Even non-Agile teams can use techniques like spiral project phases to incorporate incremental delivery.

The Essence of Agility: Progressive Requirements Elaboration

2009-02-04T09:23:23-08:00

The Essence of Agility
What makes a project "Agile"?
Part 5: Progressive Requirements Elaboration

by Alan S. Koch, PMP

They say that they are "Agile," but it just looks like hacking to you. How can you tell? The Essence of Agility consists of those sets of behaviors that distinguish a truly Agile team from a bunch of hackers claiming to be Agile.

In my last four columns I addressed five of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, customer focus, small self-directed teams, and embracing Lean principles. In this article, I will address the next key characteristic: Progressive Requirements Elaboration.

Why "Progressive"?

In the first installments of this series, we discussed three important behaviors of an Agile team. Each of those three behaviors requires a change to the way we elicit and manage requirements.

Learning and Adaptation: If we accept that predictive planning is inappropriate, then we must not expect that we can nail down all of the requirements at the beginning of the project. Both our customer and we will be learning about the requirements as the project moves forward, so our collective understanding of the requirements must adapt to that learning.
Collaboration: A big part of the regular collaboration that must happen on an Agile project centers on the requirements. We must constantly be re-checking our understandings, and be open to new and changed details as the project progresses.
Customer Focus: If we accept that satisfying our customer is paramount, then we must be willing to adapt to their changing needs. Sometimes the change is merely a matter of our customer refining their understanding of their needs. But sometimes they experience real changes in mid-project. Either way, the requirements must adapt to those changes.

Project vs. Customer Needs

If we are to focus only on our customer's needs, we might decide that no requirements should be documented. That way we would have ultimate flexibility in reacting to our customer's needs!

But that approach is insufficient because it gives us no basis for planning and managing the project. We need an understanding of what the project is supposed to deliver so we can ensure that appropriate resources and time are being brought to bear. (That is why we like big up-front requirements with sign-offs!)

Progressive requirements elaboration allows an Agile team to balance their customer's need for flexibility with their own need to plan their work. Although there is no simple formula for how an Agile team does its work, we will use Scrum (one of the Agile Methods) as our touchstone in talking about this behavior. (Please note that your team may not be precisely following these steps, but may still be taking an Agile approach to their requirements.)

Progressive Step 1: Product Backlog

The very first step in a Scrum project is for the team and their customer to collaborate to define the Product Backlog. Note that the word "backlog" does not connote being behind schedule or any other negative idea. The Product Backlog is the team's best understanding of a complete list of the names of the requirements for the project. Think of each item in the Product Backlog as the title of a requirement with no further information.

The purpose of this information is to meet the team's need for a basis of planning. Each backlog item will be a deliverable of the project, and so the project will require the sum of the time and resources required to produce these deliverables. After the customer prioritizes the backlog items and the technical team produces a ROM (rough order of magnitude) estimate of each, a broad plan for the flow of the project can be produced. I call this the Project Roadmap.

Although the Product Backlog is produced at the beginning of a Scrum project, it is never treated as final. The customer and the team can add, delete, re-define, re-prioritize, or re-estimate backlog items at any time. And of course, significant changes to the Product Backlog will result in changes to the Project Roadmap.

Progressive Step 2: Iteration Backlog

The Project Roadmap does not provide the information that the Agile team needs to manage their work during each iteration. In order to produce their iteration plan, the Agile team will usually require a more detailed understanding of the Backlog Items that will be addressed during that iteration. So, as a part of iteration planning, the team and their customer discuss each requirement for that iteration in much more detail.

Different Agile teams capture this more detailed information in different ways. Some write one or more Use Cases for each requirement, and others simply make notes on the Story Cards. Some teams don't capture the additional detail in written form at all, preferring to rely on memory. (I don't recommend this reliance on memory because … because … I can't remember why.)

The Scrum team's Iteration Backlog consists of a list of the work they will do during the iteration in order to deliver the Product Backlog items that have been selected for that iteration.

Please realize that the nth level of detail about the requirements is not elicited and documented at this point. The team only needs enough requirements detail to plan the work they will do over the next few weeks. However, if the team's customer is not Agile and will not be available for Progressive Step 3, then the team must try to capture detailed requirements at this point. (This compromises agility, so it should be avoided if possible.)

Progressive Step 3: Writing the Code

Many of the details in a Requirements Specification are not needed for planning, but are there to direct the coding effort. An Agile team will elicit those details from their customer as the code is being written. Naturally, this would necessitate that their customer is available to them continuously—or at least regularly.

Because these detailed requirements don't need to be recorded for future use, Agile teams usually document them not in a Specification, but in some more usable and actionable form. Examples that are seen on many Agile projects include:

Test Cases: When the customer says "It must work this way," test cases are immediately written to capture that information. When the tests pass, the code is correct. (This is called Test-Driven Development, or TDD, and is a very good quality practice!)
Self-Documenting Code: While test cases capture what the software must do, they may not provide sufficient background information about why. So, Agile teams will adopt coding standards that result in code and comments that make the programs as readable as any specification would be.

Becoming More Agile

Progressive Requirements Elaboration goes hand-in-hand with the last two behaviors, Incremental Delivery and Iterative Planning & Adaptation (which we will discuss in the last installments of this series). Requirements can only be approached progressively in a project that is run as a series of discrete steps that are not fully defined and planned predicatively.

The biggest challenge in adopting Progressive Requirements Elaboration lies in helping your customer to understand how this new approach works, and how it benefits them. We must emphasize the flexibility that this approach provides for them, and the degree to which it guarantees that the product we deliver will be precisely what they need. Only then will they be willing to make the investment of their own time that this approach requires.

Related Links
Requirements Cards are just one way of capturing backlog features without excessive documentation. Detailed test plans are a best practice for any project, agile or otherwise. Kent McDonald has explored the Agile concept of continuous customer involvement and the "single wringable neck," and explains why sometimes just one person isn't enough.

The Essence of Agility: Embracing Lean Principles

2008-11-21T17:17:08-08:00

The Essence of Agility
What makes a project "Agile"?
Part 4: Embracing Lean Principles

by Alan S. Koch, PMP

The Essence of Agility consists of those sets of behaviors that distinguish a truly Agile team from a bunch of hackers claiming to be Agile. They are the markers that any concerned stakeholder can use to answer an important question: “Are they being Agile, or just lazy?”

In my last three columns I addressed four of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, customer focus, and small, self-directed teams. In this article, I will address the next key characteristic: Embracing Lean principles.

Lean Principles

Lean Manufacturing has been around for decades, and has been embraced by companies worldwide as the way to run a manufacturing organization. And as much as those of us who have been fighting the concept of “software factories” might hate the idea, the same principles that underpin Lean Manufacturing are quite useful in software projects. (YIKES!)

So, let’s forget for a few minutes that these principles had their genesis in the manufacturing world, and explore how Agile software projects embrace the seven Lean principles: Eliminate Waste, Amplify Learning, Decide as Late as Possible, Deliver as Fast as Possible, Empower the Team, Build Integrity In, and See the Whole.

Eliminate Waste

A team that is behaving in a truly Agile way will always be examining their own efficiency. They will always be asking questions like, “What value does that activity add?” “Why should we do that?” and “Is there an easier way to achieve the same (or better) end?”

Agile teams define “waste” in terms of their effort. Effort that is spent but does not produce tangible results is deserving of scrutiny. Naturally, some “overhead” activity is necessary on any kind of project, Agile or otherwise. But an Agile team will always look for ways to minimize overhead to only that which is actually necessary.

They may raise questions about documentation or meetings that will challenge our traditional ideas, but troubling questions are good questions. And if we can’t come up with good answers for them, then we should be glad the questions were raised!

Amplify Learning

Projects are, at their heart, learning experiences. When we begin a new project, regardless of how much we know about it, there always remains much we do not know. As we work our way through the project, we learn all of those things that we were ignorant of at the beginning. And at project’s end, we finally know all there is to know (albeit a bit too late to make a difference).

Agile teams embrace this idea. Instead of planning like they already know it all, they plan to only the level of detail they need at the time, and they provide themselves with as many learning opportunities as they possibly can. They build regular and significant feedback loops into their processes, and they plan to capitalize on what they learn from that feedback to adapt their plans.

By amplifying their opportunities to learn (and actually using that information), an Agile team can be sure to build the product that is actually needed by their customer, and do it as efficiently as possible.

Decide as Late as Possible

If we accept that we do not know it all, and that we will be learning as we work through the project, then it stands to reason that we will want to postpone decisions until we have all of the information we need to make good ones.

Of course, the big conundrum is that we are not aware of what it is that we do not know. This can lead to a paralyzing fear of making any decisions at all. And procrastination is just as counterproductive as premature commitment to decisions.

Agile teams seek to postpone making each individual decision until the latest responsible moment—that is, the latest time that the decision can be made without slowing progress or causing problems. When it is time to make a decision, the Agile team will do so based on the best information available at that time from the customer, technical experts, and any other source.

Then …

Deliver as Fast as Possible

After making a decision, an Agile team will drive the resulting work to its conclusion as quickly as possible. Lean organizations always strive to minimize work-in-progress. The reasons for doing so on software projects are different from in manufacturing:

Switching tasks is an error-inducing activity. Each time a programmer returns to partially complete work, he or she is likely to introduce defects into the product.
Partially complete work is subject to disruption or obsolescence in a rapidly changing environment.
Delivering quickly means that you receive feedback on the completed work more quickly (which amplifies learning).
Delivering something is gratifying for developers. The more quickly we deliver, the sooner we feel that reward.

Empower the Team

A self-directed team must be empowered by management to make their own decisions (collaboratively with their customer and other relevant people). When a team has been so empowered, they must embrace this authority, exercise it freely, and own their decisions—both the good ones and the bad.

Agility requires self-directed teams, because only such a team can be effective in learning and adapting to what they learn in their pursuit of their goals. An Agile team will seek authority to self-direct, and then exercise that authority with care.

Build Integrity In

Agile teams don’t just sling code. They are strongly focused on providing the product that their customer needs. It goes without saying that the customer needs a product that is high quality. Agile teams embrace a variety of technical practices that are focused on quality:

Pair programming is essentially a continuous real-time code review.
Test-driven development means that the programmers design and implement tests before beginning to code, then use those tests as their measure of progress.
Continuous integration includes continuous regression testing to ensure that as the system is incrementally built, errors are not introduced.
Refactoring is a matter of continually re-addressing the design of a program, and making adjustments when needed, instead of continuously force-fitting a bad design.

See the Whole

Finally, Agile teams always keep the big picture in front of themselves. Programming is such detailed work that it is easy to get lost in those details and end up doing the wrong thing. By keeping their customer close and seeking the customer’s feedback on a regular basis, an Agile team assures that they never lose sight of the one team member who is most important: their customer.

Becoming More Agile

We will discuss the last three behaviors of the Essence of Agility (Progressive requirements elaboration, Incremental delivery, and Iterative planning and adaptation) in the remaining installments of this series. But becoming truly Agile can begin today. Examine the seven lean principles, see how close your team comes to each of them, and take steps to make each a normal part of their work.

Embracing Lean principles will take some time. But each of them that you adopt will bring your team one step closer to true Agility.

Related Links
Review Alan’s previous articles in this series, which address Learning and adaptation, collaboration, customer focus, and small, self-directed teams in an agile methodology.

Small, Self-Directed Teams

2008-09-16T11:39:48-07:00

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

by Alan S. Koch, PMP

The Essence of Agility consists of those sets of behaviors that distinguish a truly Agile team from a bunch of hackers who are claiming to be Agile. They are the markers that any concerned stakeholder can use to answer an important question, "Are they being Agile? Or just lazy?"

In my last two columns I addressed three of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, and customer focus. In this article, I will address the next key characteristic: Small, self-directed teams.

Small Self-Directed Teams

Agile project teams are small (generally fewer than 12 individuals), and they self-direct (or manage themselves).

"Small" is easy to see. If the project consists of 20 or 50 or more contributors, it is unlikely that they will be able to self-direct as an Agile team should. (Although there are ways to break a large project into several self-directed teams who work in parallel with each other, we will not address that option in this article.)

"Self-directed" is less obvious. What behaviors would indicate that a team is self-directing? Some people use the term self-directing synonymously with self-organizing and self-managing. The easiest way to think about these ideas is to watch the team's relationship with their management.

In traditional organizations, project teams rely upon their managers to prepare their plans, tell them what to do, track their status, and take corrective action. Some managers do these things more or less collaboratively with the team, considering their input, but the teams almost exclusively rely on management for these things. The net result of this mode of operation is that the manager carries all of the accountability for the team's work.

An Agile team turns the tables on these traditional arrangements, taking responsibility not only for their technical work, but also for making commitments and performing according to their commitments. How can they do this? It is achievable when the team consists of the people who have the requisite experience and perspective, both technical and business.

Product Owner

An Agile team includes a very important member who is often called the "Product Owner" (using the terminology of Scrum, one of the Agile methods). This person is accountable to the members of his or her end user and business stakeholder communities to ensure that the best possible product is built within the constraints of the project. This person owns the requirements of the project, and is responsible for defining a Product Vision, elaborating the product requirements, and prioritizing them so the technical members of the team have a clear objective to achieve. (We will discuss this Progressive Requirements Elaboration in a later installment of this series.)

To be clear, the Product Owner is a member of the team! This person does not chuck the requirements over a wall to the developers then await the end of the project. He or she collaborates with the developers regularly throughout the entire life of the project, providing direction and clarification about the product, then real-time feedback as the product is being built.

Planning Their Own Work

With the Product Owner as an active member of the team, the technical members of the team have all of the information they need to plan and manage their own work. Planning is done in a workshop format, with the technical members using their experience to establish a plan and estimate the work. They determine what is achievable, where the risks are, and what can be done to make the project both achievable and aggressive.

Many people worry that a team that plans their own work will not plan aggressively. First, this is rarely the case with software professionals. (Really! How often have you seen a software professional over-estimate the effort required for a task?) But the presence of the Product Owner in these planning sessions ensures that pressing business needs will always be a part of the discussion. These deliberations can produce the best plans—plans that meet the real business need, and can actually be delivered upon without turning the engineers into lemmings marching toward a cliff.

Another thing that makes this type of planning work well is that the team produces only a broad roadmap for the entire project. They build detailed plans only for the work they will do in the next iteration or so (about a month at a time). This incremental planning (which we will explore in a later installment in this series) allows the team to capitalize on what they have learned to date to produce the best possible plans.

When a team establishes their own plans in this way, they feel a real ownership, and this gives rise to careful managing of their work and taking corrective action when things begin to go awry. Yes, things still go wrong on an Agile project. But they can't go very far off course before the Product Owner and the technical members of the team have convened a meeting to figure out what to do about it.

The Coach

The remaining role on the Agile team that we have not mentioned is that of the Coach. Self-directing teams absolutely need a Coach to keep them on track. The good part about having technical people plan and manage their own work is that they are the people with the requisite experience and knowledge. But technical work can easily draw the best engineers into its details, causing them to lose focus on the big picture. The Coach's role is to be the team's conscience.

The Coach acts as the facilitator of the team's planning and status meetings, encourages and guides the players (as a sports coach would), and regularly draws their attention to the big picture of their team goals, and how they are progressing against their commitments. Unlike the traditional project manager, the Coach doesn't tell the technical team what to do about problems. His or her job is to be sure the team recognizes problems when they come up, and to facilitate their decision-making about how to address those problems.

Self-directed teams are not a new concept of the Agile methods—they are merely an important enabler of the behaviors that are required of an Agile team.

Becoming More Agile

We will discuss the last four behaviors of the Essence of Agility (Lean principles, Progressive requirements elaboration, Incremental delivery, and Iterative planning and adaptation) in the remaining installments of this series. But becoming truly Agile can begin today.

We can empower our project teams to self-direct by engaging a Product Owner to provide guidance and leading them in their first halting attempts at self-management. This is a big step for many of our technical people, and they will need to learn how to do it. But once they have learned, they will embrace each project with the enthusiasm that comes from a sense of ownership. This won't keep things from going wrong. But it will keep the project real—achievable, and aggressive.

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!

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!