Oops! There are no photos beyond last March. I felt sick to my stomach. That’s a lot of family memories to evaporated. Whew! The program we’ve been using to download the cameras also makes a backup copy local to the machine used to download. I’ve got all the pictures back on the photo server, and now just have to sort them into directories again.

But first, I need to fix the backup script. Why didn’t it warn me when it started to fail?

I copied a version on a different fileserver to that machine and edited it for the different source and destinations. It’s a simple shell script that mounts the USB drive, runs rsync to duplicate the data, and then unmounts the USB drive. I’d run into a problem once before where the drive wasn’t getting mounted properly, so I’d added some script to detect that and email me using msmtp if it failed. That only worked for mount errors, though, not for rsync errors.

As I hacked in detection and notification of rsync errors, I felt ill at ease. I was duplicating some of the script to send emails. The script was getting harder to read. The script was increasingly inconvenient to test. And I was nervous about introducing new errors.

I started practicing Test Driven Development a decade ago. It has become second-nature to me to test-drive the code I write. Why was this code just hacked together? Mostly because I hadn’t been thinking of it as code. It was just a script. At first, it just replicated the commands I typed on the command-line. I put those into a script to make it easy to run, and then to automate running it via the <del>chron</del> cron daemon. When I replicated it to another machine, I extracted the paths to variables to make it easier to change the differences. When it had failed to mount a drive, I’d added a check for that and a line to send me an email. That line surely crossed the border between “a file of commands” to “a program,” but I didn’t notice it at the time. Or, if I did notice it, I didn’t pay attention to it. After all, I don’t generally program in bash scripts and haven’t developed any rigor for doing so. It’s those “little” changes that “can’t possibly” hurt that bite you the hardest.

The script now “seems to be working,” but I’m not satisfied. Wouldn’t it be nice to get advance notice when the disk is getting close to full, rather than waiting until it is?

I now know I’m programming in sh, not just collecting a bunch of command-lines from my .history file. Adding the email notification of rsync errors was harder than I expected due to tiny errors made in an unfamiliar programming environment. In addition to being hard, it just felt “dirty.”

A little googling lead me to shunit2. After a little difficulty creating a tiny virtual disk under control of the tests, I quickly had a function that extracted the % full output using the du command and returned it as a number. Great! Now I can use that number to provide an early warning. And working test-driven is teaching me better shell scripting habits.

I’ve still got work to do, pulling the existing script into tested functions, but already I feel better. I’m on my way to a reliable and maintainable script.

Some months back, I noticed that their website had become bandwidth greedy with javascript doodads. This made it painfully slow on many hotel internet connections. They seem to have backed off from that a bit, but have now broken it in a way that prevents me from buying the ticket I want. (In addition, when I call the “Southwest Airlines Customer Representative for assistance” as prompted on the website, I find they no longer have enough to handle the call volume. I wonder if they’ve reduced the support, or if the call volume has increased, or both.)  There’s a lesson here about considering all of the important user stories when implementing new functionality, so it bears describing.

I went to the Southwest web site to purchase my ticket to Salt Lake City for the Agile2011 Conference. I took a look at the available flights on the appropriate travel dates. Then I remembered that I have an unused travel award, so I went to check if those dates were available, even at this late date. Hooray, they were! Boo hiss, the flights I want were not. Oh, well, it serves me right for putting this off so long.

So, I went back to buy the tickets with money. But when I search for the flights, instead of showing me the flights for purchase, it shows me the dates available for using my travel awards. I sign out of my account and try again. Now it gives me an error: “Oops! We are currently unable to complete your request due to an undefined error.” I try deleting cookies. I try closing the browser and re-opening it. No dice. Still, if I’m logged into the account it gives me the travel award availability dates, and if I’m logged out it gives me an “undefined error.”

I also notice that even after deleting cookies and restarting the browser, when I go to search for a flight it remembers my airport and date selections. This means that they’re keeping state on the server side, probably associated with my IP address (since I’ve logged out and deleted client side session data), and there’s no way I can find to reset this state.

In their attempt to be helpful, they’ve neglected to consider many common user scenarios. The Southwest website has long maintained enough state that you couldn’t do multiple searches in parallel to compare them and then select the one you wanted. But you could, in my experience, restart the search once you figured out which you wanted. Now there’s no mechanism I can find (and I’ve been struggling with this for over an hour) to take a purchase path that involves changing your mind and backtracking.

