Software development processes have long advocated structuring a software solution around a domain model of the problem space being automated. A domain model shows how our business processes add value by progressing the states of our key business entities. These entities and their life histories tend to be much stable over time than the processes that surround them. Modeling the entities and their states enables us to experiment with different ways of achieving the same outcomes (state progressions) as we seek to rationalize and automate these processes.
So, why have we never thought to build a good domain model of the software projects at the heart of our software development processes? At IJI we started building such a model some four years ago and this model now forms the heart of our process kernel around which we built the Essential Unified Process. One key motivator was to model the value that different development practices and processes can / do / should provide so that we could enable our customers to evaluate and select between different ways of achieving the same outcomes.
Some of the key entities in the IJI software development kernel include:
- Project – the software development project itself
- Requirements – how the software system we are developing should behave
- System – the software system we are developing
- Opportunity – the opportunity / problem space into which the system delivers value
- Team – the team that undertakes the project to develop the system
These are the “spaces” in which we can expect development practices and processes to add value, for example by helping us to:
- Steer the project to a timely and successful conclusion
- Understand, share and confirm the requirements
- Build the right team for the job and enable it to collaborate and operate effectively
Even at this very high level we can start to put this simple domain model to effective use. For example, we can get various stakeholders to rate our current capabilities within each space as a precursor to any process improvement or practice rollout initiatives – how critical is each space to our success, and how good or bad a job do we do in each space currently? If we find that we do pretty well in the project and team spaces, but we suffer significant pain in the requirements space, then looking at adopting a project management practice like Scrum should perhaps be a lower priority than looking at requirements practices such as Use Cases or User Stories.
If now we start to think specifically about the kind of advances or progressions that we need to achieve early on in any project, we can say for example that we need to:
- Agree the key project milestones, such as the next planned release point (i.e. progress the Project to state Milestones Agreed)
- Agree the goals and scope of the release we will produce at that point (i.e. progress the Requirements to state Shared)
Having established WHAT we need to achieve, we can now look at the different options that we have in terms of HOW we might go about achieving it. Scrum, for example, has the concept of release planning, which tells us that we need to do these things, but gives us little specific guidance on how to achieve them. User Stories are great for prioritizing and sizing the requirements and driving and tracking requirements progress, but we really need a scope-level view before we can go about getting the right kinds of users into the right meetings and give them the right scope steers to get the right kind of user stories coming our way. Actually, a Use Case diagram is a great way of very rapidly sketching, agreeing and sharing the scope, context and user types for a release in support of Scrum release planning and in preparation for a user story workshop. Suddenly the “Use Cases vs. User Stories”, “either or” “method war” is shown to be an unhelpful and overly simplistic view of the world that prevents us discovering and leveraging some powerful practice combinations.
So, even with a few, very simple and obvious codified “spaces” (Alphas) and “bases” (state progressions) we can start to achieve some very powerful things that no other process construct can help us with, namely:
- Establish and communicate exactly WHAT a given technique, process or practice helps us with (and what it does not help us with)
- Evaluate potential practices and processes against identified process gaps, needs and priorities
- Establish which processes, practices and techniques are complementary and which are competing like-for-like alternatives.