May 29, 2006 / Agile System Analysis: Why The Spec Hurts?
4 commentsSystem 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
4 Comments:
Very nice idea, thanks for the post!
There is one thing that still concerns me. What about estimates and budget?
There are usually two reasons for the first version of Spec:
1) mapping business goals into system functionality
2) budget/resource allocation
The first point can be covered very easily with a pretty small conceptual document just as you suggested. But is this enough for proper budgeting?
What also adds complexity is that for most of the projects set of functionality is fixed (decison: go/no go) and other times budget is limited/fixed (decision: functionality becomes a variable).
One can say that fixed set of functionality requires less documentation.
I think you're exactly right that up front requirements analysis has to be done at the right level of detail. Going too far with it will only result in wasted effort.
I'm reminded of advice Mike Cohn gives about estimation in his book, Agile Estimating and Planning. Up to a point, putting more effort into an estimate yields a more accurate estimate, but beyond a certain point it results in a less accurate estimate, even if it looks more "precise." The same rule of thumb applies to up-front requirements elaboration.
It's an example of the classic problem of false precision. For example, in the US we use the Fahrenheit temperature scale. We are taught that the normal human body temperature is 98.6 degrees. Because of the decimal point, people automatically assume the value must be extremely accurate. Mothers worry when their babies reach a temperature of 99.4 or 99.8 degrees. Yet, the figure 98.6 is simply the conversion from Celsius of the general normal body temperature, 37 degrees. This is not meant to be an absolutely precise value, but when expressed as 98.6 degrees is looks precise and people take it too seriously. The same problem can occur with requirements specifications that look highly precise. People assume precision implies accuracy. It isn't so.
Budget is a problem in every project with fixes scope when team/someone wants to use agile development. In fact if project going to be with fixed scope/budget, there is no way to apply agile development, only very restricted set of practices like TDD, Refactoring, etc. You may predict budget by doing estimates on early stage, but this will be rough prediction in any case and will give only budget order.
It seems to me that prototyping or simulation can be invaluable in defining requirements more accurately and faster. Simulation/prototyping software from iRise and Simunication are great tools to this end. You should consider this development.
Post a Comment
<< Home