Am I the only indecisive customer? Or has Southwest forgotten the variability in the ways that humans approach things, and coded their website for a robotic “customer unit” that follows the one expected scenario?

More importantly, what do you and your organization do?

• A list of features to be built
• A release plan or timeline for those features
• Setting up development infrastructure such as version control or continuous integration servers
• Studying or practicing skills in new technologies they expect to use
• … and other management, infrastructure, and technical endeavors.

They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.  The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.

And we’ll have burned an iteration without producing any working software that tests our decisions.

My advice is to borrow an idea from Lean and look at the situation from the output point of view.  Ask yourself, “what would it take to start delivering?”

The initial backlog really only needs to be one item in order to start delivering.  If you’ve got too many unknowns, then just start with one item.  Get the business stakeholders, the programmers, the testers, and anyone else who needs to be in on the discussion (User Experience? Ops?) to talks about it.  (I call this a meeting of the Three Amigos.)  What is the one obvious thing that needs to be done? (Hint: it’s not “login.” Start with the main purpose of the system.) I can’t imagine a situation where a project is started without any ideas at all.

Take that one thing, and slice it into thinner slices.  Decide on the examples that represent acceptance of those slices.  Some of the slices will have questions that can’t be answered.  Put those aside for the moment.  Choose the most central slice that travels through the entire concept from end to end, or as close to that as possible.  Estimate that as one team-iteration.  (Estimates don’t have to be “right.” They’re just estimates.)  Start building it.

Learn the necessary skills in the technology while accomplishing real work. Learn the parts that aid building the system, rather than developing the system according to some framework. When you don’t know how to accomplish something, or you think multiple approaches might work, do minimalistic spikes to give the information needed to make a decision.

Along the way, start slowly building your development infrastructure. Set up a local code repository. You can always migrate the code to an “official corporate” repository later.  Right now, there’s not much code. Set up a simple build-and-test script so that everyone builds in the same fashion. You can always add other build targets later. If you’ve got time, you can set up a Continuous Integration server. Otherwise, just do it manually. Checkout & build into a clean workspace. Do what’s needed to run the code so that you can show it working.

If you can’t accomplish this slice in one iteration, it’s probably not thin enough. Or, maybe you haven’t yet solved an essential technical problem. Or the goal isn’t yet clear enough. Figure out what impediment is most in your way, address that, and try again.

More likely, you’ll get this slice done in less than a iteration length. If you get this slice done before the end of the iteration, then pull in another slice.  Estimate this as “the rest of the iteration.”  Repeat as needed.  As long as you’ve gotten one slice done, you’ve got a potentially deliverable product increment.

Yes, there will still be development infrastructure to be developed. There’s no particular rush to get that done. Just keep improving it, so that it helps you get more done. Yes, there will still be technical skills to be developed. That should always be the case. Just keep experimenting and pushing your limits.

Yes, there will still be features to be added to the backlog, refined, prioritized, split into stories, and prioritized again. This should continue throughout the project. It’s part of the “steering” process. Yes, there will still be a need for projections to estimate when functionality can be released, or how much functionality can be released by a certain date. When you think you’ve got enough information about what needs to be done, then consider the initial release plan.  By then you’ll also have accumulated a little information about how fast things get done.

There will still be a lot of holes in your knowledge of what needs to be done and how fast things get done.  Don’t trust your initial release plan to be “right.”  It’s just a stick in the sand to help you judge how things are going.  Keep planning, and move the stick as needed. And as time passes, you’ll have a better and better indication of how fast the system gets developed. Even when you think the Release Plan is complete, it needs to be continually reviewed and adjusted. Since it’s never done until the release, there’s no particular hurry for a certain level of completeness.

This sort of beginning is very like the Hudson Bay Start that Johanna Rothman describes in her book, Manage It (pp. 52-53).

The Hudson Bay Start approach was originated by the Hudson Bay Company in the 1600-1700s in northeastern Canada. The Hudson Bay Company outfitted fur traders. To make sure the traders hadn’t forgotten anything they needed, they left Hudson Bay and camped just a few miles away. By making camp just a few miles away, the traders ensured they hadn’t forgotten any tools or supplies–before they abandoned civilization. With just a short start to their journey, they had a better idea about their ability to endure the winter.

There’s really no reason (other than “that’s not the way we do things around here”) that this can’t work for the start of any team/project. It’s a great way of learning the right stuff for the current situation while also making a bit of progress. I use this technique in my Agile in Six Months transition plan.

No, to me, code is inventory.  It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.

