I’ve been thinking recently about what makes a software project successful. Of course this depends on what you measure success by and where your team is starting from in terms of previous success and skills, however I’ve found that a minimum set of basic practices can make a big difference in the outcome of your project. This is purely my own opinion based on personal experiences, not all of the following will work for everyone but I hope the general principles are useful no matter what your circumstance. They are in no particular order.
1. Maintain a backlog
Keep a single, prioritized list of outstanding tasks. This must be loved, maintained and groomed, preferably by a single person, preferably the product owner. This list enables self organising teams, empowers developers to take control of and responsibility for the work they do. As it is a single list containing all types of tasks – bugs, improvements, documentation jobs – the team has a single location for all outstanding work. As it is prioritised any team member can easily find the next most important thing to do. As it is maintained the team has confidence that the list is up to date and correct.
2. Technical practices
Any software development hinges on the capabilities of the developers. Bad developers can kill a project, good developers can save it. You absolutely cannot cut corners on technical practices and training. A development team should have an ongoing commitment to training, adapting to the needs of the project but also addressing regular practice of foundation skills. The most fundamental of these is Test Driven Development (TDD). A developer with a good grounding in TDD and a basic knowledge of a language can very quickly and relatively easily create functional, proven software that is easily extensible, easily maintained and easily understood. This is the fastest and most reliable way to become a reliable and effective team member.
I have also grown to value ad-hoc pairing to encourage knowledge sharing and increase the quality of the software produced. Two heads are always better than one, from design and implementation to testing and definition, although pairing is hard partly because it is difficult to get over the counter-intuitive hump that pairing actually makes you go faster in the long run. Hand in hand with TDD goes simple design, small changes and the SOLID design principles. It is fairly straight forward to create software that adheres to the SOLID principles when using TDD.
3. Daily standup
You can substitute this section title with “morning sync”, “scrum”, “water cooler catch up”. There are many ways to achieve the same affect, the critical part is to create a means by which the team regularly and consistently talk to each other so that everyone knows what the others are doing, who to go to for help and if anyone is blocked. The standup should be quick (5 mins), concise (no rambling) and small. Teams of 8 or more are pushing it and the important points are more likely to get lost amongst noise. It is the job of the scrum master (or coach, or team leader) to make sure the standup achieves its intention and to pursue any blocking points the team raises and remove the blockage as quickly as possible.
The benefits are that problems are raised as soon as they happen, are visible to all team members and a self organising team can optimize their activities based on the daily update. This makes the team responsive, adaptable and highly focused on delivering business value.
4. Project board
Provide a visible, accessible project board that the team can use, change and update. This is best if it is physical but if that is not possible then a virtual representation can be made to work. The project board should be a focus of the daily standup and the team members will likely make use of it several times a day. Task progression can be tracked here as well as blocking issues, milestones, bug counts and any other information relevant to the project. Other terms for these boards are information radiator, kanban board or scrum board.