The Software Development Domain
"Where To Start"
By Glen B. Alleman
Glen's Tip
More on the Agile Alliance
The Agile Alliance http://www.agilealliance.cm ohas a nice repository which includes some agile PM papers.
Several questions have arisen lately on "where to start" when entering into the software development management domain. These questions actually took me by surprise and caused me to think. I've been doing software development and managing those who do for nearly 27 years now. So asking where to start seemed out of place at first - why everyone knows where to start. You start at the beginning. But that's harder than it looks. For agile software project management this is a bigger problem because many of the texts and articles assume the reader is an experienced developer or development manager.
I'd suggest an alternative approach. Start with a "framework"for how software "should"be developed independent of any method. "One" starting point for this approach is to look through the Software Engineering Institute' CMMI materials. These can be found at http://www.sei.cmu.edu/cmmi/. I know this sounds anti-agile but in fact it's not. Much like the poor implementation of PMBOK, poor implementations of CMMI - by firms having absolutely no business seeking CMMI - are common. Nothing in CMMI-SW (Software) states "how" the practice areas to be implemented. Agile methods are a nice fit in many ways. There are some presentations in the same site describing just this. http://www.sei.cmu.edu/cmm/slides/agile.pdf is a starting point.
If you look through the practices you'll find narrative on all kinds of processes for delivering software (use CMMI-SW Staged). I'm not suggesting you seek CMMI, nor would I suggest that for anyone that has not fully assessed their needs for CMMI. But process improvement - continuous process improvement - has great value for software development firms (and likely all other firms as well).
My second choose would be Walker Royce's Software Management: A Unified Framework. Again this is perceived as anti-agile but of course it's not. Finally Highsmith's and Cockburn's works must be in the list.
One other starting point is to ask and answer what kind of software you're working on: real-time process control, bank check clearing, ERP? These domains many times drive the processes that produce the software - there are few universal "methods"that can be moved into practice without tailoring. By defining the domain, the external and internal driving forces and gaining a good understanding of the process elements of a software delivery process, the question "where should I start" now has a chance of being answered.
A word of caution -there are hundreds of books on "software management."Not all are good. In fact in my experience few are good. The primary reason they are less than satisfactory is they are "normative"and "rational" in their approach. What this means is they are "sets of rules"for managing the development process. Sometimes looking at the rule book is useful, but managing software development projects is not one of those. So I would also recommend books by Steve McConnell.
About the Author:
Glen
Alleman is Vice President, Program Management for the Information and Network
Services organization of CH2M HILL's Communication Group. Prior to this
position Glen was the Principal Consultant for Niwot Ridge Consulting, where
he specialized in the management enterprise application integration projects.
At CH2M HILL, Glen provides services to Rocky Flats Environmental Technology Site. This work involves program management services for software development, server and network operations, infrastructure installation and removal, as well as telecommunications and wireless devices. Glen B. Alleman < galleman@niwotridge.com>