Assembling Agile

Which agile approach is the best?

Every project is different. There’s no single Agile approach that works for all projects. Discussions on whether one Agile approach is better than the others conducted on several fronts are annoying and superfluous. The most important thing to consider is what we learn from each Agile approach and even traditional methodologies. How can we forge an approach from these experiences that works for our organization and our projects? In short: how can we assemble Agile?

Whichever approach an organization or project chooses is irrelevant. It’s more important that projects learn from the mechanisms and techniques that make Agile efficient and effective. Implement those mechanisms. Short iterations. Collaborating teams. A small unit of work. Prioritize again and again. Continuously plan and measure. Practice continuous testing and delivery. Keep communication as simple as possible.

Choose the approach that’s most obvious and best fits the organization and the type of projects being implemented. The approach gives the team a common vocabulary. Start, for example, with Scrum. Scrum is lightweight, has a big reputation, is fairly easy to implement, and provides a lot of freedom in the use of complementary techniques.

Factors to consider when choosing an Agile approach

The question then is what additional techniques should companies use in their project? This is different for every project and depends on a variety of factors. The following question will help us understand the factors involved while choosing the approach:

• Are there few or many stakeholders?
• Is the project carried out locally or is it distributed?
• Are end users directly involved?
• How does the project backlog get created?
• How many parties work together?
• Is the software realized by an external party?
• Is the price fixed?
• How experienced is the team?
• How complex is the architecture?
• How complex is the domain?
• How complex is the application landscape?
• How does the project fit into the existing organization?
• Which tools are used?
• How is the software handed over to maintenance?

In short, projects also have a sliding scale, from small and lightweight to heavyweight and complex. As projects become more complex and heavier, the team needs more grip. Some examples are as follows.

• Contracts: In fixed-price projects, choosing the right contract type is vital.
• Preparation: Many projects, especially long-term ones, choose one or two preparatory iterations using Smart and DSDM to get more of a foundation before starting on the realization.
• Set-up: In short-term projects, it’s of great importance to have the development and other environments established in advance. Establishing the environments in distributed projects is even more complex. Think of continuous integration and unit testing. Establishing them on time is crucial.
• Stand-ups: In any case, organize stand-up meetings. On distributed projects, video conferencing is essential for this.
• Dashboards: In projects that are carried out in one location, a dashboard of post-its on the wall suffices, as does a spreadsheet to monitor progress. On distributed projects, an online dashboard is inevitable.
• Unit of work: For simple applications or mobile web applications, user stories often suffice. In complex service-oriented application landscapes, smart use cases may be a better unit of work.
• Estimates: On projects with distributed teams, estimating can be tricky. Estimation poker isn’t always possible. Are teams in different locations estimating the same way even if they use the same scale?
• Tools: Be careful with the use of all kinds of tools.
• Tests: On more complex projects, the role of testing is more crucial than on lightweight projects. If possible, don’t start complex Agile projects without explicitly having testers on the team.

Above all, don’t be dogmatic. Leave room for the team to optimize the chosen method during the project. Where necessary, add new techniques and best practices from the various Agile and traditional approaches. Give the team this space right from the first day of the project. A team will continue to learn.

This way, no method is imposed on the team. Instead, the team takes responsibility for its own method.