Preconditions for Agile

I had lunch with two good friends, and we talked about Agile. With my experience, I truly believe that Agile is the way we can make things right. But one of my friends is skeptical.

After I heard his concerns, I understood what he concerned about.

We talked about communication. He said communications also meant disruptions. Shouldn't we avoid too much disruptions in the team? I said yes. There is a precondition for interaction in Agile, which is that we should avoid unnecessary communications.

Then I talked about evolutionary design, which is also my friends' concern. He prefers good design upfront and I said yes, you are not wrong, because evolutionary design was once proved failed. In early days of software development, some 1980's, software pioneers found that there was a change cost for software development, which meant that if we found something need to change at the earlier phase, it would cost much less than we change something at the later phase. Say, for example, if we find out a problem when doing requirement analysis, it could cost us one dollar. If we don't find this issue but leave it to test phase, it could cost us 1000 dollars. With this thought, we have the waterfall SDLC.

However, along with the software development experience, people found out waterfall was not the way we can successfully develop software. Waterfall was based on one assumption:

• We could find the right answers upfront.

But actually we couldn't. Not for requirements, not for development tools. We even have problem with human resources, because people come and go more often than we would have expect.

That why we have to step back and think about evolutionary design and iterations.

The key issue we need to handle in evolutionary design is about the change. If we can flatten the change cost curve, then we can use evolutionary design again. In another word:

• If we can change something easily later, it is less important for us to have it right upfront.

So, this is another precondition for Agile: you need to make sure you can change the current design, decision, or implementation easily before you apply Agile. Otherwise, you are going to prove something has been proved in 1970's.

The answer for this was from Kent Beck. He found out two things to solve the change curve issue:

• Unit tests
• Refactorings

But my friend asked me again: sometimes unit test doesn't help, why? 

Here comes that precondition for unit test: you have to have a system that unit test friendly.

Unit test means that you can verify the system with a very small unit and make sure it work as expect. Two things need to address here:

• Your system quality could be assured mainly by unit tests.
• Unit tests needed to be simple and small.

Say, for example, if quite a portion of your system are running on some logic that your unit test could not reach, then how can unit tests help the quality?

On the other hand, if your unit tests are monsters, very difficult to understand or very difficult to trace problem, then how can those unit tests help improve the velocity?

That's why we have to advocate decoupling and cohesion. That's why we need Agile architecture for Agile development. That's why we need SOLID.

That are all preconditions for Agile development. If you miss them, you are not doing Agile at all, and you are possibly going to fail, and fail very badly, even worse than those days you are following waterfall.