Agile Development: "Think Big, Start Small!"
Many software development projects fail simply because they are too big.
Too big to get traction. Too big to achieve clarity. Too big to stay focused. Too big to organise and manage effectively.
And too big because by the time they're developed the business requirements have moved on!
A key part of agile development is the principle of building software in small, incremental releases - repeatedly iterating to continuously improve the software feature by feature. This mitigates traditional risks significantly by keeping things small, and substantially improving visibility of what's been completed.
But that doesn't mean agile development is only a good approach for short tactical work, or for business-as-usual changes to existing products. It can also be applied equally well to larger projects and more strategic initiatives, repeating many iterations before completing an entire project or release.
In this situation I would still encourage regular releases though. Certainly as regular as possible based on the minimum requirements that make sense. Why should any project only deliver 1 or 2 releases - why not deliver releases regularly throughout the project? Apart from minimising traditional risks with software development projects, this also enables early delivery of some benefits, allowing the busines to realise some value early.
My mantra, for keeping this in mind, is Think Big, Start Small!
See also:
How d'you eat an elephant?
No Sprint is an island!
Fast but not so furious!
Too big to get traction. Too big to achieve clarity. Too big to stay focused. Too big to organise and manage effectively.
And too big because by the time they're developed the business requirements have moved on!
A key part of agile development is the principle of building software in small, incremental releases - repeatedly iterating to continuously improve the software feature by feature. This mitigates traditional risks significantly by keeping things small, and substantially improving visibility of what's been completed.
But that doesn't mean agile development is only a good approach for short tactical work, or for business-as-usual changes to existing products. It can also be applied equally well to larger projects and more strategic initiatives, repeating many iterations before completing an entire project or release.
In this situation I would still encourage regular releases though. Certainly as regular as possible based on the minimum requirements that make sense. Why should any project only deliver 1 or 2 releases - why not deliver releases regularly throughout the project? Apart from minimising traditional risks with software development projects, this also enables early delivery of some benefits, allowing the busines to realise some value early.
My mantra, for keeping this in mind, is Think Big, Start Small!
See also:
How d'you eat an elephant?
No Sprint is an island!
Fast but not so furious!
0 comments:
Post a Comment