In the essay, which is about the need for a science-literate political system, Lederman states

…I am driven to the ultimately wise advice of my Columbia mentor, I.I. Rabi, who … urged his students to run for public office and get elected. …We need to elect people who can think critically… We need a national movement to seek out scientists and engineers who have demonstrated the required management and communication skills…

While I agree with Lederman about the need for more science-literate representatives in our government, what I am posting about is related to software development. What is that? Well what if we take the above and do a few substitutions?

s/run for public office and get elected/apply for management positions and get them/
s/elect/hire/
s/scientists and engineers/developers and architects/

The point is this: we’ve all had our share of PHB silliness, but we can’t expect things to get better if we aren’t willing to be involved in managing our affairs. We shouldn’t be afraid to manage.

Does all of the code compile?

Number of automated tests?

What is your code coverage?

What is your branch coverage?

What is your average cyclomatic complexity?

If working with legacy code, how long has it been since it was modified?

If working with legacy code, who wrote it, an employee or contractor?

Are you familiar with the Joel Test (or something like it)? What’s your score?

If you have the basic infrastructure:
What type of source control do you use?
What tool(s) do you use for continuous/daily builds?
What tool(s) you use for bug tracking?
What tool(s) do you use for deployment?

How long does it take to get a user environment set up?

What type of machines (RAM, CPU, monitor(s) size)?

What type of phones? Obvious how to hang up, redial, etc?

How easy is it to get conference area?

Do conference areas have projectors?

Do conference areas have whiteboards?

Do cubes have whiteboards?

How many managers have programming background?

How many managers to a person?

How are people organized? Matrix, hierarchical, team?

Who makes the estimates?

What is the basic unit of measurement for estimates? Hours, days, points, etc?

Type of browser? Are daily tools dependent upon browser?

And, of course,

Is coffee provided?

Assuming that our stakeholders are comprised of customers, developers, testers, database, support, and deployment working in their own silos, what is the common ground between any two?

Worst case:

We can see that in a worst-case, siloed organization, the conduit for communication can differ. Even between two stake holders, the conduit can differ depending on the flow of information (e.g., the conduit between Customer and Support is not the same as Support and Customer). Each conduit is a chance for miscommunication.

So, the common ground between any two can vary. What if we have an idea or issue that spans several silos? More and possibly very different artifacts will have to be taken into account. Because these artifacts were created by different groups, there’s a good chance there is going to be miscommunication and wasted effort.

Now, let’s tweak the terms like “Requirements”, “Application”, “Bug Report”, and “DB Schema” for a best-case description of said artifacts/conduits:

Requirements: Description of what the Application should do with runnable examples and text
Application: The system that will be deployed for users, as well as all the tests, set up scripts, etc
Bug Report: Automated, report-as-soon-as-you-find-it test failure
DB Schema: The DDL and DML used in the database in support of the Application

What we really need is something that takes the best-case description of the artifacts and holds them in a common area for all of the stake holders. This common area would be the spot where we all can talk the same talk, manipulate the necessary artifacts, and if need be, see the appropriate “view” (as a Customer, as Tester, etc…) of the software as a whole.

Where/what is this commons? Well, it doesn’t fully exist yet. Things like Fit, FitNesse, and BDD almost get us there. The next generation of tools such as Twist get us even closer.

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.

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?

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.

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.

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!