One of the more difficult decisions to make in an IT development project is how much analysis of requirements is required before any actual coding is done. Actually, I’ll make a minor adjustment to that statement: in a perfect world, knowing how much analysis and discussion of requirements is required is not a completely straightforward decision. I am deeply suspicious of anyone who resides at either end of the spectrum of this dilemma – all the more so when they prove to be intractable in their views.
Whether there’s an Agile/XP evangelist saying let’s just jump in and start coding without actually analysing what we’re trying to achieve or some hidebound bureaucrat who isn’t happy until everyone is bleeding from the eyes (and probably still wants to keep going even then) – sticking to some orthodoxy no matter what is likely to end badly. So what does this BA think is the ideal amount of analysis?
You should do as much analysis as is required but no more than that.
That statement isn’t half as glib as it might seem. The real issue is that “how much analysis is required?” is the wrong question. The right question is “What are we trying to achieve?” And just to head off the Agile zealots, I’m not talking about definitively answering “what will the end product be” before starting any coding. The important thing for the business to know before they start wasting developers’ times is what are the desired outcomes? Not how it’s going to be done but what the business needs to achieve for the project to be a success.
As a BA, it’s a constant struggle to stop people on the business side from leaping straight to “We should use this software and have this sort of widget and all the buttons should be cornflower blue.” At the early stages when the scope of a project is being set, the analysis should ideally be limited to “what do we want to achieve and why is it important?” In almost all cases these conversations can and should be completely technology-neutral so there’s no need to drag developers into endless brain-storming sessions.
When it comes down to it, the non-IT side of a business should almost never consider technology when analysing requirements for IT projects. That’s the role of the technical team. Scope-level discussion should almost always steer clear of technical issues (apart from any mandatory compatibility issues) but even documentation of detailed Business Requirements and Functional Specifications can be done without focusing on technical details. These documents should be telling you exactly what their names suggest: outcomes the business requires and what functions the system will have to perform to deliver on those requirements. Both of these can be analysed in depth without dictating the technology to be used.
So at the end of the day, the “right” amount of analysis is going to differ from situation to situation. If you’re following an Agile-type approach with rapid iterations then analysis probably only needs to progress to the scope level. Define what outcomes you want at the level of “this is in – this is out” and go for it. But be very wary of anyone telling you any up-front analysis or design is too much. How can you possibly know when you have succeeded if you have nothing to measure your output against?
While I lean towards much more analysis that the average Agile devotee would advocate, I’d run a mile from anyone who wants to saddle me with crippling never-ending design and analysis processes. Nothing will crush the life out of a worker like a death march with no end in sight.
If you can’t define what it is you actually want to achieve then you need more analysis. If you are in the 10th hour of meetings to discuss what particular shade of green will most inspire customers without having developed a functional prototype to see if the solution is even viable then you are wasting valuable time and brain power with analysis paralysis.
Do what is required. Nothing more. Nothing less.
20 responses to “Analysis Paralysis”
Sometimes when the product is finished, it ends up being out of date, that is why I guess people enjoy Agile.
The first time I ran across a programmer in the wild spouting off about XP I found myself holding back laughter. Zealotry is right.
I suppose renaming it Agile is spreading the religion?
i agree with you that BA should focus on “what is required” that is the end result of project or program instead of how to do that.
i think “Do what is required. Nothing more. Nothing less. ” sum’s it up very right.
The worst experience I’ve had is a boss who mulls things over ad nauseam and makes a decision only well after the majority of the choicest bits of the opportunity have passed. ARRRGGGHHH!
The questions I always add on to this, because the stuff I work on tends to be more open ended are
How will we know if we succeeded? How will we know if we failed?
If you can’t answer those then you just want to build something ‘kewl’ and that’s fine by me; I LOVE a good art exhibition. But it isn’t business.
The title of your blog is actually quite hilarious. It captured my attention. I like your blog. It was interesting to read!
I’ve yet to meet any of these zealots I keep hearing about who would advocate jumping in and coding before having any kind of conversation with the customer about what’s wanted. People are confusing Agile with the “code and fix” anarchy of the dot com era.
Scrum and XP both emphasize tightening the feedback loop with the customer. At the beginning of each iteration we conduct a Sprint Planning Meeting (or a “Planning Game”) to negotiate what will be done, along with the acceptance criteria for each item.
range: I think the “getting to work” aspect appeals to a lot of people
candice: it’s not like the XP/agile approach is without merit but the zealots (like all zealots) get a bit scary
cancerus: that’s my zen koan for analysis.
gwhiz: yeah. and then they blame you for things not working
robert: good summary, is it ary or business?
shelby: glad you like it!
agilescreener: possibly you have selective blindness, possibly you are lucky. Agile seems to be whatever someone wants it to be – it’s incredibly easy to find zealots and it’s incredibly easy to find masses of contradictions.
On second thought, I guess I do meet zealots: often newbies who have had a good experience with Agile, or PHBs who have read good things about it but not yet realized it’s hard to do, with many pitfalls. I posted about this here: http://www.danube.com/Scrum_is_Hard_and_Disruptive
Agilists argue with eachother about implementation details but tend to agree on core principles, as expressed in the Agile Manifesto. http://agilemanifesto.org/
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.”
I’ve found that doing Scrum and Agile in real life does require a certain amount of the things on the right, so I guess I’m essentially in agreeement with you. Next time you meet a zealot who doesn’t value the things on the right at all, send him to me!
Agreed on the scary zealotry.
Programming by someone’s textbook methodology has always seemed a bit off. Especially in the case of the XP folks, they came out of a failed software engineering project. (And also, the formal software engineering that they are now starting to teach in schools is frightening. A mind-numbing endless maze of diagrams.)
agilescreen: you the man! All zealots will henceforth be sent ot you.
candice: yep, zealots = scary. Pragmatic adoption of useful things I can live with but I’m not into drinking the kool-aid.
Candice: Care to give any specific examples of this zealotry? Which textbooks? I’ve been out of school a long time.
tas: look around online, specifically when anyone prominent has questioned the value of agile methodology – you’ll see the zealots come out real quick.
Check out the Software Engineering program’s work at CMU. They are one of the leaders in that. (I went to a school with a related SE program at RIT, but I fell in with the CS snobs instead. Much more interesting to actually do stuff.)
Oh, you mean the SEI? Their work with CMM and “Product Lines” *is* an attempt to create a textbook methodology. But that’s the opposite of what the Agile movement expouses: doing practical work to meet customer needs sooner, with frequent mandatory reality checks.
Amen! My poor GF is working on a team where management (of all people…) is making the technical decisions.
I don’t know WTF the BAs there do. Everyone of them I have met was an overly perky female (although at least one was knowledgeable about technical matters), which scares me…
 The perky part.
candice: thanks for the background
tas: don’t get so defensive. You’re not a bad guy, that doesn’t mean there are *no* bad guys.
Devlin: A place full of perky female BAs? Where do I sign up?
tas: I’m mentioning that being frightening as well, that’s all. SEI was the acronym I was looking for, I actually managed to get those braincells back.
Analysis paralysis or what?
Wicked wicked problems