PM Blog: Alan S. Koch

How to Estimate Program Size

2010-08-18T09:52:55-07:00

In my last article on Cost of Quality, I started out by blithely proposing, "Let's say we're going to write a system of 25,000 Lines of Code." Teri (a perceptive reader) called me on it! She wrote:

If a new system is built, how do you guess at how many lines of code there will be? You possibly can guess at the number of programs from looking at the requirements but how do you guess the number of lines involved for each program?

It's an important question without a quick and easy answer. This was what I told Teri.

Why Lines of Code?

In my article I used Lines of Code (LOC) as the unit for measuring the size of software. Some people embrace this unit and others are adamantly against it, preferring Function Points. So the first step is to decide if you will measure the size of your software in LOC, Function Points, or some other unit. A good unit will have these attributes:

It correlates with the effort involved in producing the software, defect rates and anything else we would want to use the estimates for. Both LOC and Function Points correlate nicely with these things.
It can be measured objectively in existing code. LOC is quite easy to measure; LOC counters abound. Function Points cannot be measured using a tool, and counting them manually in existing code is not an exact science.
It can be estimated by professionals. Function Points were designed precisely for estimating systems before they are built. Using LOC for this purpose is less straightforward, but it can be done handily using the techniques I will describe below.

These things lead me to choose LOC as my unit of choice. (And I am not alone.) But it is a professional preference. If you prefer a different unit, then by all means, use it.

After we have chosen a unit of measure, we can use it to do two things: Compile our historical data, and use that data to estimate each new system we will build.

Compiling Historical Data

We all have libraries full of code written by our developers. Those libraries are goldmines! Let's start digging.

Measure your existing software using your chosen unit. You could measure each source file, but this is likely not your best option because there are usually multiple components in each file. Measuring each component instead (e.g. each function or class) gives you a lot of data for the next two steps, which is a good thing. It also allows you to be more precise, which will make for better precision in the estimates based on your measurements.

Categorize each component you measured. The categories need to be things developers can visualize based on requirements (e.g., an I/O function or a certain type of a class). How many categories should you have? Too many will make it difficult for developers to slot individual components. Too few will give you less precision. My recommendation: you should have around a dozen categories. Of course, the size of your library will be a factor, because you need to have several examples of each category for the next step.

Document the size ranges for each category. If your data set is large enough to use statistical techniques, compute the Mean and Standard Deviation for each category. For smaller data sets (the norm when you are just getting started), just capture the Min, Mean, and Max sizes for each category.

Now you have a list of a dozen or so categories of software component that you find in your systems, and for each, you have basic size ranges. This gives you the data you need to estimate a new project.

Estimating the Size of a System

This estimating process can only be accomplished by development professionals. (Sorry! Project Managers must stand by and watch, or facilitate!) It works best as a workshop in which the whole development team can discuss the requirements and come to consensus on the estimates. If the team has not yet been assigned, the estimates should be prepared by at least two competent development professionals. Based on the requirements, the developers compile two lists:

Components that will change. If the project is to change or enhance an existing system, or if a new system will be build using an existing one as a starting point, the developers must identify each existing component that will be changed. For each of these components they must:
- measure its existing size;
- estimate how much of it will be changed (only a ball park estimate, e.g. around 30%); and
- compute the size of the change by multiplying the existing component size by the estimated percentage change.
New components to be built. The developers then forecast the new components they expect to build. For each of these components they must:
- identify the category from your historical data that it best fits into;
- determine whether it would be a "very small", "small", "medium", "large", or "very large" example of that category; and
- assign an estimated size based on category, the small-medium-large judgment, and your historical data. This is where the size of your historical data set comes in. If you have enough data to use statistical methods, then your size estimate for each component will be:
  - "Very small" = Mean – 2 Standard Deviations
  - "Small" = Mean – 1 Standard Deviation
  - "Medium" = Mean
  - "Large" = Mean + 1 Standard Deviation
  - "Very large" = Mean + 2 Standard Deviations
If your historical data set is small so that you only have Min, Mean and Max values, then your size estimate for each component will be:
- "Very small" = Half of Min
- "Small" = Min
- "Medium" = Mean
- "Large" = Max
- "Very large" = Twice Max
Either way, the developers must apply their best judgment to the "Very small" and "Very large" estimates. If the estimates look unrealistic, the developers should adjust them.

