I was talking to a friend the other day about agile philosophy and practices. We were talking about priniciples leading to actions, which in turn, lead to other principles.

He related an opinion he had received regarding the most important agile principle:

A commitment to continual improvement

Or taken from the Principles behind the Agile Manifesto:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I believe that if we are serious about producing software that meets our customers’ needs, all other practices and ideas can be traced back to this. If you can’t trace a practice back to continual improvement, or if a practice/principle leads to an improvement, but cannot be extended, then you aren’t going to see real, lasting, long-term improvement.

Too often, when we tackle a larger-scale problem–say something that is at a multi-team level–we don’t keep the idea of continual improvement in mind. Decisions are made that don’t take into account that we want to be able to improve even more sometime in the future. This leads to periods of improvement, followed by a plateau, followed by some backtracking, and then a new improvement.

If we want to reduce this plateau/backtracking, we must keep in mind that we want our decisions to be in accordance with our need to constantly improve.

Don’t repeat yourself. It is a great advice for writing code. However, it isn’t the only place it is applicable.

Let’s look at a super simple description of software development roles and their artifacts:

Customer: requirements, acceptance tests
Developer: code, unit tests, module tests, acceptance tests
Tester: module tests, acceptance tests

See the overlap? If customers, developers, and testers aren’t working together, we are creating waste through duplication. Even if we are working together, we can do better.

What if worked in such a way that the customer requirements can be run as the acceptance tests and acceptance tests can be viewed as customer requirements? What if architectural requirements can be run as unit tests or module tests? Or, vice-versa?

You can see where I am going with this. We are still creating a lot of waste because of duplication. If we can work within some framework (that doesn’t necessarily mean a tool) that seamlessly allows us to have requirements as tests and the other way around, and reuse tests between customers, testers, and developers, we can make some real gains in efficiency.

Furthermore, working in this manner reduces duplication in communication. Everybody is working with the same “stuff”. This “stuff” serves as documentation as to the expected behavior and real behavior of the system. There should be less time spent talking about the same thing amongst the various roles.

We are all essentially working on the same “stuff”. So, why not act like it and identify areas of duplication and reuse?

When we talk about customers with respect to an agile methodology, we often talk about people who have the final say in what is going to be produced and when.

Customers make decisions based on feedback from sources such as the current application, the tests for the parts of the application that are currently under development, their future needs, and what the development team says they can do in an iteration. The end result should be customer-approved software.

The implementation of the system outlined above may vary, but they key features remain. And, I think too often there is an implication that there is a distinct wall between producer (development team) and consumer (customer). The development team makes the stuff and the customer must approve it.

Contrast this with another approach to creating customer-approved software: have the customer write the software. Supposing the customers are savvy enough and/or have the right tools, if they write the software, it would be customer approved, too.

I actually worked at a place where this was the case. The first release of the product was written in a scripting language by industrial engineers that knew the domain. And, you know what? It worked. It did what they needed it to do at the time.

Notice I said “at the time”. As time went on, keeping the software “soft” proved to be difficult. Maintainability, extensibility, and testability went out the door. I don’t blame the people that wrote it. That kind of stuff is really part of the software development trade. In fact, I believe that if some sharp developers had been involved earlier, there would have been few issues.

What if the customer is not savvy enough? Provided we are always striving to improve our software and development process, I think eventually they will be. The longer we work with a customer, the more likely we will be creating tools for the customer to write some of the software themselves.

I am seeing hints of this at my current employer. On one of our projects we’ve reached the point where we have DSL for describing and testing our system that is used by developers, testers, and business analysts. We have super-tight iterations, with very few defects. If we are going to take a next step, it seems that step would be to use the DSL to create production code. It’s the next logical step.

Why is agile still such a foreign concept? Many software shop are familiar with the name, and some even claim to be agile. Yet, very few are.

In many places that claim to be agile, rather than collaboration amongst stake holders, there’s conflict. The process is more valuable than working, deliverable software.

“We can’t release your well-tested, customer-requested, money-saving feature now.”
“Why?”
“Because we only release 3.2 times a year, per our process. This release would violate the process.”
“Process? 3.2?”
“Yes. The process keeps us agile and the .2 helps gives us some buffer.”
“I don’t even know what that means!”

When does this silliness end? My guess is about one developer-to-leader generation. The developers that experienced an agile working environment will want to take it with them as they start leading others. But, that’s only when you’d start seeing some changes.

Have an agile team? Tired of all those high-quality deliverables and happy customers? Well, there are few simple things you can do to make certain that team will “fall in line”.

No-Location
Separate the team. Make certain the customers, developers, testers, and other stakeholders are not anywhere near each other. As face-to-face communication is the most effective method of communicating complex issues, it must be eliminated.

Lengthen The Feedback Loop
By making certain that decisions cannot be made “just in time”, you can prevent real agility. Purposeless delays in deploying to production, ridiculously long testing cycles, and a barely working deployment infrastructure can be a real help here.

Time-Consuming Metrics
A superb way to waste time and kill morale is to forcing agile teams to prove they are agile by collecting metrics that do not really mean anything to the end customer. Extra morale-killing can be achieved by having people track every single task they work on to the hour.

External Organization
Don’t let the team self-organize. Hold back key pieces of information that could allow a team to self-organize, such as organizational changes or time line changes. Be sure to conduct daily meetings that really are just people “reporting up”.

Emasculation
If at all possible, make certain whoever has the ultimate say in what will happen (e.g., the project manager) is completely out of the loop with the day-to-day work. But, don’t let the team have any say in how things are going to get done. Prevent individual and team decision making.

These are just a few simple suggestions. Be creative. You can break their will if you put enough effort into it!