Geeks With Blogs
AJ Warnock This Page Left intentionally Blank
Recently, a friend and past coworker called and of course the topic meandered to work and software development as frequently occurs. We began discussing development and agile development in particular. It seems that a majority of his issues appear to stem from self-styled “Agile” or lean development teams and the lack of attention to adequate requirements gathering and discovery at his organization.
Often and from many people, I hear that agile or lean development processes are flawed because they focus the team on self direction and deliverables rather than ensuring complete specifications before the development has begun. However, being lean or agile is not about skipping the necessary, prudent or regulated development tasks. It is about minimizing the effort spent on tasks where the cost benefit ratio is less than desirable when the guiding policies, regulations and contracts do not require the undertaking, deliverable or function. This means that appropriate and sometimes even complete requirements gathering is a primary pre-requisite of all agile development initiatives.
No, I am not saying that you must completely specify, document and define all interfaces, functionality, architecture and design; however, you had better know the rules, constraints and at least the minimum requirements for successful completion (And, yes although agile prefers working deliverables and satisfied customers over highly specified contracts.  Detailed contracts are often the norm). This means that if the requirements have not been defined, legislated or contractually agreed upon prior to the beginning of the project then it is the agile development staff’s initial responsibility to ensure that they discover and define them.
With the high levels of enthusiasm and passion usually associated with the start of a new initiative, I know that it is very easy to start defining and designing a solution prior to truly ensuring that we adequately know the constraints, guidelines, restrictions, and requisites; in addition to the final goal or desired deliverable. While you can freely practice and prepare for a marathon; don’t try to start, run and win a marathon before you ensure you know and complete the application process, the checkpoint requirements, the schedule, and acceptable course. You don’t win the marathon by just being the first person at the finish line the day of the race; by running the race a day early or late, or by running the race without checking in at the required checkpoints.
We need to remember our first goal before solving the problem is to refine, define and appropriately ensure that we know what the problem, goal or destination, as well as, the rules we must follow to get there.
Posted on Wednesday, August 5, 2009 10:07 AM | Back to top

Comments on this post: Requirements, we don't need no stinkin requirements....

# re: Requirements, we don't need no stinkin requirements....
Requesting Gravatar...
I often say, "We need the requirements, just not necissarily all of the requirements document"
Left by james peckham on Aug 06, 2009 5:33 PM

Comments have been closed on this topic.
Copyright © AJ Warnock | Powered by: