I know this isn't specifically architecture-related, but thought I'd blog on the topic anyway. In every organization I've help introduce agile, there's one question that always comes up; "Should agile be applied on every project?". This is asked both by those who are hesitant in adopting agile and also those that have and whose enthusiasm knows no bounds :) And it's a good question.
The obvious reaction is that "yes", the principles that underpin agile should be applied on every project. But life, as ever, isn't as simple as that and there are circumstances in which the use of agile could be the root cause of failure. Imagine if you have no business representative on your project. Or what if, due to technology constraints, the concept of continuous integration was near impossible? Trying to force agile into places where the odds are against you really requires careful consideration.
On my first agile adoption programme, I had a few ideas in my head of the factors that can make or break an agile approach. As a result of that work and a fair amount of investigation I came up with a set of factors that I've since applied consistently on several more agile adoption initiatives, so these do hold up to some scrutiny. And harvested from many sources I have to say. The various factors are listed below (grouped by specific areas) where a positive response to each question is favorable toward adopting agile. As it happens, this was built into a framework that allowed an organization to assess a potential project, with each factor given a weighting, a score and a "red / amber / green" indication of whether each factor was going to result in a project risk should an agile approach be adopted.
Of course, the result doesn't lead to a black-and-white decision (although some organizations use the framework to choose between different project lifecycles, such as waterfall, iterative and agile), but it does provide an indication of points of sensitivity to watch out for. I hope you find this summary useful and would appreciate any comments on this list (positive and negative).
- Business Flexibility - Management is willing to accept that business parameters, such as cost, schedule and intermediate milestones, are flexible
- Empowered Teams - Management is willing to allow the team (including the product owner) to make key project decisions
- Acceptance of Agile - Stakeholders understand and accept agile practices and the consequences of following these
- Number of Stakeholders - The number and diversity of stakeholder relationships to be managed is limited
- Stakeholder Responsiveness - The business representative, end users and testers are committed to spending a good deal of time working with the team in an iterative fashion
Project Team Influences
- Team skills - Individuals on the team are team players, good communicators and are familiar with agile practices
- Embracing Change - Team members expect and embrace frequent changes and iterative refinement of the solution
- Colocated Teams - The project team will be colocated
- Team Stability - Individuals will be assigned to the team for the duration of the project
- Team Roles - Team members are able (and willing) to take on multiple roles during the project and to take on new roles if/when needed
- Agile Disciplines - Team members have proven ability in performing disciplines that are critical for agile development with short iterations (design, testing and configuration management)
- Development Environment - The development environment (method, tools, training) will support an agile way of working (such as automated regression test, continuous integration and real-time dashboards) and is sufficiently mature
- Execution Environment - The execution environment can support regular releases
- Requirements Churn - There is a strong likelihood that there will be significant changes to requirements (and the solution) during the project
- Solution Complexity - The required solution is relatively-complex (e.g. requires the use of unfamiliar technologies) and/or there are many different solution options
- Time-to-market - The deadline (time) is the most important factor for the solution while the scope of the solution is flexible
- Dependencies - There are no (or only a few dependencies) on internal or external suppliers
- Release Frequency - The solution can be subdivided in viable and meaningful business releases that can be delivered within 3-4 months
- Demonstrability - The solution can be easily demonstrated on an incremental basis (through a user interface, for example)