I’m not sure I can see the analogy of code that’s in production to inventory.  Code that hasn’t shipped, yes.

But all code is a liability, I think.  When code is in production, then it’s offset by the asset that is the functionality.  Whether or not the net is positive is another question.

There’s no doubt to me that code, whether in production or not, has carrying costs that are larger than generally realized.  Perhaps it’s a depreciating capital expense?

Carrying costs are larger than we think. There’s competitive advantage for companies that recognize this.

It’s something that takes up space.  It takes maintenance.  It takes attention.  It does have a substantial cost of ownership–larger than we think.

The analogies may be failing me, but I think Michael’s sentiment is correct.

Software-dependent businesses can only evolve as fast as their ability to write and evolve their software allows them to.

I think this is not only true, but an incredible opportunity for businesses that understand that.  Let’s face it: most businesses spend an awful lot of time for a very meager increase in systems capability.  Companies that do better than average can shoot to the top.  Look at the spectacular successes of some of the relatively young internet companies, for examples.

As Corey Haines points out, we, as an industry, know how to produce relatively bug-free software in a steady stream, delivering needed functionality early and often to businesses starved for capability. But, for the most part, the IT industry doesn’t do so.

Jason’s proposals for addressing this gap fall short, in my opinion. The first, that getting more kids to choose software development as a career, seems odd to me.  I don’t think we’ve got a lack of people. I think we’ve got a lack of people who know and practice the techniques that we, as an industry, have found to work.  The second, getting more practioners to want to do better, addresses this lack.  I’m all in favor of this, but I don’t think it, alone, will make much of a dent in the overall situation.

Even if we’ve got excellent software craftsmen, if the quality isn’t demonstrably valued by their organization, they’re most likely to either get demoralized and slack off their efforts, or leave that organization for greener pastures.  So, while I do think that most software developers need to improve their skills (and continue to do so over their entire career), I don’t think that will drive improvement in those organizations that need it most.

Organizations, like most systems composed of people, tend to develop amazingly stable patterns of operation.  These patterns persist through reorganizations and changes in personnel.  The reason they persist, is that there is an informal network of effects that regulate the system, putting and keeping it in its current state.  This stability doesn’t happen without forces reinforcing the behavioral patterns and inhibiting other behavioral patterns.

The study of these patterns and the forces that reinforce them is called Systems Thinking.  You can read more about it in Peter Senge’s The Fifth Discipline, Jerry Weinberg’s Quality Software Management: Systems Thinking, or An Introduction to General Systems Thinking, among others.

A fundamental lesson I’ve learned from Systems Thinking is that when some behavior persists over time, there’s something that’s rewarding it in some fashion (perhaps unintentionally).  If the behavior doesn’t make sense to me, or seems counterproductive, then I often find it more productive to look for what that reward might be rather than plead harder for a different behavior.

In this case, I think that large organizations operate in ways that support doing a slapdash job of software development.  I’ve seen many organizations that primarily reward behavior that’s irrelevant to helping them evolve more rapidly.  That and simple neglect of the behavior that would aid being more nimble in the marketplace are enough to produce the stability of the systems I see.

Many of these instances of rewarding irrelevant behavior come down to focusing on costs (which are easy to quantify) at the expense of value (which is much harder to quantify).  To promote the development of higher quality, more valuable software, I think we need to make that value more visible to the decision-makers.  They’re not stupid, after all.  They’re just working with the information they have.

What other drivers do you see behind the vast sea of mediocre software production?

We’ve got an excellent plumber.  He’s not producing art, but he does a neat job.  The pipes run straight and are well supported.  When he’s repairing old work, he may cut out a section that’s been patched numerous times and replace it with new, more reliable, work.  When he has to cut holes in the wall to reach old plumbing, he repairs those holes so they work isn’t obvious.

The electrician who wired our new house is a different matter.  He took shortcuts as he saw fit.  Here’s the brand new electrical installation in our new house.  He sized the box with absolutely no room for expansion, even though he knew that we’d want to add more outlets in the unfinished basement.  The new box was actually smaller than the one in the preceding house that we demolished.  Our insistence that this was not acceptable was rejected, but his neglecting to allow for one circuit caused him to expand the installation.  So he slapped up a sub-panel.  Notice the care with which he mounted it partially on the wooden support and partially hanging in mid-air.  Notice how some wires go straight up into the ceiling area, some go through the board, and some go around the edge of the board.  It’s going to be a major chore to do any further work in this area.  That’s kept me from making the adjacent workshop area easy to use.  Moving forward is going to require major rework.

