May 29, 2006 / Agile System Analysis: Why The Spec Hurts?

4 comments

System analysis is a VERY complex and hard activity in general. It is so easy to spend months on requirements gathering, huge amount of small details, visions, business rules specification, domain model refinement, detailed good looking UI mockups and prototypes. In Waterfall, Business Analyst digs into all this things several months and creates The Spec. Approved. Signed. Complete. You know what happen with this spec in future. No, I don’t think that The Spec is completely useless. It does provide helpful information for developers, explains system goals and in the best cases describes business model. But I think it is just an overhead to have The Spec and especially in the beginning. There are just two correlated reasons:

• It takes much effort.
• It is incomplete and imprecise in ANY case.

The less effort you spend on spec, the less precise it will be. The more complete spec you want upfront, the more effort you will sacrifice on Requirements Definition phase. The sad fact is that The Spec WILL be changed. Developers will find conflicting functional requirements, market will change, customer came to you with new ideas s/he want to see in the system right now instead some other already defined features. World is not an Ice, world is a liquid, it changes quickly and unexpectedly. Business software development is not mathematic, it is imprecise and chaotic by the same reason: world around the system changing every day.

So huge part of the effort spent on The Spec will be wasted. Moreover, even existence of such desirable and hopeful thing as The Spec hurts software development. The Spec impedance changes, but software development embraces changes, so The Spec should not be created by wise development team. OK, but what is the alternative?

Solution is simple, let’s call it “Details On Demand”. In many cases output is less important than the process itself. System Analysis process more important than The Spec. During this activity you learn a lot. You learn who will use the system, what problems that people have, what are they hopes and desires, how to make they life easier and what are you going to build anyway. Are you sure you need to know on May whether button “Hide Old Leads” required on Leads list, if you will work on this functionality on November? I don’t think so. There are so many more important questions and areas to address. Forget about complete details, you don’t need them upfront.

Get back to “Details On Demand”. In any development process Requirements Definition phase should take place. But it should be short and just enough to form system vision and high level view on future system. After this stage you should know answers on all important questions like “Who are system users?” and have details about a dozen the most important system features. Should you create a spec as a separate document? I don’t think so. The Spec may be replaced with several other smaller manageable artifacts:

• List of system users with their goals and usage patterns. This will be system concept if you want to call it that way. This simple list answers almost all the most important questions about future system. It clearly shows who will use the system, for what purpose and even how. Each developer should keep this doc in mind. It focuses on important things that users deserve.
• Features/User Stories You may have them in any format: written on index cards, written on sheets of paper, written in MS Word or putted into Agile Project Management System like TargetProcess. After Requirements Definition phase you should have:
  • More details for most important user stories that will be implemented next month
  • Short description for all other user stories (usually naturally comes from system usage patterns)
• UI mockups for most important parts of the system

That’s all you need to start development. No, really. That’s all you need to have good feeling about future system, to understand what you are going to build. In fact The Spec (in ideal case) should play the same role: give developers confidence in future system, give them “a-ha” moments. But huge specs play against developers, hiding knowledge and confidence somewhere between pp1-999. “I just don’t have time to ready it! I’d better relay on Project manager, s/he will give me assignment and I will just complete it. No more, no less”. The Spec fosters parasitism in development team. This is one of the most dangerous things for project success and solid team building.

posted by Michael Dubakov @ 10:45 AM