With the developer estimates in hand, you can easily compute the expected size of the new system. Just add up the estimated new and changed component sizes to get the total project size. You may want to inflate the total estimate if the team believes they have not identified all of the components.

Better Estimates Next Time!

At the end of the project, you will want to add all of the newly created components to your historical data. (More data is always better!) Be sure to categorize them properly and use the actual final sizes, not the estimates! You will also want to update the historical data for any existing components that have changed.

Then re-compute the size ranges for each category. After doing a few projects (or one big one), you will likely have enough data to compute Mean and Standard Deviation for your categories, which will give you better estimates than Min, Mean and Max.

Finally, the developers can improve their ability to use this sort of estimating technique by comparing their initial list of components and estimated sizes with what they ended up with at the end of the project. They should specifically look for:

Components they built or changed, but did not identify during estimation
Components they identified during estimation, but did not build or change
Size estimates that were way off (e.g. anything that was estimated "Medium" but ended up being "Very Large")

These errors should all be documented as lessons learned on the project. Then those lessons should be reviewed immediately before the next project is estimated.

Using techniques like these, you too will be able to blithely comment on the estimated size of your projects!

Related Resources
How do I get estimates when the work is uncertain?

IT project templates – an index for project managers

Software Requirements Specification – Make sure you capture all the requirements

Project Tradeoffs Table for negotiating trade-offs when you can't possibly complete every requirement

How Much Quality Can We Afford?

2010-06-08T11:06:21-07:00

Sure, it might be nice to build a higher quality product. But how much quality can we really afford? Well, let's break out our Cost of Quality Calculator and try out the numbers.

What is Our Cost of Quality Today?

First the basics: Let's say we're going to write a system of 25,000 Lines of Code, and our data tells us that we inject about 50 defects per 1000 lines of code. So along with those 25 KLOC, we will also write 1250 defects.

			Defect Injection		Defect Removal		Defects in Product		Cost of Quality
Activity	Size		Rate	#	Yield	#	#	/KLOC	Rate	Hours
Design & Code	25	KLOC	50	1250			1250	50.00
Totals				1250		0	1250	50.00		0

For a system of that size, we usually end up with a 20-page requirements document and a 40-page high-level design specification. And since we usually inject 5 defects per page in our documents, that gives us 100 defects in the requirements and 200 defects in the design bringing our total to 1550 defects.

			Defect Injection		Defect Removal		Defects in Product		Cost of Quality
Activity	Size		Rate	#	Yield	#	#	/KLOC	Rate	Hours
Write Requirements	20	Pgs	5	100			100	4.00
High Level Design	40	Pgs	5	200			300	12.00
Design & Code	25	KLOC	50	1250			1550	62.00
Totals				1550		0	1550	62.00		0

Of course, we always review the requirements. We review about 10 pages of requirements per hour, finding 40% of the defects in the document. We incur 2 hours of Cost of Quality to find and fix 40 defects.

			Defect Injection		Defect Removal		Defects in Product		Cost of Quality
Activity	Size		Rate	#	Yield	#	#	/KLOC	Rate	Hours
Write Requirements	20	Pgs	5	100			100	4.00
Review Requirements					40%	40	60	2.40	10	2
High Level Design	40	Pgs	5	200			260	10.40
Design & Code	25	KLOC	50	1250			1510	60.40
Totals				1550		40	1510	60.40		2

And of course, we test. Our data tells us that we find 50% of the existing defects in Unit test and that we can do it at the rate of 5 defects found and fixed per hour. We find 40% of the existing defects in Integration (at a rate of 2 hours per defect found & fixed, or 0.5 defects per hour), and 30% in System test (at a rate of 10 hours per defect found and fixed, or 0.1 defects per hour). Unfortunately, we also inject about 2.5 new defects for every 100 we fix.

			Defect Injection		Defect Removal		Defects in Product		Cost of Quality
Activity	Size		Rate	#	Yield	#	#	/KLOC	Rate	Hours
Write Requirements	20	Pgs	5	100			100	4.00
Review Requirements					40%	40	60	2.40	10	2
High Level Design	40	Pgs	5	200			260	10.40
Design & Code	25	KLOC	50	1250			1510	60.40
Unit Test			2.5%	19	50%	755	774	30.96	5	151
Integration Test			2.5%	8	40%	310	472	18.88	0.5	619
System Test			2.5%	4	30%	142	334	13.36	0.1	1416
Totals				1580		1246	334	13.36		2188

