Agile software development has gained wider interest recently as companies seek ways to better respond to changes in customer demands and market dynamics. Whilst agile can be applied quickly for small isolated developments or in small startups with a flat organizational structure, it is a different matter to integrate agile within an established organization.
During a client meeting recently, the development manager asked what challenges we had come across when working with both agile and traditional waterfall (sequential) approaches. In the next few posts, I will summarize the 5 critical lessons for successfully using agile in enterprises that are more familiar with the traditional waterfall approach. The first lesson is:
1. Choosing the Right Approach
Agile has been successfully applied for small or standalone software development projects, new product developments where software is a major component, user experience-led (UX) or user interface-led (UI) software developments, iterative product developments e.g. Minimum Viable Proposition (MVP) and product developments with a single product owner from concept to end-of-product-life. Agile does not lend itself to large or complex projects unless these can be broken into smaller releases. Agile can be risky for projects underpinned by contractual cost, scope, timescale and quality (e.g. how long is a piece of string?). However, the benefits of agile working can be gained by applying agile where appropriate to whole or parts of projects where it make sense.
Agile is most useful where the requirements for a product or software solution need to evolve. Instead of asking stakeholders to imagine what a product will be like and try to capture their ideas in requirement statements, agile offers an effective way to quickly translate concepts to a working model that can be refined through an iterative process. This has the advantage of providing quick feedback to the product owners and users, and also avoid spurious requirements for features that may never be used. (Half of all software features are never used!)
On the other hand, if the requirements are known e.g. the interfaces to legacy systems or existing business processes, then there are no benefits in 'discovering' requirements and the efforts should be spent on ensuring adherence to specifications and standards. Instead of agile, it may be beneficial to consider prototyping to validate integration patterns and system performance.
There is no doubt that some of the agile pricinples can be applied to the traditional sequential approach (e.g. user engagement), and similarly, some of the structure from formal project methodologies can be of benefit to agile teams (e.g. change management). The key lesson is to choose the right apporach for the challenge at hand. Anyone suggesting a binary decision between agile or not agile, needs to expand their understanding of both agile and waterfall approaches.
The next post will look at the challenge of introducing agile to a traditional project organization.
During a client meeting recently, the development manager asked what challenges we had come across when working with both agile and traditional waterfall (sequential) approaches. In the next few posts, I will summarize the 5 critical lessons for successfully using agile in enterprises that are more familiar with the traditional waterfall approach. The first lesson is:
1. Choosing the Right Approach
Agile has been successfully applied for small or standalone software development projects, new product developments where software is a major component, user experience-led (UX) or user interface-led (UI) software developments, iterative product developments e.g. Minimum Viable Proposition (MVP) and product developments with a single product owner from concept to end-of-product-life. Agile does not lend itself to large or complex projects unless these can be broken into smaller releases. Agile can be risky for projects underpinned by contractual cost, scope, timescale and quality (e.g. how long is a piece of string?). However, the benefits of agile working can be gained by applying agile where appropriate to whole or parts of projects where it make sense.
Agile is most useful where the requirements for a product or software solution need to evolve. Instead of asking stakeholders to imagine what a product will be like and try to capture their ideas in requirement statements, agile offers an effective way to quickly translate concepts to a working model that can be refined through an iterative process. This has the advantage of providing quick feedback to the product owners and users, and also avoid spurious requirements for features that may never be used. (Half of all software features are never used!)
On the other hand, if the requirements are known e.g. the interfaces to legacy systems or existing business processes, then there are no benefits in 'discovering' requirements and the efforts should be spent on ensuring adherence to specifications and standards. Instead of agile, it may be beneficial to consider prototyping to validate integration patterns and system performance.
There is no doubt that some of the agile pricinples can be applied to the traditional sequential approach (e.g. user engagement), and similarly, some of the structure from formal project methodologies can be of benefit to agile teams (e.g. change management). The key lesson is to choose the right apporach for the challenge at hand. Anyone suggesting a binary decision between agile or not agile, needs to expand their understanding of both agile and waterfall approaches.
The next post will look at the challenge of introducing agile to a traditional project organization.
RSS Feed
