I hope this will be done by then.

These are sad and scary words to me.  When I hear them in the context of a software development project, I associate them with a project unlikely to meet expectations.  Further, it’s likely that there is no good indicator of what can be delivered when.  With no hard evidence to tell them what’s possible, and to judge the effects of changes they try, people fall back on a strategy of hope. They no longer feel in control of the situation.

We’ve done our part.

This signals the underlying hopelessness. When you can’t make things come out the way you want, when you can’t even predict how they will come out, one natural response is to give up. Often the cultural expectations don’t allow saying “this project is in trouble.” The person who does so is the person who will attract all the scrutiny. Without the clear data to back up the perception of trouble, why stick your neck out? Others should be noticing the same thing; let them call attention to it. And when things don’t work out as “hoped,” if weve “done our part,” then someone else will get the blame.

You can’t solve a problem that no one wants to see. Instead, we’ve found an acceptable way to fail.

I’d like to share with you an interview conducted by Bill Fox for his 5 Minutes to Process Improvement Success project. My interview, “Measure Progress in a Way that’s Visible and Reliable,” is found on page 69 of the PDF.  You’ll also find interesting interviews with Karen Base, Kevin Schaaff, Hillel Glazer, Scott Ambler, Neil Potter, Bob Payne, Mike Bonamassa, Mario Hyland, Jeff Dalton, Paul E. McMahon, Karl Wiegers, Mary Lynn Penn, Ally Gill, Alan Shalloway, and Tom Cagley. And there are more to come in the future.

My advice is to

• measure your progress
• watch the trends
• project the trends tentatively into the future

and relax.  It’ll work out the best it can.  False precision won’t make it any better.

Now I just read The Virtues of the Imprecisely Measured Self by Alex Knapp at Forbes. He tells the tale of a study in the journal Psychological Science April 2011 that indicates that precision, whether false or not, inhibits success.  Alex summarizes,

Precision can actually be the enemy of performance goals. To be sure, feedback is definitely a positive thing. But it appears that if you want to keep yourself motivated, it’s best to get a more generalized, imprecise feedback that lets you know you’re heading in the right direction, rather than the precise coordinates of where you are on the path.

It’s something to think about.

Teamwork

The fundamental practice of teamwork remains essential.  Agile succeeds in large part by reducing wasted effort, and much wasted effort is the result of various people pulling in different directions.  Even slightly different directions will create enough friction to noticeably slow the project.  It’s well worth spending some time and effort on building an effective team within the context of the project.  The two practices most essential for supporting teamwork in an Agile transition are working with a whole team in a common area.

Whole Team

While collaborative teamwork among all the developers, for example, is beneficial to any project, it’s not enough to accomplish a transition to Agile.  At a core, you’ll need high-bandwidth collaboration between your Product Owner, Scrummaster, and Developers.  This is the minimum, in Scrum terms.  In most organizations, Developers really includes both programmers and testers; in some it includes user experience designers.  Yours may include people with other titles, such as architect, database administrator, security officer, system administrator, operations engineer, technical writer….

Your project community will also consist of other stakeholders, such as executives, customers, end users, support personnel, other development teams, facilities maintenance…. There are a lot of people with interest in the project or the things that the project team is doing.

The boundary between the core team and the rest of the project community is rarely distinct.  One useful distinction is whether a person is focused principally on the project, or whether the project is just one of many things with which the person is concerned.  This distinction is not without peril, however.

All too often an organization will assign multiple projects to people where it would be much better if they were focused on one.  If you give your Product Owner, your programmers, or your testers multiple simultaneous projects, you’re likely headed for trouble.  You may be headed for trouble if you multi-task in some of the other specialties, but there’s more variation from one context to another.  As a rule of thumb, if there is any way to let someone focus on only one project, then you should do so.

Common Area

Building a team, which is different from a mere work group, takes a lot of work.  With skill, you can facilitate that teambuilding to help it happen more reliably and a little faster.  If you don’t have a skilled facilitator, though, you’re still in luck.  People have practiced self-organizing into small groups for their common good for millennia. If they’re working together for a common goal in a common area, distinct from those working on other goals, they’ll likely build a gelled team without an outside facilitator.  There are many reasons for this, from trust building to osmotic communication.

