There are many examples of constraints that can inhibit agility:
- Legacy system dependencies
- Vendor dependencies
- Disparate technologies requiring different skill sets, resulting in divided teams—e.g., mainframe versus Java, mobile versus web
- Geographical separation of talent (different time zones, or even just different floors)
- Coordination among software, firmware, and hardware teams
- Lack of automated tests
Mitigation strategies are highly dependent on the context and may take a long time to effect.
There Are Multiple Continuums
Even this agility continuum, however, is a simplification. Agility can vary across different dimensions of software development.
Requirements: What to build
Take, for example, a team whose agility in requirements is immature. Observations might include:
- Predominance of backlog items resemble tasks instead of user stories
- Large quantity of fully formed user stories that won’t be done for months (perhaps ever)
- Lack of clarity on which items to peel off into a new iteration
- User stories look more like requirements documents than index cards
- Missing acceptance criteria
Even this is an oversimplification, but it’s a step toward more clarity about where weaknesses and opportunities lie.
Engineering: How to build
Perhaps in this same team or organization, the engineering practices are mature. You might see some of the following:
- Test-driven development as a standard practice
- High collaboration between developers and testers
- Low defect rates
- Poly-skilled talent
Linkage between dimensions is important. For example, poor requirements may simply make an efficient delivery team deliver the wrong features more quickly. On the other hand, independent, valuable, small user stories without automated tests will impart a regression test burden on the delivery team, which will reduce efficiency and time to market as the product grows.