It Ain’t Easy Being Agile
You have to admit – agile folks are conflicted. On one hand there’s the folks screaming requirements are dead***. On the other hand, people teaching agile practices have to explain the asterisks; mention these things called user stories and the practices of getting good user stories (like making each user story testable and how to deal with non-functional requirements). Then there are the folks rolling out these practices and using them in real life on complex engagements. We’re facing the issues of sequencing and redundancy of stories, figuring out which ones accidentally change the architecture of the system (oops!), which ones were really a whole book rather than just a story, etc. and how to actually get to the promised land of higher productivity. No wonder you get questions from developers like, “can I write down this non-functional requirement?” Agile is still a storm of mixed messages – and like the Internet bubble of the late 90s hype might do more harm than good to the movement over time.
Let’s get away from the hype and look at the facts of performance – meaning development efficiency, timeliness and stakeholder satisfaction. I recently looked at all of these variables in a large scale research study – The Business Analysis Benchmark. What I found is that Agile, Waterfall, Iterative, Prototyping/visualization-centric approaches all performed identically. Statistically there is absolutely no difference between any of them. What creates the performance difference is the level of requirements discovery and management maturity behind the primary SDLC selected. Any hype that says agile practices are universally better is simply wrong and detrimental over time. It will lead to very large scale and eventually public failures – and a counter-movement away from these practices. This would be a real shame. Agile is great stuff when used correctly.
Methods and practices of business analysis have to follow the mantra of “the right practices at the right time.” You can’t use OLTP analysis practices/techniques and expect to produce effective requirements on a data warehouse. It’s silly! Similarly, you want to target agile practices to the right projects where agile makes the most sense and have enough corporate requirements discovery and management maturity to know the difference. Anything else is like trying to blast a square peg through a round hole. If the stakeholders don’t want to participate in scrum meetings every day… get onto another track! If you’re dealing with something data driven or with very high numbers of transactions in a regulated system – run away… don’t walk. Yes, you could do it… why would you? I could run around on the freeway too, but I’m suggesting there are better ways to use some roads. In the long run, using the right techniques at the right time will pull far more momentum to the movement than creating hype and watching the carnage.
Don’t forget to leave your comments below
Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.