Those of you with children will have experienced the ‘why’ stage of a child’s development.
What’s that?
A tree.
Why?
Err…
Why is one of the fundamental building blocks of learning that, as providers of solutions, we tend to overlook. Most of us have learned from experience that regardless which software development process we use that requirements are key. However, I am also sure that we have also been in a situation where we have been ‘fixing’ a problem for someone and halfway through being told why they wanted you to do it and realise that you have a better solution for them. It is a human trait to try and provide solutions to problems and often what people call a requirement is a result of a preformed solution. The real requirement is hidden in the ‘why’.
I always try to remember to ask why (although not in necessarily in a direct way) to understand the goal better. I can still remember times when I haven’t and have kicked myself for forgetting to ask.
User stories adopt the ‘why’ in the ‘so that’ part of the phrase. However, this post is more about remembering to ask why to ascertain the real user goal in all aspects of solution delivery. The goal (‘why’) often shows the true requirement that users are unintentionally hiding from you.
A case in point is SDLCs (Software/Solution Delivery Life Cycles). I have worked at a number of companies that have formal processes and procedures. These processes tend to be similar in having stages including requirements definition, functional specification, technical design and so on. However, people seem to assume that this means a heavily paper-based documentation approach. Unfortunately, most of the documentation I see does not achieve its goal and I also see a great deal of duplicated effort between the various stages.
From my experience a large proportion of people writing documents as part of an SDLC focus on the need for document X at this stage rather than the goals of the stage. Don’t obsess about the paperwork – concentrate on the goal – capturing requirements, and defining a solution that the user needs. Is writing a on hundred page design document delivering you any more than a prototype would?
The idea of design documents is to present a solution that can be reviewed for less than the costs of doing equivalent work. I have witnessed far too many cases where the design documents take longer than the development effort and, in many cases, as the authors are not domain experts provide a sub optimal solution anyway.
There are ways that we can follow an SDLC in a more agile way, removing unnecessary duplication, being more productive and fulfilling a user’s needs. To software traditionalists the mention of agile principles conveys an image of non-controlled development when the opposite is true.
That is why.
, click All Programs, and then click Accessories.
In the User Account Control window, verify that Program name is Windows Command Processor, and then click Yes.