So this spreadsheet represents our normal 25KLOC software project. Over a person-year of effort spent in Cost of Quality work, and hundreds of defects delivered. More than 13 defects per 1000 lines of code is pretty bad.

How much will it cost us to improve it?

What if we were to do a more formal inspection of the requirements? Let's say we could only inspect about 2 pages per hour, but would find 65% of the existing defects.

			Defect Injection		Defect Removal		Defects in Product		Cost of Quality
Activity	Size		Rate	#	Yield	#	#	/KLOC	Rate	Hours
Write Requirements	20	Pgs	5	100			100	4.00
Inspect Requirements					65%	65	35	1.40	2	10
High Level Design	40	Pgs	5	200			235	9.40
Design & Code	25	KLOC	50	1250			1485	59.40
Unit Test			2.5%	19	50%	743	761	30.44	5	149
Integration Test			2.5%	8	40%	304	464	18.57	0.5	609
System Test			2.5%	3	30%	139	328	13.14	0.1	1393
Totals				1580		1251	328	13.14		2160

We found more defects, but look! Our cost of Quality went down! Why did that happen? Because those defects we removed early in the inspection didn't get found later in testing when they are more expensive. Cool! Let's try inspecting our design document, too!

			Defect Injection		Defect Removal		Defects in Product		Cost of Quality
Activity	Size		Rate	#	Yield	#	#	/KLOC	Rate	Hours
Write Requirements	20	Pgs	5	100			100	4.00
Inspect Requirements					65%	65	35	1.40	2	10
High Level Design	40	Pgs	5	200			235	9.40
HL Design Inspection					65%	153	82	3.29	2	20
Design & Code	25	KLOC	50	1250			1332	53.29
Unit Test			2.5%	17	50%	666	683	27.31	5	133
Integration Test			2.5%	7	40%	273	416	16.66	.05	546
System Test			2.5%	3	30%	125	295	11.79	0.1	1249
Totals				1577		1282	295	11.79		1959

Yes! Same again! Fewer defects and less time spent in Cost of Quality! Our coding is our biggest source of defects. What if we inspect the code as well? Let's plan for the same 65% yield and say we can inspect code at 100 LOC per hour. (That's gonna be a lot of hours, but here goes!)

			Defect Injection		Defect Removal		Defects in Product		Cost of Quality
Activity	Size		Rate	#	Yield	#	#	/KLOC	Rate	Hours
Write Requirements	20	Pgs	5	100			100	4.00
Inspect Requirements					65%	65	35	1.40	2	10
High Level Design	40	Pgs	5	200			235	9.40
HL Design Inspection					65%	153	82	3.29	2	20
Design & Code	25	KLOC	50	1250			1332	53.29
Design & Code Inspections					65%	866	466	18.65	100	250
Unit Test			2.5%	6	50%	233	239	9.56	5	47
Integration Test			2.5%	2	40%	96	146	5.83	0.5	191
System Test			2.5%	1	30%	44	103	4.13	0.1	437
Totals				1559		1456	103	4.13		955

Jackpot! We improved our defect level by almost a factor of three! And we cut our Cost of Quality by more than half! We have achieved a respectable defect level of less than 5 defects per 1000 lines of code while investing less than half of the quality effort we started with.

So, What Do The Numbers Mean?

Of course all of this is theoretical and based on some basic averages that many organizations have reported. This exercise will be most interesting when you plug in your own organization's numbers.

What? You don't have these numbers? Better start measuring your Cost of Quality today!

P.S. If you want to use my spreadsheet instead of building your own, just download it here or from my website at www.ASKProcess.com/resources/CostOfQuality.xls.

Related Resources
Our Requirements Walkthrough Checklist can help you organize a productive inspection of requirements. Make sure everyone knows what they should look for when reviewing requirements.

The Agile Customer

2010-03-30T09:41:08-07:00

Making your supplier a bit more Agile

"We are adopting an Agile method for our internal development projects." This student in my Agile Project Management Boot Camp is really beginning to embrace Agility. But ... "But on my project, some of the development work is being done by an outside contractor who is decidedly non-Agile! How can we be Agile when they are not?"

Agility is relatively easy when you control all of the parts of the project. But when others are involved, barriers to Agility can begin to spring up. The best way to overcome those barriers depends upon your situation. So let's explore options for injecting some Agility in spite of the Waterfall raining down on you from your supplier.

