Friday, April 14, 2006

The Software Success Reference Model - Overivew

Here, again, is my Reference Model: a 30,000 ft. view of software success. This post will provide an overview of the categories from the model--sort of a taxonomy of success. See my previous post for more information on how I derived this model.



Groupings
Organization and Project Management
Perhaps this should be entitled simply Organization and Management. This grouping deals with factors that are beyond the scope of any project team--organization and management at the highest levels.

Project Team
These factors deal more specifically with the project team involved directly with producing the software.

Iterative Development
This category contains factors that relate to producing software in an iterative, incremental, adaptive manner.

Productive Culture
Factors dealing with the kind of people the Organization employs and how the Organization fosters a culture that promotes productivity.

Productive Practices
Specific practices that help the Project Team develop software efficiently.

Software Engineering (for Large Projects)
Factors necessary for projects with a large number of developers and/or critical consequences of failure.

Factors
Manage for Agility
This factor encompasses the critical role that Management--or the Client--plays in Iterative Development. Leadership must be willing to launch a project without detailed plans or specs, and trust the team and the process. Further, project clients must realize that the agile approach is a Good Thing, allowing the team to respond nimbly to a changing world, and producing more relevant software in less time.
Deliver Value Quickly & Often
Another aspect of Iterative Development, this factor focuses on the ultimate goal of software development: working software. Teams must focus on producing working software from the very first iteration, and keeping implementation as relevant to the needs as possible by avoiding unnecessary interim work products and long time lags.
Continuously Learn & Optimize
The final component of Iterative Development is the concept of continuous improvement. Iterations afford the team with the opportunity to exercise all lifecycle activities in short bursts. This means they can reflect, learn, and optimize their process and practices with each cycle.
Empower the Project Team
Also solely in the Management arena, the client of the project must provide the project team with the tools, resources, and support necessary to succeed. As much as possible, the team must be allowed to organize and direct itself however necessary to deliver the requirements.
Enable Open Communication
Software development is inherently a team design activity. Communicating ideas and building a shared mental model of the solution are critical. Organizations must strive to achieve "osmotic" communication, provide access to experts, and involve users throughout the process.
Demand Quality
Teams must develop a high standard of quality as a norm, and internalize quality validations within the team, rather than "throwing" code "over the wall."
Use More Realistic Specification(s)
Just as a picture is worth a thousand words, the richer, higher-fidelity one can achieve in software specifications the better. Teams should use mock-ups, prototypes, and visual models as much as possible, while still constraining specification to whatever is "minimally sufficient" for the current increment.
Use Automation and Tracking Tools
The value of SCM, task & issue tracking, automated tests, etc. is well established. Just do it.
TODO: Software Engineering factors

2 comments:

Anonymous said...

great post, look forward to the continuation, especially in making things more explicit in terms of best practices etc. thanks for this.

PS: small typo in the title of this entry

John said...

Thanks, ferdy. I hope to finish the overview soon, and then do a series of posts on the various groupings.

Note that, since this work is an attempt at a "taxonomy" of success, I probably won't be offering much in the way of new, hands-on practices. But I will point out some techniques from trusted thought leaders.

My goal is to provide a set of "boxes" that need to be filled for success. To fill the boxes, organizations can draw upon the work of the experts or come up with their own implementations.

Thanks again for reading!

- John