Breaking Agile Rules
Breaking Agile Rules on Purpose…for Successful Integration Projects
Not a true Agile disciple? That's okay.
Approaching integration with the mindset that they have tostrictly adhere to Agile principles will add unnecessary complications to your projects and will cost time and money. Everything that works in an Agile environment will not always be applicable to integration.
The value of Agile is not in dispute. However, significant resources are wasted in the attempt to conform, and there is a palatable pressure when you fail. If you want to make the best choices for your project and enterprise, being 100% agile may not always be part of the solution.
There are times when being a maverick and purposely breaking the rules is right. Resist being Agile-shamed for doing the right thing.
For Successful Integration—Some Agile Rules Have to Be Broken
Why is this? The answer may lie in the difference betweenthe natures of integration and Agile.
Integration is a supporting, foundational technology—infrastructure—that serves as support for another application. By necessity, it has significant degree of inflexibility and making sure that it is executed right the first time is essential. It is like the solid and rigid concrete foundation of a home, serving many masters—it is not only responsible for supporting the weight of the home, but also load-bearing walls,a parking garage, etc.
Agile originated among the “top of the food chain” product development projects, where there are volatile elements, or moving parts, that require the flexibility to make changes at any time. It was developed to take advantage of existing resources. To continue with the analogy of the home, Agile is the changing of the flooring, wallpaper light fixtures, or paint, that can happen over and over again.
How Integration Development Can Stray from Agile Principles
- Continuous development cannot be executed
- Documentation-heavy development and execution processes
- Requirements are clearly defined, with no allowance for variation
- Integration is usually one and done type of project.
Tips from Big Compass
Which development methodology should weuse? Waterfall is the predictive, traditional approach that takes steps early in the development process to reduce flaws. Agile is the iterative development approach in which there is an assumption that there will be errors.There are many cases in which predictive tends to yield better results for integration projects, but the world has been increasingly settling into Agile.
Here are some helpful tips to use to feel better about yourself and to survive in an Agile-centered world:
- Create an integration team with developers and business analysts (BAs)
- Dedicate multiple sprints to analysis - getting deliverables to shovel ready (i.e. data map construction so analysis can be done to determine priority, reuse, eliminate redundancy)
- Once the end goal is known, it is okay to look ahead
- “Get mapping doc done” is a valid user story sprint concept
- Given the number of moving parts, consider alternative models, like Kanban
- External deadlines drive priorities
- There should be no shame in questioning whether the agile development process is applicable to your integration project. Keep in mind your projects’ true goal: to establish interconnections between subsystems so that data can get to where it needs to be so that it can deliver value. This may require incorporating both predictive and Agile principles.