Hire an Agile Contractor

The obvious best case would be for you to contract with suppliers who have already embraced Agility. They will understand what you are trying to achieve and work with you to make the iterative lifecycle work to your advantage.

Unfortunately, many of us find ourselves beyond this point in the process. The supplier has already been chosen (by us or someone else) and changing suppliers is either impossible or highly undesirable. Next time, we must be sure to choose an Agile supplier!

But in the mean time, all is not lost on this project. Even though we find ourselves in a less-than-optimal position, we can still make the best of it. We can work with this supplier in a way that will make the relationship a bit more Agile.

Write an Agile Contract

The contract defines expectations with our supplier, so we really need to start there. Most contracts are written with the Waterfall in mind. First there are requirements, then a design, then (at the end of the timeframe) they deliver a product to us for acceptance. If we are to interact with our supplier in a more Agile way, then the contract must not enforce waterfall!

But what if the contract has already been written and signed? Can you say "Contract Mod"? Few contracts go unchanged for their lives. If your contract does not support an Agile approach, then change it. Very few suppliers would balk at a time and materials contract with no fixed deliverables pre-defined. (And if your powers-that-be won't go for the concept of an Agile contract, then you have bigger problems than a Waterfall supplier!)

The key difference with an Agile contract is in the deliverables. An Agile relationship calls for completely different deliverables than the normal waterfall-ish ones. Our Agile contract must call for Agile deliverables. For example:

The supplier will collaborate with us to define a Requirements framework that draws a broad picture of the product they are to build. In addition, they agree to work out the requirement details collaboratively with us as the project progresses.
If we feel that up-front design work is necessary for the type of product they are building, then the supplier must deliver an architectural framework (without all of the design details). This framework must provide enough detail so we can ensure that anything we are building will fit together with what the supplier will deliver to us.
The supplier must deliver a product deliverable to us for acceptance every month or two, beginning no more than two months after the requirements and architectural frameworks are complete. If the supplier is stuck in the waterfall, we must ensure that the earliest product deliverables are things they are capable of building. For example, most suppliers can build the main User Interface or workflow screens with no actual processing code or database undergirding it.
At the beginning of each of those month-or-two chunks of work, the supplier will collaborate with us to define precisely what they are to deliver in that time box, including the details of the requirements.
If this supplier's product must integrate with other software that we are developing, then these interim product deliverables must build up to the right set of capabilities at appropriate times in the project.

An Agile contract must establish time boxes and budget limits, but leave requirements details as the variable for managing the relationship. Ultimately, the supplier will be paid a fixed fee for a fixed timeframe, and will work with us (their customer) to determine precisely what they will deliver.

Be an Agile Customer

We are used to being the supplier for our customers. But when it comes to our supplier, the shoe is literally on the other foot. They are the supplier, and we are the customers. That means that we are the "single wring-able neck" that Ken Schwaber talks about in the Scrum book.

If we are successful at establishing an Agile contract with our supplier, that means that they will be delivering what we asked for. And that means that we must be asking for the right things! If we end up with the wrong product at the end of the project, it is because we have not been diligent in providing feedback to our supplier about each deliverable.

The other part of being an Agile customer is making the hard choices. When things aren't going well (there are technical difficulties, or the things we want take longer to do that we anticipated), then we must decide how to make the project fit into the prescribed time box. What requirements are truly required? And how much (or little) gold plating do we really need? And in the end, if it really will take more time and money to get what we need, we must admit it and pay the piper.

As the project moves forward, we will quickly come to understand precisely what our supplier is capable of delivering, both from a technology and a quality standpoint. This allows us to take any corrective action that is needed early in the project. And in the end, it allows us to get the greatest benefit we can from the contractor relationship while mitigating the risks.

Related Links
Partner Contract Guidelines
When outside partners are employed to execute part or all of a project, the contract with that partner is critical for defining expectations, due dates, and responsibilities. This template provides guidelines for typical contents for such contracts.

Vendor Assessment Checklist
A set of questions to ask a company or contract resource you're thinking of hiring for your project. The questions are aimed at ensuring you have a common understanding and good fit in goals, skills and experience, processes, and priorities. Avoid disaster! Choose your partner well.

Agile Project Management Index Our Agile Project Management resources help you understand and apply agile principles, practices, and techniques to your projects.

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!