Dan is right that we’d rather our systems be built by craftsmen.  This was no day-jobber, though.  This electrician owns his own business (as does our plumber).  He’s certified as a master electrician.  That means he went through apprenticeship and testing.  The electrical panels are plastered with stickers from the building inspector saying that the installation meets the requirements of the electrical code.  Both the electrician, and his work, are certified by bodies empowered by law.

And yet he did crappy work that did not satisfy his customer.  And we, as his customer, will pay the price for his crappy work every time we go to add or modify anything in this area.

We, as customers, cannot rely on certifications to reassure us.  Even referrals can let us down.  The builder (who did an excellent job in most ways) provided good to excellent sub-contractors except for this one.  I think the builder has finally given up on this sub-contractor, but it’s too late to help us.

In the end, there’s no way to eliminate shoddy workmanship.  But we can promote craftsmanship and the people who practice it.  We can help those who are willing to learn and practice.  It’s a messy world and we can’t fix that.  But we must do what we can, or it only gets worse.

I didn’t “sign” the Manifesto for Software Craftsmanship because I thought it was particularly well written, though.  I signed it because I support the intent (as I perceive it, and which Ade Oshineye defends) behind that manifesto.  Writing software is a craft, and there are far too many people who don’t treat it that way.

Some of the people who treat software as something other than a craft go the route that Dan North fears, indulging in adding baroque complexity for their own sense of aesthetics.  That, despite Dan’s suggestion, is not craft, but art.

Yes, a craft implies imbuing a utilitarian product with a certain beauty, but that beauty is not necessarily either “fancy decorative stuff” or separate from the value of the product.  In Dan’s example of a cathedral, the ornamentation and grace is part of the functional aspect of the product.  A cathedral is not merely a glorified hut to keep the rain off.  It is designed to lift peoples’ spirit and guide them to think of things larger and grander than their everyday life.  This is appropriate design for the purpose, and part of “amazing your customers.”

The utilitarian beauty of a craftsman is not all cathedrals, however.  Look at the design of Shaker furniture.  It is elegant in its spareness and utility.  It is designed to delight the user without any ornamentation.  This is another way that craft is expressed.

At the other extreme are the programmers who develop systems which result in “the clanking of information as it rattles from one poorly-implemented system to another, through ill-conceived interfaces.”  These are the poorly-skilled (in practice, at least) programmers for whom the Software Craftsmanship movement is intended to help.  In many cases, this is a result of a lack of knowledge, a lack of practice, or both.

In the end of his rambling post, it appears that Dan’s real concern is providing reassurance that systems “were being built by master craftsmen rather than day jobbers.”  It’s the certification issue, again.  Certification does not work.

Certification does not provide such reassurance.  I think a better approach is to increase the general level and availability of craftsmanship in the software industry.  True craftsmanship is often not immediately visible to the customer, but the lack of it becomes visible when systems take a long time to build or modify, and when they exhibit a lot of quirks in usage.

My expectation is that, while programmers may seek to be craftsmen for their own sense of pride, customers will seek craftsmen programmers for the long-term financial rewards.  That’s where quality pays.

(Note: the use of the word “craftsman” is not a reference to any gender.)

Why did he make this statement?

He went on to explain, that the design of a dome house depended on a single skin being perfect waterproofing technology.  Traditional houses, by comparison, have multiple imperfect layers.  There are overlapping shingles, which keep most of the water out.  Below that there’s a layer of tar paper, which keeps out most of what reaches it.  Then there’s the plywood sheathing, which blocks or absorbs most of what penetrates the tar paper.  Then the attic insulation….

No single layer of this system has to be perfect.

Software testing works the same way.  If you depend on one method of testing, you’re going to leak bugs into production.

If you do unit testing (or micro-testing, as Mike “GeePaw” Hill calls it) of small chunks of code at a low level, you’ll catch most of the coding mistakes.  Then, if you do small scale integration tests of the code that talks to other systems (such as the database), you’ll catch most of the remaining ones.  Then higher level integration or acceptance tests that check that the whole system is wired together right will catch most of those that have escaped so far.  Then exploratory testing….

Any competent network security professional will tell you that you can’t protect your network from malicious people by relying on perimeter security.  You have to bake security into other levels of access, too.

Again, the same is true of testing to protect your application from bugs.

As Lisa says,

