The notion we can have a conversation about agile software development in the absence of a domain, context, and level of maturity of the participants is just that notional. we use the AT&L Life Cycle Management System in our domain. This wall chart shows all the process flow starting from an idea through the retirement of a DoD system. You'll notice the details are iterative and incremental.
The domain here and the context inside that domain is weapons systems acquisition. So there are limits on the appropriateness of these process outside weapons systems acquisition. But I was motivated to produce a "carton" of this chart for a discussion about the application of agile software development.
The location is simple to understand.
- In the same room - I can see the team from my desk. I can call across the room to ask a question. I can get up an walk over to a person without having to go through a door. We share the same refrigerator for our lunches
- In the same Building - I know where your office is and I can get there by walking. Maybe I have to ride an elevator. I probably have to go through a door. I can look to see if you're on IM so I don't waste my time walking. I probably worked with you on a previous project. We see each other at the Starbucks in the lobby.
- On the Same State - I can see if you're at your desk from your IM status. I can call you. I can see you on the video call. We have a shared document repository. We share source files through that tool. You speak the same language, but you may have a heavy accent.
- On the Same Planet - I probably can call you because you're sleeping. I can see you on the video call when you're awake. I can't there from here in less than 24 hours. You may not speak the same language.
Stages of Done means how mature are we when it comes to understanding the problem, how much it's going to cost, how long it might take and our confidence in these understandings.
- Research and Development - we don't really know what we're doing. If we did it wouldn't be called a research project would it. We'll spend all the money and consume all the time, then tell someone what we discovered. We've worked this problem before, but it didn't turn out so well and we don't know why. We have no idea what DONE looks like, but we recognize it when it arrives.
- New drug development
- Inventing new physics
- Flying to Mars for the first time
- Technology Development - we know what we're doing and we've done it before. We just haven't done it in the way the customer wants it done. We've got an idea of what DONE looks like and have seen DONE in the past, so we can see where we're going.
- Automating the warehouse with a software stem
- System Development - we've got a picture of DONE that is clear enough to say things like how long and how much with some level of confidence.
- Installing a DCAA CAS compliance accounting systems
- Installing a MSFT Project Server
- Adding 4 new pages to the corporate web site
- Rolling out the new cell phone products using the exsiting sales system
- Full Product - we're installing a COTS product and turning it up into production. We're trained. We've done this enough to have lost interest in the "coolness" of the products.
- Deploying SAP to the 12th site this year.
- Integrating the VoIP switch for the 33rd time at a new site.
SO HERE'S THE POINT
These are "cartoon" examples. They're a stretch some times. But
When do we discussion the benefits and outcomes of agile - and more importantly - discuss the "evils" of the past in the absence of a domain and context in that domain?
I have an opinion. That opinion is informed by my personal experience, the experience of others, and the research of those interested in this question. Here's my opinion.
Those who suggest their opinion has no domain and context don't realize there is a domain and context for nearly every thing technical. It's not philosophy, it's not generic, it's not generalizable (in the way many want it to be). The development of software and the processes that manage that development are coupled to the domain and the context inside that domain. The degree of coupling is itself a variable.
Those who suggest otherwise may have yet to experience development outside their domain and context. Or they may not want to come to grips with the notion their ideas are not that applicable to other domains.
I will strongly assert there are fundamental principles of managing a project. No matter the domain, context, technology or location on the planet. These principles are the Five Immutable Principles of Project Management.
Long ago (2005) I was a contributor to a large study around the success of IT projects. "The Story of Managing Projects: An Interdisciplinary Approach," Carayannis, Kwak, and Anbari, 2005. These gentleman are professors at George Washington University in DC where project management is a profession.
In that book we referenced many sources to guide the conversation:
- All the Capers Jones work on software estimating, classification, and processes
- Software development taxonomies of the Software Engineering Institute
- The Software Engineering Body of Knowledge (SWEBOK) to which I have contributed.
- The National Software Quality Experiment
- And many internal software taxonomy and process improvement assessments
From these experience came the 5 Immutable principles. They also came from watching success and failure (many times my own) and taking note for what worked and what didn't in my domain and others.
That may be the final contributor to the hubris of some in our industry - they have yet to have their "big flop" and keep notes about it.
