Cockburn suggest to take into account these factors when designing a methodology:
- Problem size: bigger problems need more people to resolve it, and by consequence more coordination mechanisms. 2 developers working in a garage hardly need any coordination rule. 100 people working in a big building need a lot of coordination rules.
- Criticality: Will the life of some people depend on the software you are making? If it will, tighter controls are needed.
- Precision and accuracy: Are you dealing with wall street money or is it just a movie rental system?
He also says that there is not a one size fits all methodology. The methodology needs to be designed based on the problem that needs to be resolved. Smaller, less critical projects with 6 members on the team need much less artifacts and coordination mechanisms than bigger, more critical projects. It is not the same to have a collocated team of 6 people, all of the same culture/country than having 100 people, in different continents with different cultures, languages and time zones.
Therefore, why are we saying that Agile is having a lightweight methodology? Probably what we should say is "Agile is having the lightest methodology that the problem in hand needs". Highsmith states that the methodology needs to be "barely sufficient" ... "A little bit less than just enough". The methodology should be light in the context where it is applied.
Why do we want a lighter methodology?
First, because we want to deliver value early and often. Cockburns states that excess methodology weight is costly because more time is spent writing and maintaining work products (like GANTT charts, plans, etc.) that don't directly contribute to adding business value. Teams that use lighter methodologies are more productive because they spend most of the time on productive activities. The second reason, which is as important as the first, is Agile welcomes change. With a heavy methodology, it is difficult to change because there are many artifacts and more ceremonies. If there is a lot of documentation to change and many meetings, changing will be painful for everyone and therefore everyone will want to avoid it.
Making your methodology lighter
There should be constant instrospection on the artifacts and ceremonies that take place inside the team. Face to face communication is more effective than communicating through an intermediate deliverable and it is much lighter. Having the team together increases the flow of communication and therefore decreases the need for written documentation and meetings. Highsmith says "don't confuse documentation with understanding". In the end, what matters is understanding. Feedback provided by business people is of utmost important. Instead of trying to define big diagrams, which usually contain a lot of guesses, do a little bit and show it to someone that understands. This type of communication makes the methodology lighter while maximizing the chances of doing what is expected. Another important point is discipline. Agile teams are highly self disciplined. As a developer, I have felt the pressure of doing things the best way I possibly could because I was pushed by the high standards of the team. This is in contrast of being pushed by a process. Agile teams constantly introspect what's giving them value and what isn't. Why are we making this document? Is this meeting being helpful or is just a waste of time?
