Sep 11, 2008 / Software Development Diseases and Agile Medicine

3 comments

It is really interesting to check some established diseases in software development and investigate how they can be resolved using agile processes. If agile development is so good, it should provide solutions to common problems. Here we go.

Student Syndrome

Many people will start to fully apply themselves to a task just at the last possible moment before a deadline.

Maybe the most famous disease in software development teams. You have 40 hrs task and thoughts like "Huh, one week! I am pretty sure I will complete this task in 2 days!" You are doing something fun like refactoring or research and start working on the task Wednesday's afternoon. Suddenly you encounter a serious problem. You spent all day hunting for resolution with no luck. In a weekly status meeting you say that task was not done and 80% ready, but there is completely unexpected nasty problem that popped up and broke the plans.

Looks familiar? Yes, it is. Agile development solves the problem with several simple practices:

1. Daily Meetings. You have to say something on a daily meeting. If you committed to the task on Monday and spent all Monday researching something completely unrelated you will have bad feeling during Stand-Up. It pushes you to actually start working on task. Also serious problems will not be under the carpet for days, they will be revealed and expressed.
2. Short Iterations. In short iterations every single task is important. If you have 1 week iteration you are feeling that deadline is close enough and you have no spare time. If you have 6 months project deadline in waterfall process you have an eternity. You can do wrong things for weeks till the reality hits you in the neck.
3. Short Tasks. Two days is a good maximum for a single task. It is quite hard to convince yourself that you can start coding tomorrow if you have only two days to complete the task.

Parkinson's Law

Work expands so as to fill the time available for its completion.

Indeed it is a matter of perfection and laziness. Some people may complete the task earlier and have spare time for other things. Some people will complete the task earlier and polish the solution till it shines. Some people will digress from the task and complete it on time. All attitudes may be dangerous. The result is that a whole project delayed.

Agile approach has some medicine for this disease as well:

1. Definition of Done. The task is done when it passes all assertions in DoD. The goal is to have clear, unambiguous definition. People should know when it is ready. The phrase "it will be done when it's done" should have clear meaning behind.
2. Iteration Goals. Clear iteration goals help people to focus on getting things done.
3. Short Tasks. Again short tasks may help here. In short task it harder (but still possible) to add long safety buffer.

Conway's Law

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Maybe it looks quite weird, but this law has great application in software development. If you have two modules that interact via API, you hardly create good API unless developers of the both modules communicate together. It leads to some conclusions:

• Communication between developers is very important for good design.
• Distributed teams may hurt software design in case of poor communication (and it is harder in distributed teams).
• Software can't be produced in isolation. You can't have several people working on several modules with no or little interactions.

In agile development there is a clear statement that communication is very important. It does not have explicit practices for software design communication (well, except pair programming), but it doesn't take a rocket scientist to create and apply them. Company should adapt and change to have great communication flows.

Brooks' Law

Adding manpower to a late software project makes it later.

There are two simple reasons behind this law:

1. It takes some time for the people added to a project to become productive.
2. Communication overheads increase as the number of people increase.

From the first sight agile development can't to anything with these problems. However that is not true.

1. Pair programming. Likely it is the most efficient way to familiarize new people with the project.
2. Iterative Development. New iteration and new release is a new mini-project in fact. It is easier for people to start with something new. If you join the team in the middle of one year release you feel less comfortable.
3. Small teams. Agile approach works best for small teams. When it scales, it does not bring much communication overhead. For example, a single scrum team works autonomously, while scrum master participates in scrum-of-scrum meetings. However it does not increase communication time in a single scrum team.

Feel free to continue the list of diseases ;)

Labels: agile, software development

posted by Michael Dubakov @ 2:32 AM