How to adopt Agile methodologies in the enterprise
Agility and flexibility are top of mind when it comes to delivering IT projects. With that being the case, the traditional waterfall development approach, which requires each step of a project to be completed before the IT team can move onto the next, seems a bit outdated.
By now, you know about agile methodologies and how they can help improve your software development efforts. It’s based on collaboration and continuous development, and differs from the waterfall approach in that it can be characterized as being adaptive rather than predictive. Essentially, with agile, the requirements gathering, development and testing happen concurrently versus consecutively.
While agile methodologies have had tremendous success in task-oriented teams, many larger businesses have been slower to embrace them as a corporate standard. In my experience, not only can Agile scale, but as the pace of change accelerates and consumerization impacts every corner of economy and government, Agile may mean the difference between success and failure in the long run.
Usually, the main challenges for agile adoption in the enterprise are: complex interdependencies across projects, effective utilization of specialized, shared resources across projects, and finally, the “sprint overhead” for complex, architectural tasks.
So here are few tips on how to overcome some of these challenges:
- Get the management involved – Program Managers should be aware of the agile approach, usage and expectations. If they are not on board, any additional work to convert reporting from waterfall to agile style adds no value
- Adapt sprint lengths –Integration flows and services are complex and shortening the sprint length to 2 weeks makes it impractical to complete any full-fledged integration flow. Keep sprints lengths at 3-4 weeks so that either a complete service or integration flow can be developed and tested
- Get used with complex inter-dependencies –Identify dependencies across project components upfront during release planning. In some cases, this calls for a special sprint called “Sprint Zero.” Use this sprint to also get commitments from dependent teams so that you can use this to plan future sprints. Use this sprint to also design the overall architectural requirements, so that these are not limited by the “sprint overhead”
- Plan for entire releases, not just one sprint – Use story points to estimate and extrapolate velocity from one sprint to future sprints. A lot of project planning is based on the project manager and team’s experience in estimating work; and this does not reduce with agile planning. Note that the future sprints don’t need to be fully nailed down at the start itself, and some agile tools support this concept by allowing the placement of backlog items on specific releases.
- Adopt continuous integration principles – Build early, build often, and don’t break the build. This is invaluable for complex code interdependencies.
For its collaborative nature, its customer-centricity and its adaptability, I would argue that agile development is the better option in most business cases today. It’s the less bulky option and enables enterprises to better discover and address user’s needs.