Back in May, I was at a talk presented by Kiril Savino of Gamechanger. Mr. Savino discussed both the product they are building, the stack they use to build it, and the process they use in building it. He noted that there are several processes out there, but all effective software processes include the following four principles:
Having had sufficient time now to understand these points, here is my take on them:
The principle of iteration is not something that is unique to software. I think everyone was taught in grade school to do a rough draft and work to improve it rather than try to do an immaculate first draft. The first draft of something will always have problems, no matter how well you try to plan before hand. To make matters worse, until you see the product, you will not know in what ways it is important to improve the work. Every first draft also has some good things in it too, and it is hard to see what works well and what does not until you have something tangible in front of you. Being able to work in quick iterations helps to maximize the good while minimizing the bad over the course of a software project.
Communication comes in two flavors: verbal and written. Written communication’s strength is that no one has a perfect memory, and by putting down what two team members agreed to, there is a decreased chance of misunderstanding between them. The obvious benefit of written communication is that there is a piece of paper with what two people agreed to. Less obvious is that the act of putting the communication down on paper forces the writer to be more precise and to think out what was said in more detail. I have found that when I write something, whether it is an email, design document or blog post, I find inconsistencies in the way I think about a problem that I don’t see until I’m staring at them on a computer screen, and writing them provides an opportunity to correct my misunderstandings.
Verbal communication’s strength is that it is interactive. Whereas a written document can potentially cover the “wrong” set of details, in a conversation one person can tell the other what he does and does not understand. No document, except for the software itself, contains every detail about how a piece of software works , and team members need to talk when they have different views about a requirement or design constraint.
Giving the developers on a team a backlog helps them in lots of ways. From a technical standpoint, knowing what features are coming down the pipeline helps to plan what technical infrastructure the team will need and what the team needs to do to train itself. It also helps in terms of morale. Without a backlog describing to the team the direction a product will take before its release, it is not ever clear if the team is approaching the goal not. Another way having a backlog helps is that future requirements are coming from a well understood set, and are not being written the day a sprint starts.
Automation can fundamentally change how a team collaborates. For example, Mr. Savino mentioned in his talk doing automated deployments, which is becoming a common practice. Automated deployments make the feedback loop between developers and those giving feedback (for example, the product owner, QA, customers, or the CEO) much shorter, which makes correcting the software less expensive. It also makes deployments easier, since a developer or system administrator doesn’t have to take his time to manually go through an error prone checklist that might be out of date.
Automated tests are another example of automation that changes team collaboration. If a developer writes a piece of code and someone has problems with it, he has to interrupt the flow of what he is working on, take a look at it, understand the problem, and figure out if it really is a problem with his code or how the code is being used. If, however, that same developer writes a piece of code and the tests to go along with it, then when a bug occurs the team can more easily narrow down the cause of the bug.