“But we can’t do that,” I hear you cry!  Why not?  Is this project, this Agile transition, so unimportant that you can’t sit together?

“Our Product Owner has an office elsewhere, and needs to attend to other things.” Maybe you’ve chosen the wrong product owner.  Maybe the Product Owner can sit in the team room for part of the day.

“Our project team is scattered around the globe.”  Don’t do that.  While it’s possible for people scattered around the globe to work together, it’s much harder.  The odds of making that work while also making an Agile transition are slim to none.  If you must do distributed projects, set up a collocated team at each location and minimize the working dependencies between the teams.

“We don’t have a space that supports that.”  Find or make one.  Move furniture.  Take down cube walls.  Set up temporary or movable partitions.  If the furniture arrangement is more important than the project, consider canceling the project.

Visible Progress

In order to see whether or not we’re headed toward our goals, we need visibility into the progress.  Usually, this boils down to the questions “Are we going to get everything done?” and “Are we going to get done in time?”  If the answer to one or more of these questions is “no” then we can make adjustments to how we’re doing things, how much (and which things) we expect to get done, and what time we expect to have them done.  We can subdivide this visibility into two simple practices: taking baby steps and getting things done.

Baby Steps

Everything we do, from releasing interim versions down to validating the code we write, we should do in small steps.  Working in small steps gives us a much finer-grained view of the progress.  It lets us view the initial trends sooner.  It lets us view changes in the trends sooner.  It gives us more opportunities to make corrections or course changes.  It gives us more practice and comparing where we’re going with where we want to go, so we get better at doing that.  It requires less work before we see that we’re doing something wrong, or doing the wrong thing, therefore there is less work to be thrown away and redone.

Done

There’s little point in measuring something as progress unless we know that it actually contributes toward reaching our goal.  Measuring amount of work done doesn’t tell us that.  Consider this scene from the movie, Captain Ron:

Captain Ron: We should be okay. ‘Cause I know we’re near land.
Martin Harvey: Great, Cap. Great. Ya hear that? We’re almost there. Explain to the kids how you know that, Captain Ron. Someone translate for General Armando.
Captain Ron: Alright, now stay with me: When we left, we had just enough fuel to make it to San Juan. And we are out of fuel.

The gap in that logic is immediately obvious, but plan-driven projects attempt the equivalent all the time. We must measure relative to the goal, not relative to the path we’ve taken.

It’s important that we measure functional slices. It’s often tempting to measure tasks that have been accomplished. Sometimes, however, these tasks turn out to be unnecessary, and they don’t contribute to accomplishing the goal.  Sometimes, while they look right in isolation, they turn out to have flaws when we look at the bigger picture.  Sometimes they don’t quite meet with other tasks, and there is a gap to be filled between the tasks.  Such a gap in unknown undoneness.

We need ways of seeing progress that won’t like to us about how much progress we’ve made, or how much is left to do.  We want to measure functional slices that go all the way through the system.  It’s easy to neglect some of the things that people think of “someone else’s responsibility” after the system is “complete.”  These things might include an installation procedure, or deployment to a different computing environment.  Sometimes people neglect something so basic as testing that the system works.

We want to see functional progress–something we can demonstrate and test, something we know is desirable.  Expending the amount allotted is not such an indication.  Getting most of the way to the goal is no guarantee that we’ll get the rest of the way there–particularly when the remaining part is fundamentally different than what we’ve been doing.  We want to always, or at least at frequent intervals, be able to stop and have something that can be used, even if incomplete.

Putting these together can be difficult for a team making a transition to Agile.  It’s hard enough to get everything working, but much more so when you’re having to do that all the time.

Fortunately there are a lot of well-known engineering practices to support combining baby steps with getting to done at each step.  I’m starting with the assumption that the team is already capable of creating working software using whatever techniques they already know.  Eventually they’ll need to learn other practices to support this new way of working, and even to get better in general.

Continuous Improvement

