[This article is a guest post by Rajesh Raheja, who is a senior director of development in the Oracle Fusion Middleware SOA group. He is a Certified ScrumMaster and a Stanford Certified Project Manager. You can visit his blog or connect on Twitter @RahejaRajesh. Note: The views expressed on this blog are his personal views and do not necessarily reflect the views of his employer.]
A few months back I wrote about the challenges facing agile adoption in the enterprise. It stressed on the three areas: complex interdependencies across projects, effective utilization of specialized, shared resources across projects, and finally, the “sprint overhead” for complex, architectural tasks.
In this post, I would like to outline a few tips to overcome some of these challenges.
1. Get management buy-in. 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 agile to waterfall style adds no value.
2. 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 (that would defeat the agile purpose), hence the use of extrapolation. Some agile tools support this concept by allowing the placement of backlog items on specific releases.
3. Plan sprints with specialized/shared resources in mind. For example, plan on effective usage of an architect or a performance expert’s time. Don’t expect these resources to be part of your sprint / daily stand ups.
4. Complex inter-dependencies are a reality – deal with it! Identify dependencies across project modules/components upfront during release planning. In some cases, we called this 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.”
5. Keep reasonable sprint lengths – at 3 or 4 weeks. 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. Specifically, Sprint Zero may be the largest sprint of the project so as to remove sprint overhead on the rest of the sprints.
6. Don’t expect all sprint deliverables to be production ready. Especially in enterprise integration projects that have very complex dependencies across legacy applications, the initial sprints build the foundation for the end-to-end integration flows. Latter sprints can then execute deliverables from all dependencies and test the overall integration flow.
7. Define “done” consistently across the teams. For example, “done” could imply the following: design, coding, unit testing and coding deploy scripts. Further more you may want to include the specification of system tests (as opposed to execution) to be part of the story in case service dependencies restrict system testing.
8. Reserve at least two “hardening” sprints. Use these sprints purely for bug hunts, system testing and refining any remaining packaging/deployment tasks.
9. Be pragmatic about usable documentation. Use an agile design document template or use Wiki’s instead of writing reams of documentation that no one will probably read. On the other hand, don’t skimp documentation only in favor of code comments because you need to document the functional context and know-how to benefit future developers.
10. Adopt continuous integration principles. Build early, build often, and don’t break the build. This is invaluable for complex code interdependencies.
The following diagram highlights some of the above principles used within many of our integration development projects.
A special Sprint Zero is followed by iterations of functional and design specifications for the overall business process flow or architecture design. The output flows into Construct sprints, which goes into Test sprints. While at the outset this may look like waterfall-ish, this “iterfall” approach worked very well in combining the best of both worlds, reducing project risk and increasing visibility into the project details. The above concepts would also work well with other agile methodologies as well such as Kanban, which introduces a process oriented workflow in place of time-boxed sprints.
[Want to guest post? Let us know]