Agile development teams often struggle with reaching the goal of having every sprint deliver a customer-ready build. Not every software feature fits into a short sprint. Should you abandon such a feature or revert to waterfall for implementing it?
At times, unforeseen issues arise and a feature can’t be completed as planned within the sprint. Should you call the entire sprint a failure and start over?
There is an agile approach
There are better options. Think about how a feature can be hidden or disabled, if needed. A feature that requires more than one sprint to complete can be turned off until it is fully baked.
A feature that isn’t production-ready as planned can be shut off without bringing down the entire sprint.
The challenge is planning for the best way to do this for each lengthy or risky feature in the software. Here are a few ideas:
- For features that are exposed to the user and driven by the user interface, insert the ability to enable or disable the affected UI elements. This can be done with command line switches, configuration files or build options.
- For features that are not exposed, similar approaches can be used to disable them. For a high risk feature, turn it off by default and enable it when ready.
- If you are building an interface to an external system and you’re concerned about problems with it, consider building a dummy interface that returns pre-defined values. Use it until the real interface and the external system are available.
Examine every aspect of software development
Sometimes a software process problem can be solved with a technical approach. Don’t jump through hoops trying to devise a convoluted process when a simple change in the implementation will do.
Being agile requires that you examine every aspect of what you do. Nothing is sacred. Analysis, design, implementation, testing, deployment and support all need to be more agile for your organization to realize the full benefits of agile software development.