Being able to work as a team and measure progress in a visible manner is only the start.  At first, we’ll do these things in a rather rough manner.  As the system grows in size and complexity, that rough manner won’t sustain forward progress.  We’ve got to get better in order to keep moving.

And there’s no limit to how good we can get.  No matter how practiced we are, there’s further improvement we can make.  If we conscientiously practice our techniques, we’ll see places where we can improve them.  We can then practice those improvements, so they become a part of our routine, and we do them even when distracted by the latest disaster.  When things go wrong, it’s no time to ease off on the practices that make us more effective.

As a team, we need to take stock from time to time to see the longer term trends, both good and bad, and the issues that only become visible in retrospect.  Holding retrospectives at various tempos–each iteration, each quarter, each release–will give us various views into what we’re doing, and result in different insights.  We must use these insights to plan ways in which to improve in the future.

From these starting points of teamwork and visible progress, and proceeding with a program of continuous improvement, we can learn all of the practices that support Agile development.

I’ll start with the assumption that you have a list of features you want to add to an application.  Some of the things you want to add may not be properly called features–they might be bug fixes, for example.  And the application might be brand-new, with zero functionality so far.  That’s OK, we can handle cases like that.  Let’s walk through how I do this…Here we see a burnup chart showing the development of the first feature of a project. This “Feature 1″ took the team 4 iterations to complete.

Now we want to develop “Feature 2.”  Is it about the same size as Feature 1? Bigger? Smaller? It’s really hard to say, isn’t it?

We could head down the path of precision estimates, looking at the detail of the work to implement Feature 1 and the imagined detail of the work to implement Feature 2.  We could measure the person-hours spent on Feature 1, and apply adjustments for sick day, holidays, planned hiring, and a myriad of other factors.  I find that such an approach not only doesn’t help me answer the questions I have, it distracts me from them.

Instead, I like to estimate features in “T-shirt sizes.” A simple range of small, medium, large, and extra-large is “close enough.”

When we’re just starting out on a new project, we don’t have enough information to make wise choices. So let’s make quick ones.  I’m going to call Feature 1 a “medium” feature.  Given the lack of detail about Feature 2, let’s call it “medium” also.

So we project another increment of work, the same size, accomplished at the same rate. Surprise, surprise, surprise! We project it will take another 4 iterations.  We didn’t need a burnup chart to tell us that.

Pessimism

It’s also likely that we don’t really believe this projection. Sure, it’s the best information we have at the moment, given that we know so little, but it seems prudent to explore the “what ifs” a little.  What if the feature is really 50% bigger?  What if the team is slower this time around?

Yikes! Now we’re looking at 10 iterations as a pessimistic estimate.

Optimism and the Zone of Probability

What if the Feature 2 turns out to be smaller than Feature 1? And the team is more productive because they’ve got some momentum as a team?

Our most optimistic estimate suggests that we’ll only take 2 iterations to implement Feature 2. By extending both our feature size and our team velocity estimates, we see the bounds of the Zone of Probability.

A range of 2 iterations to 10 iterations is a pretty wide variation. We’ve got such a large variation because our uncertainties are large with regard to both the size of the feature and the capacity of the team.  We have these large uncertainties because we’re extrapolating from a single data point–the time it took this team to produce Feature 1.

In time, we’ll have more data and can reduce the range of our uncertainty.  (Or the data will show that we really are that uncertain in our delivery.  Delivering at a more reliable pace is a topic for another day.)  If you want more predictability, sooner, then work in smaller chunks.  If the features are smaller, then the picture comes into focus much more quickly.

For now, I’ll leave it as an exercise for the reader

• how to handle Feature 3 and beyond
• how to handle features of different sizes
• how to sort a large stack of planned features into buckets for different sizes
• how to handle uncertainty in size when projecting further into the future

and other such issues.  If you have any questions, don’t hesitate to ask.

