I have found that organizations pursue agile initiatives from two directions. Organizations want to be agile because they have software engineering problems to solve (e.g. staff turnover, buggy software, brittle software) or they want to be agile because they have business problems to solve (e.g. customer dissatisfaction, loss of revenue, loss of market share).
I have also found that no matter what direction you start, once you have one set of problems fixed, the other raises its ugly head begging for attention – even if you didn’t have recognizable issues before. An inescapable side effect of becoming agile in one area is that it creates and/or magnifies problems in the other.
I was recently talking to a friend who is helping to lead the agile adoption in their organization. They said that their organization is consistently executing 3 week sprints that include enough testing to produce potentially deployable increments. YEAH! They said that their organization is ‘priming the pump’, i.e. grooming the product backlog during sprints to prepare for the next sprint (or two). YEAH!
But, they also said that their organization is now struggling with a bloated backlog of requests and issues. BOO! Business problems have raised their head – What should we work on next? What features are important and which ones aren’t? Can you reject requests? How?
I rarely start an organization out with hierarchical requirements. A flat product backlog that supports feature grouping is usually sufficient to start an agile adoption. Yet, within most innovative organizations, there will come a time when a top-down requirements management strategy will become necessary. Frameworks like the one proposed by the Scaled Agile Framework (SAFe) were developed for just this purpose.