I can’t tell you the one right way to test and develop software….  The one right way for your team to code and test will continually evolve over the years. In fact, I’m sorry to tell you that you’ll never find the one right way; it’s a moving target, but you’ll get closer and closer to it.

This is an incredibly important point!  There may be many “wrong” ways—wrong in that they fail to achieve your objectives—but there is no “right way.”  So I’m happy that Jim and his teams are able to achieve the results they want.  I’m not saying they’re doing it wrong.

At the same time, I’ve seen teams struggle with the increasing burden of acceptance testing and the divergence of understanding between the Customer, the Developers, and the Testers.  And so I continue to explore ways to alleviate that struggle.

Jim describes how the teams discuss concrete examples with the customer.  They then automate those examples (or not) in their own unit and integration tests.  Jim reports that these tests give the programmers confidence that the system is working as desired.  For the customer’s confidence, Jim reports relying on “a reliable track record of shipping defect-free software.”

Jim’s argument is that the customer won’t trust the test results before trusting the team.  This is true.  If the customer thinks the developers will fake the test results, then it doesn’t matter how the tests are expressed; you’ve got a serious problem.

I’ve not experienced this level of distrust.  Instead, I’ve experienced customer’s who trust that the developers are working in good faith, but still don’t trust that the developers will ship defect-free software.  And perhaps the developers won’t ship defect-free software.  They’re fallible, just like the rest of us humans.  Maybe they misunderstood the customer’s example.  Or they made an error converting it to code.  Or they didn’t automate that example because they thought it was the same as another that they did automate. Or…

Mistakes happen.  Miscommunication happens.  It’s great that Jim’s developers have that zero bugs attitude, but the customer has the right and obligation to participate in achieving zero bugs.  It can be condescending to take all the responsibility for correctness.

Yes, the customer gets to review the completed software, but we can detect misunderstandings sooner if the customer can read the acceptance tests.  Yes, the developers may produce defect-free software, but miss a test case such that nobody notices right away when a defect is inserted into this feature later.  I want to enable the customer reading the test and saying “Yes, that’s what I meant.”  I want to enable the customer saying, “I’ve thought about another case we don’t have covered.”  Or “We’re changing our business rules and this example is no longer correct.”  Or anything else that’s appropriate.  I want the customer to share that zero bugs attitude.

But is this practice essential?  Obviously not, as Jim and his teams are successful without it.  For many teams transitioning to agile practices, they’ve probably got too many other, more fundamental, practices to learn that they don’t have the energy to tackle this one yet.

Is this practice too expensive in terms of effort?  Maybe.  A lot of people are working on making it less expensive.  If you don’t make it an integral part of the conversations when you first start discussing the story, then it’s likely to seem too expensive.  Then it’s like writing unit tests after the code rather than doing TDD.  To make it work, I think you need to make the customer examples flow from the initial conversation through signaling “done” for the developer.  You’ve got to work at making them maintainable, just like the code in the system you’re delivering.

This is just one small practice in a forest of useful practices.  The forest can survive without any single one.  We can almost always find ways to compensate for things we’re not doing.  That’s a double-edged sword, however.  It can also allow us to fritter away our advantages until we’re working in the same old way we’ve always done.  It can blind us to some of the process improvements we could make.  Jim’s “fix the process description” is

Every escaped defect, whether found in exploratory testing or found by end-users, is a indication of a flaw in the process. When we find one, we fix our process.

The first thing is to analyze the defect, write a test that reproduces it, and fix it. While we’re fixing it, we look at the design of the code and see if it needs improvement, too.

Next, we conduct Root-Cause Analysis. We ask ourselves, “What about our process allowed this defect to escape?” We continue asking “why” until we get to the root cause. Once we find it, we make changes to prevent that entire category of defects from happening again.

Note that “fix the process” could include adding a process of creating Customer Readable Automated Acceptance Tests.  They’re are a tool that I want to keep in my toolbox.

Certainly when something’s not giving you the results you want, it’s time to make a change.  That change can be to drop the practice that’s not working for you.  It can also be changing the way you go about the practice, or changing what you want to accomplish.  Or, instead of changing, maybe the word “refining” is a better fit.

In my experience, teams that don’t do automated acceptance testing quickly get to a point where adding new features goes slower and slower, just because it takes longer and longer to test all of the functionality.  Sometimes they start trying to figure out which functionality they need to retest, and which “couldn’t possibly be broken by this change.”  This starts down a very slippery slope.  As Elisabeth Hendrickson says,