As is often the case, we must back up and take a larger systemic view to see further.  Once upon a time, people borrowed money to buy a house, paid it back over time, and ultimately the bank was able to lend that money to someone else.  With the creation of the FNMA (Fannie Mae) in 1938, the income streams of those mortgages being repaid were converted to bonds, so that they could be sold to other investors and the banks to re-lend their money more frequently.  This allowed many more people to afford houses.  In the 1970s, private banks got into the business of creating their own bonds based on debt repayment streams.

Nothing ever stands still, of course.  People continued to look for new wrinkles on these themes to allow them to expand the business, or to increase the profit on the business they had.  Some of these investment vehicles got very complicated, intended only for professional bankers who could understand and evaluate them where the mass public could not.  Or, so went the pitch at the time.

As it turns out, many of those professional bankers couldn’t fully understand and evaluate these instruments, either.  And this is in spite of reams of financial reporting about the quality of the underlying mortgages, the default rates, and other things that might affect the debt repayment streams.  No one has time to read the reams of financial reporting.  Instead, they simplify it, and boil it down to a relatively few values and ratios that they do read.  These derivative indicators became proxies for a real understanding of the risks and rewards of bonds based on mortgages.  And then there were derivative financial instruments based on the bonds based on the mortgages, and they had their own proxies for the risks and rewards.  I don’t know how many layers there are to this particular onion, but I do know that, at some point, the proxy measurements diverged from the real understanding of the risks and rewards.

Where have I seen this phenomena before?

I’ve seen it in businesses that couldn’t quantify the actual value of the software systems they were building, so they substituted the cost of building them as that value.  I’ve seen it in project managers who couldn’t quantify the actual productivity of their developers, so they substituted proxy measures such as “hours worked” and “lines of code” as an indication of productivity.  I’ve seen it in project managers who couldn’t quantify the actual progress of a project, so they substituted conformance to their original plan as a proxy.  And for individual items on that plan, when they couldn’t discern the actual progress on an item, they substituted reports of “percent completion” as a proxy.

All of this makes perfect sense at the time.  There is some correlation between lines of code and productivity.  And by using proxies that are quantifiable, we can crunch the numbers and come up with a few key indicators to let us know how we’re doing on productivity, progress, and value.  And we can calculate the amount of risk we have, at least, the amount that we’ve anticipated.  We end up with a handful of indicators that make us feel on top of things and in control.

And, like in the financial industry, as long as things keep going well, these numbers seem to work for us.  But we have no way of knowing how much and in what ways our proxy measurements vary from the things that really concern us.  And we have no way of knowing what risks are not included in our numbers.  And we have no way of knowing in what ways the future might differ from our increasingly successful past.

There were those who took a systemic look at the financial industry and predicted that trouble was coming.  As the system mutates over time, it rewards behavior that varies from what we really want.  The increase in that behavior then drives further changes in the system.  It’s a lead-pipe cinch that the future will differ from the past.  But looking at proxy measures won’t tell us that.

“The prudent mariner will not rely solely on any single aid to navigation, particularly on floating aids.”  This advice used to be printed on all US nautical charts.  It’s good advice for the prudent manager, also.  Proxy measures are like floating aids to navigation.  They only give an approximate position, as they drift around their anchor point.  And sometimes, unseen by us, the anchors themselves drift from the known location where we set them.  As we reward lines of code or hours worked, these measures drift further and further from a representation of productivity.  As we measure conformance to plan, then that conformance becomes more important and accomplishing the goals that the plan was created to accomplish becomes less immediate.  That conformance then becomes a poor proxy for accomplishing our goals.

So, look around.  Find some other aids to know where you are, and where you’re heading.  Don’t wait until it’s too late to prevent disaster.

Don’t get me wrong.  I’m all in favor of an Agile Team using something like the Nokia Test (or, better, Nationwide’s “Agile Tea Leaves”) as part of a self-examination and retrospection.  But any sort of discussion of conformance to practices is way too low-level for the executive team, or even middle management, of an organization.  Agile is the tool, not the goal.  The goal is to accomplish the things the organization wants to do.  Agile is a tool to allow the organization to accomplish its goals more reliably and in a more timely fashion.

