Trial-and-error with a feedback cycle

Don’t EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle.

That’s giving your intelligence much too much credit.–Linus Torvalds

trial and error

A common mistake when trying to be “Agile” (or trying to appear to be Agile without actually being Agile) is to shorten milestones while still maintaining the idea that we have a plan for every milestone done up at the beginning of the project and we consider changing the plan to be a management failure.

The whole point of trial and error is to make our plan, but to accept the inevitability that our plan will not survive contact with reality. I was working on one project, and the first two-week cycle went badly sideways. The project manager complained that she hates missing milestones early in a project, it foreshadows all sorts of problems. She wanted to impose overtime to hit the date.

I urged restraint. If we were wrong about our velocity, or wrong about some of our technical predictions, or wrong about some of the requirements, it would be far better to adjust our expectations. The two-week cycles were a bonus because they were providing the feedback we needed to adjust our plans.

If you ignore the evidence, if you try to twist the appearance of reality to suit your plan rather than twist your plan to suit reality, the feedback is wasted.

feedback

Feedback is so critical, that even if you do everything else right, and even if you think you are gathering and responding to feedback, you can still fail. One major project management anti-pattern is called The Waterfall Trap. This is when you build software incrementally instead of iteratively.

“Increment” and “Iteration” are not synonyms. Increments are components of the finished software that do not provide value in and of themselves, like a database and its associated ORM doo-hicky. When you build an increment, what feedback do you have? Feedback about how well you are executing against your plan.

This is like deciding to march through the jungle and measuring how many steps you take per day. Are you going in the right direction? Who knows, but you know you how fast you are going, and that is worth something, isn’t it? I can tell you exactly what it is worth. At some meeting later on, when the project has been judged an expensive failure, you can prove it was a well-managed failure under your watch. Congratulations.

For feedback to really work, you must have feedback about how well the finished software delivers value to its users. The only way to do that is to deliver it to those users and get their feedback. Thus, the other approach: to build the software iteratively. This means to build things that are valuable in and of themselves, so users can judge how well they work.

An iteration is a piece of software with business value. People can touch it, try it, use it, and judge how well it does or doesn’t help the business execute. This is different in every way from an increment. I call iterations “products.” If something cannot be called a product, it probably isn’t really delivering any value.

productization

My Golden Hammer for building software iteratively is to divide it into separate products. We sit down and look at the pile of functionality on the plan and ask, “Which of these pieces could be useful things in and of themselves?”

On one project, there was a complex bit of loan eligibility reasoning that needed to be built into a database application. We decided that although the finished application would have the reasoning built into certain input screens, the reasoning could be a separate product. We imagined this thing sitting in its own screen alongside what their existing process.

There would be some double entry involved, but we knew that if we built this as a stand-alone product, it could be used in production and it could provide value. So we did. And sure enough, we got a lot of feedback from the users. We didn’t end up deploying it in production, they wanted to wait for the rest of the pieces to be built, but they could play with it, they could see how it worked, they could give us real feedback.

Did I mention they decided against deploying it in production until the rest of the project was ready? That was the most critical piece of feedback yet. It told us it wasn’t as important as we thought, and we were able to re-prioritize around other things.

That kind of feedback is only possible when you get feedback about the value you are providing. And that is exactly the feedback Linus is talking about: the ruthless feedback of users who don’t care about your plans or your years of experience or your blog or whether you work for a billion-dollar company or whether you use Java or JRuby, or whether your servers are MSFT or Linux.

the scarce resource

In addition to feedback, there’s another reason to develop software in products rather than increments. Strangely enough, it’s the exact reason that software projects naturally “want” to divide themselves up into increments rather than iterations. Once you understand this, you need to ruthlessly fight a project’s natural slide into increments.

Increments deliver what you might call software value. Completing an increment validates architecture or software assumptions, such as “Can we build a functional facade in front of an ORM and expose it to applications via REST-ful web services.” Since a software development team does a lot of software development, it naturally wants to modularize the software along development lines.

If the team is large enough, it can happily develop multiple simultaneous increments of software functionality. It has the software development bandwidth to pull this off. And each increment contributes to several different chunks of business functionality: The database will be used by every feature, as will the system for pushing notifications to browsers, as will the markup for building pages, as will… You get the picture: Working on any one increment of software is really working on many simultaneous products at once.

Unfortunately, the capacity of a team to effectively develop simultaneous products is nearly always one. That’s right, no matter what the size, teams are most effective when they work on one chunk of business functionality at a time. And by teams, I mean the full team, including stake-holders, business analysts, everyone, not just the programmers.

There is nearly always an excess of software development “muscle” compared to the management attention available to analyze the software once a project is underway. Business focus is the “scarce resource.”

Focusing on one business iteration at a time is not about maximizing programmer productivity. In fact, it has nothing to do with programmers. It’s about a very scarce resource: management attention. Whether you are building a commercial application for an ISV or a client project for a government ministry, there is a very limited ability of the stake-holders to digest the project’s progress and contribute with feedback and priorities.

Developing multiple increments simultaneously hits the stake-holders hard, forcing them to try to manage the relationships between them in their head, understand the impact of changes from product onto another, and juggle twice as many documents and meetings.

The results are invariably poor.

So what to do? The answer is surprisingly easy. Divide large projects up into their natural products, then develop the iterations serially. Work out which product can be developed first, and then start with it, religiously rejecting attempts to extend it horizontally with features from the other products. Resist the siren’s call of “optimizing development time.”

When each product is done and delivering value, build on it by adding another product. Repeat until done.

(Originally published in December, 2007)