If the customer has an expectation, they have expressed that expectation, they have every reason to believe you have already fulfilled that expectation, they don’t want to have to manually go re-verify that you have actually done the thing that you said you did before.

Is that so much to expect?

In one of Jerry Weinberg’s books [Quality Software Management: Vol 2, First-Order Measurement, pp. 156-158], he talks about how a one-line change is more likely to introduce a defect than a larger one.  This seems counter-intuitive, until you consider how people drop their guard when they think they’re making a trivial change.  They don’t check everything as completely.  When someone doesn’t check some aspect because “it couldn’t possibly be affected” by this change, they leave the door wide open for Murphy to demonstrate his law.

Given that I’m convinced things need to be retested, and that the shorter the iteration the more frequently they need to be retested, I’m not willing to give up on automated tests.  That leaves me looking at what I want to accomplish and how I want to practice it.

Jim describes two problems with automated acceptance tests.

These two problems–that customers don’t participate, which eliminates the purpose of acceptance testing, and that they create a significant maintenance burden, means that acceptance testing isn’t worth the cost.

About the first problem, lack of customer participation, he says,

The planned benefit of those tools is that the customers are supposed to write the examples themselves, thus improving communication between customers and programmers. In practice, I found that customers (a) weren’t interested in doing that, and (b) often couldn’t understand and didn’t trust tests that were written by others. Typically, responsibility for the tests gets handed off to testers, which defeats the whole point.

I also have found that customers are not interested in writing tests, themselves.  I don’t blame them for that.  Nor do I think they would, in general, do a very good job by themselves.  Sending testers (or developers, for that matter) off by themselves to translate discussions into test examples isn’t any better.  They have the same problems that face the customer, plus the problem of the customer not trusting tests they don’t understand.

I don’t, however, think that’s the way it has to be.

I’m still working on demonstrating long term results, but I’ve had some success using automatable examples as a tool to enhance the conversation between the customer, the tester, and the developer.  Not to replace the conversation, or to send one person off to write tests, but to add precision to the agreement about what needs to be accomplished.  The goal is for the customer to look at the test and say “Yes, that’s what I want.”

Once we’ve got that, there are lots of tools available now, and getting better all the time, to help us turn that automatable example into an automated one.  Yes, maintenance is still hard.  Dale Emery has an excellent article on this topic.  We, as an industry, have far to go getting this difficulty under control.  I say, let’s work on it.

If we approach the development of the examples with the customer and in the terms of the customer, then we’ve accomplished the hardest part.  It’s worth spending the extra effort to put these examples to work preventing defects rather than finding them after the fact.

Here’s a little cheat sheet.  Forget all the details and the various ways you can implement Agile for the moment.  Let’s simplify the picture.  There are just three essential legs that your Agile project needs to stand.  Get those in place, and you’ll do OK.  Keep improving all three, and you’ll do fantastically!

Arranging the work.

Know what is the goal.  Everybody should know this.  The “things to be done” should be fed smoothly to the development team.  Iteration cycles should respect the capacity of the team.  So should release cycles.  Doing these cycles smoothly will allow the team to maximize their capacity better than pushing for higher productivity.  Delay making decisions until they’re really needed, and make use of what you learn in the mean time.  Get the flow going and measure progress in real terms—working software.

Doing the work.

Working in iterations, alone, won’t get the project done.  The team has to do a competent job at doing the work.  If they had trouble delivering before, then better focus on shorter term goals may help, but you still have to work at it.  In addition, the sharp focus of short iterations and measuring working software makes it harder to sweep problems under the rug.  The team could look worse until they get a handle on things.  Set a high standard with your definition of done and keep to it.  This is the real capacity of the team.  Work to improve skills to increase the capacity.  Work to eliminate unnecessary work.

Working together.

An incredible amount of productivity improvements of an Agile team comes from the synergy of working effectively together.  Build a team, a real gelled team, not just a work group assigned to a project.  Support each other.  Help each other grow.  Leave no team member behind.  Solve problems together.  Respect each other.  Respect the differences, the special abilities, the varying perspectives.  These things give the team strength and resilience.

These three legs are enough to stand up a new Agile project.  Use these three categories to organize all those details we put aside at the start of this post.  Use those details to help you steady these three legs.  Experiment and practice until you feel you can succeed at each of these three aspects of your project.  And then keep improving.  Keep looking for things you can do better.  Keep re-evaluating.

It’s really that simple.  I won’t promise that it’s easy.