Seven Best Practices of Agile Projects
Enterprises are moving towards agile software development methods to increase productivity and project quality. Agile projects must adhere to agility best practices to increase their success.
There are seven best practices for operating agile projects. These best practices span every size of IT organization and generally apply to all agile projects. Follow these practices to optimize agile software development and drive improvements to the projects' bottom line.
- Stress frequent releases. Long iterations tend to hide problems. Minimize risk and increase control by keeping iterations short (e.g. three to six weeks). Short iterations allow flexibility and adaptability to changing realities. They also allow the project team to catch problems faster and fix them before the problem spins out of control, or the project runs significantly over budget. Projects are completed in stages with a series of deliverables rather than a single final product. This makes modifying the direction of the project according to evolving needs much easier.
- Keep it simple – smaller is better. Keep a tight rein on project scope. Requirements can change frequently within the project boundaries, but the boundaries must be held firm to control project size and maintain ease of communication. If project size gets too big, break it into separate projects so agility is maintained. Agile projects function most effectively at a maximum team size of 20. Consider a maximum team size of 10 for small and mid-sized enterprises.
- Create working software, not comprehensive documentation. Documentation accompanies software to explain its use and its function. Agile projects must focus on just enough documentation for the situation. The agile manifesto's focus on minimal documentation has resulted in disagreement within the agile community over just how much documentation is appropriate. Use Info-Tech's guidelines to determine the amount of documentation that is adequate:
- If the expected life of the solution is greater than three or four years, then there is value in putting documentation together for maintenance and for faster development of additional projects within that system or business process area.
- Keep documentation to a bare minimum for short-term solutions that have little integration. Documentation will be unnecessary and will slow project progress.
- For projects with regulatory compliance requirements, there may be additional requirements documentation necessary beyond the typical agile project. In regulated environments, surface early documentation requirements affected by regulation. For example, a business requirements and a functional specifications document satisfies Sarbanes-Oxley, HIPAA and SAS 70 Type II requirements.
Documentation consists of:
- Software documentation. This includes any document that defines requirements, design, testing, or systems architecture.
- Technical documentation. This includes source code documentation, algorithms, and interfaces.
- End-user documentation. This includes manuals to assist and train end users, system administrators, and any support staff.
- Provide a framework for stakeholders to actively participate. Agile methodologies emphasize the importance of incremental feedback in the development process. Implement methods for continuous feedback and changing requirements into project design and goals.
- Ensure that the whole development team – analysts, developers, and testers – are continuously working with customers. Set up testing whereby users can relay their impression, suggestions, requirements, and feedback to the team.
- Include communication mechanisms, such as team e-mail addresses, a project team Web site, and standing meetings in project set-up.
Effective communication and interaction mechanisms will boost the team's productivity. Improve communication by:
- Encouraging regular team meetings or round tables (e.g. weekly, daily).
- Having daily lean conference calls (i.e. minimize waste) to keep team members in touch and up to speed on the project progress.
- Designing the work space to facilitate co-located teams. Move the development team to a separate space within the organization so they can speak to each other frequently without disrupting other employees.
- Remove barriers such as cubicle walls to encourage open and frequent communication between team members at their desks.
- Increase individual competencies and collaboration levels. To be agile and efficient, the team needs the appropriate resources to be readily available. Intensify the normal level of support for the project team. Provide the tools and technology required for efficient collaboration and quick access to functional and technical expertise. Identify and deal with training needs and competency gaps early and often.
- Push decision making as far down the team as possible. Agile teams must be treated as the decision making unit for the project. Establish a clear picture of project expectations, rules, and boundaries. Ensure that an escalation process is in place and can be used when needed, and also ensure that the team knows when to use it. Decision boundaries must be broad and escalation must be the exception. A clear and properly defined decision making framework is good practice for any project, but it is required practice for success in agile.
- Customer collaboration over contract negotiation. Agile methods differ from other methods in that work is performed in a highly collaborative manner. Working closely with customers or business partners is more effective than specifications or strict requirements resulting from lengthy negotiations; designs and implementations can be constantly steered and corrected if necessary. Determine high-level scoping questions up front. Work with stakeholders to answer the big question and define important requirements first. Further changes can be done in an iterative manner. In highly-regulated environments, surface early any requirements affected by regulations. Mark these as high priority before proceeding.