Archive for September 2009
For Sage Accpac ERP development we adopted the Agile Scrum development methodology back in June. Since then we are now on Sprint 5 and learning all sorts of things about scrum and agile as we roll out and practice this methodology. There are quite a few aspects to agile, but one of the key ideas is to relentlessly breakdown large tasks into smaller manageable tasks. Then to finish those tasks completely, don’t let them drag on, say code now and leave it to be tested three months later. For us we’ve realized quite a few immediate benefits:
- Teamwork. Our agile teams are typically 6 to 12 people (most close to 6). This fosters excellent teamwork and shared purpose for the team members. It is also far easier to manage such a team, than say manage 40 people working on the same thing. The teams are also cross functional, so it aligns programming, quality assurance, user centered design and documentation together on the same team, rather than being members of separate departments with their own agendas.
- Sprints. By running in three week sprints, it forces us to keep the product integrated and greatly helps preventing large numbers of bugs accumulating that need to be cleaned up later.
- Better estimation. By forcing us to break tasks down to take less than one sprint, it forces us to fully decompose tasks and greatly increases our estimating accuracy in the process.
- Better release planning. The agile release planning process is far superior to the older waterfall methods, with all their hand overs. With agile release planning you create your story backlog and when planned this is what you directly act on and track, without an conversion processes.
- Better project tracking. Tracking agile stories and story points and measuring team velocities is far easier than traditional project management techniques which track by days or hours with all their complicated formulas.
- Pushing decision making down to the teams. This has greatly eliminated roadblocks and enhanced teamwork. The teams make their own decisions and are responsible and accountable for the results. Works far better than relying on a Directory or Manager for decision making.
When adopting any new process there is some pain as you switch from what you know and what is tried and trusted to something more unknown. But it’s really a matter of having the patience to give the new process a chance. To see it working and to learn to trust it. One of the harder things to accept for Agile is the concept of not designing things until they are needed. There is an element of trust and confidence here that you will be able to successfully do this when the time comes. That everything isn’t laid out at the beginning of the project.