Software development continues to increase in complexity with results being of higher quality and produced in less time.  It is a recipe for disfunctional teams and stressed out individuals.  To establish successful track records software teams turn to various means of define the work that needs to be done and track its progress.  There are a significant number of similarities between the management disciplines involved and I would argue that a common infrastructure to support these disciplines is key to taking the next steps in software process automation and software team collaboration.

The “management“ disciplines I'm referring to are: requirements management, bug and defect tracking, project management, risk and issue tracking.  I'm going to take some broad brushes here so bear with me.  Requirements management focuses on defining the “what”.  What are we trying to build?  Bug tracking focuses on identifying and resolving the things in the current “what” which deviate from the defined “what”.  Project management focuses on the “how“.  What is the work required to achieve the “what” and emphasizes who is doing that work, what is the ordering of that work, and when will it be done.  Risk and issue tracking focuses on reducing project risk by identifying risks and issues and tracking the work needed to reduce or eliminate these risks and issues. 

What do these things have in common?  First, they are all lists that software development teams want to keep track of.  What will the system do?  How high a priority is feature A?  Don't forget to fix bug 20303!  Hey Joey did you finish implementing that performance improvement yet?  Items in the list have a name or identity, they typically have someone assigned to them, they have state (e.g. Active, Complete, Deferred), and they have relationships between them and in fact interdependencies.  For example, a high-level requirement such as “The system must support e-mail notification” may produce  bunch of lower level features such as “Implement Notification API”, “Add e-mail event listner”, and “E-mail template deisgner”.   To implement these features, developers get assigned tasks (coding work) and testers get assigned tasks (test case development and execution).  All this work is tracked by the project manager as tasks with a result being as schedule for delivery of the “what“.  As testers start testing, bugs or defects are found and identified.  This produces additional work to be done along the way. 

It is all a web of work trying to produce the right what.

With the state of practice today, I believe there are significant gaps between the team member tooling causing inefficiencies in communication and collaboration.  Each member of the team uses different, but poorly integrated tools to get their particular job done.  The analysts defining the what, the project managers defining the plan, and developers and testers who attempt to build the what by following the how.  The difficulty is for a developer or tester in the trenches is to determine what a project's real requirements are and for a project leader to keep a schedule up to date with what is really happening on a project.  Both of these are key symptoms of these gaps.

I would assert that a common infrastructure that delivers a way to manage lists of items and their interelationships and yet supports the unique needs of each member on the team will signficiantly improving communication, support more sophisticated automation, and generally help teams achieve their goals more efficiently.

I'm keenly intersted in what people are doing to address these problems on their own teams.  I'll be at Tech Ed next week so feel free to drop me an e-mail and we'll find time to chat.  You can find me in the TechEd RIO system at http://rio.crgevents.com/TechEd2004/Rio/ 

+++++++++++++++++++++++++++++++++++++

This posting is provided "AS IS" with no warranties, and confers no rights.