With this in mind, I thought about what a high-level manager wants from the organization’s projects and the process used to develop them.  How can this manager tell if the development staff is doing a good job, or could be doing better?  I came up with this Do-It-Yourself Project and Process Evaluation Kit that such a manager can use, no matter what process the organization uses for development.  I think it will also be useful for Project Managers who need to report upwards.  Report in these terms, not in the details of the development process.

And here it is:

The DIY Project Process Evaluation Kit

• How long does it take an idea to be realized and deployed?  A year?  A month?  A week?
• What keeps it from being shorter? Budget cycles? Serial processes? Too much work? Bottlenecks?
• How do you tell that you’re working on today’s highest priority items?
• How do you verify that the systems you’re developing are solving the intended problem? How quickly do you know?
• How do you measure progress of system development?  Is this a measure of something you actually want, or is it a surrogate measure?  Is it a reliable progress indicator or does it hide surprises?

Will these questions help you?  Are there others you’d want to add?

I hope you find these questions useful for years into the future.  To that end, I’ve printed them up on a card that can fit in your wallet.  Look me up at Agile 2009 and I’ll be glad to give you one.  Or send me your address and I’ll mail it out to you.

Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction that’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by–the first possible, optimistic date.

I like that characterization of the predicted date.  Another characterization, usually true of serial lifeycles, is that the predicted delivery date is the first day of schedule slip.  I’ve seen many serial projects get almost to that date before they first admit that they’re in trouble.

There was a comment from Pawel Brodzinski to Johanna’s post saying,

About predictability I’d say it doesn’t have to be false. Waterfall project which was properly planned and is properly managed should end around deadline and should deliver functionalities specified in requirements.

He’s right.  It doesn’t have to be false.  It usually is, however, because a serial lifecycle doesn’t give you any tools to manage schedule risk.  It only gives a prediction.  Experienced managers will guess the amount of padding to add to the schedule to give themselves a chance of meeting it.  Cautious but less-experienced managers will add a lot of padding, to increase their chances.  Of course, a development team working to meet a highly padded schedule may be so over-confident that they slow down to match, and then still miss the schedule if something unexpected happens.

In Pawel’s own blog post, he quotes Steve McConnell who describes an XP software development project that failed to produce a salable product because Customer (a.k.a. Product Owner, in Scrum terms) didn’t have a vision for a salable product.  For some reason, probably ignorance about Agile Software Development methods, Steve lays this failure on the development team creating one iteration at a time.  He apparently missed the practice of release planning.  When he says they “did it by the book,” they obviously didn’t use the book Planning Extreme Programming, which was published only a year after the first edition of Extreme Programming Explained: Embrace Change. Surely in two years the team could have read a second book.

Back to the point about Agility and Predictability, Steve says,

True agility–which means adopting a posture that allows you to respond rapidly to changing market conditions and customer demands–conflicts with predictability. Some businesses value agility, but many businesses value predictability more than they value the ability to change direction quickly. For those businesses, becoming more Agile is a second level consideration; the first level consideration is how to become more predictable.

Here, Steve seems to make the common mistake of using the dictionary definition of “agility” instead of checking the values and principles of the Agile Manifesto.  The “Agile” of the manifesto is a brand name, of sorts, to replace the wimpy “light-weight methodology” term that was starting to be commonly used at the time.  It’s a good brand because Agile does allow you to change directions more easily.  But Agile doesn’t require you to change directions and it certainly does expect you to have a direction.

How does Agile give you a predictable schedule? By giving you early, frequent, and fine-grained feedback and allowing you to steer the project to that schedule.

Let’s take a look at the release plan created at the start of the project.  First, write story cards for all of the features you want in your product.  These cards will generally be big stories, a.k.a. epics, and you’ll want to break them into smaller stories for development.  The big stories will work just fine for release planning, though.  Estimate the size of these cards.  I prefer estimating in story points, a fictional, unitless measure.  Some people like to start with ideal engineering days.  Either way, you have to guess how many of these your devlopment team can accomplish in a short iteration.  (I recommend one or two week iteration lengths.)  Count up the story points, divide by this guess, and you’ve got the number of iterations it will take to create the software.  This plan is exactly the same as the plan created by a serial lifecycle.  It’s just a guess–one made as carefully as our experience will allow–but still a guess.

Now develop software for one iteration.  How many story points did you accomplish?  Was this different than your guess?  If so, you may want to adjust your prediction to use this value instead of the guess.  Sometimes people may want to wait for three iterations before doing so, to let the team get up to speed, but they’re put on notice at the end of the very first iteration.  That makes a pretty good prediction, don’t you think?  And you can refine your prediction at the end of each iteration.  With a serial lifecycle, you’re either stuck with your original guess, or you get nervous enough that you make a new guess.

If wishes were horses, even beggars would ride. My mother used to tell me that when I wanted something that was clearly out of reach.  Sometimes a software development team just can’t accomplish all of our wishes by the desired date.  We’ll see this as we replan our schedule at the end of each iteration.  And, unless the desires and capabilities are completely out of whack, Agile Software Development gives us the tools to meet the desired date anyway.

How can we meet the date when there’s too much to do?  We do the most important things first.  And we do things at a fine-grained level.  Instead of leaving whole features to the end, we leave “nice to have” refinements of features to the end.  And we then trim scope to fit the date.

We can do this if we’re getting each little story done-done as we go.  This includes testing, so we know it works the way we want.  And it includes automated regression tests, so we know it continues to work without getting buried by re-testing.  A serial lifecycle leaves this important feedback to the very end, when there’s little time to remedy problems that are discovered.  That late discovery leads to the lack of predictability produced by a serial lifecycle.  Agile Software Development gives you more predictability than those carefully planned-up-front project plans can provide.

Oh, and yes, it can provide the dictionary definition of agility, too, should your goals change.

Consultant George Dinwiddie from iDIA Computing suggests using a burn-down chart to track project progress.

I actually recommend a burn-up chart to track project progress, and a burn-down chart to track iteration progress.  There are specific reasons that I think a burn-up chart is superior to a burn-down for tracking over the course of a project or release. I’ve been meaning to write a long post about this, but haven’t found the time. I just wanted to correct the record, in the mean time.

The full comments of my note to Esther:

If you don’t know anything else about Agile, know that it’s largely based on using feedback to drive the work and keep things on the desired track.

The use of feedback in Agile software development is pervasive. On a project level, if you use a burn-up chart to track the progress of a project, you’ll see how the progress is converging, or not, on the goal line and can take action if necessary. That action might be to move the goal line, or to make changes in the way the software is being produced to try to speed it up. On the lowest level, using Test Driven Development allows a developer to specify the next tiny thing the software is expected to do, and then get feedback when the code meets that expectation. When a developer asks the business Customer about a feature, he gets feedback on the desired goal. When the business Customer sees the incrementally growing software, she gets feedback on how well the software is converging on the desired goal.

In every way possible, reality should be tested against what is desired. The feedback should be generated with as little delay as possible. Reducing the time between when a decision is made and when it is validated will pay off in reduced waste.

This validation comes in many different forms, at different levels, and from different viewpoints. This is much more powerful than a single validation that must be perfect to be valuable.

Software’s nature is to be invisible, unless we work to make it visible…. During a construction project, we can see the building rising; but during a software project, all we may be able to see is a programmer staring at a screen.

This got me to thinking, as Jerry’s writing generally does. I recall reading sometime in the early 1980s, in some trade magazine, something to the effect that

You can see the progress of an electronic hardware project by the stack of revised schematics being generated. When you see a growing stack of program listings for the associated hardware, however, you can bet the project is stuck.

You cannot view the progress being made in a software development project by looking at the effort being expended. The progress can only be determined by the output achieved. And I can think of no better output to measure than Running Tested Features. That is, the software does what you, and the Customer, want–in increasing amounts–in a way that is measurable.

This is the purpose of “Acceptance Tests” in Agile Software Development. They don’t, as testing professionals often point out, prove that the software is completely correct. They don’t even force the Customer to accept the software and release it. But they do provide a measure of the progress in producing software behavior that is desired. They make the software visible.  Then you can see the progress.