Bit Motif

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!