The Kernel Journals 6: Where to (first/next)?

The Kernel Journals 6: Where to (first/next)?We all know that we want to “cut to the chase” as soon as we can and start incrementally developing the software product through which we deliver value back to the business. But we also know that there are certain essential pre-requisites to “sprinting”, such as some kind of vision of where we are supposed to be going and the right team and tools to get us there. If we start motoring before we are ready we may head off in the wrong direction or we may find that the wheels come off as we accelerate through the gears.

It’s confession time. I’m a huge fan of Barry Boehm’s standard project milestones, as originally set out in “Anchoring the Software Process” [Barry Boehm, November 1995]. Honestly, you can run your life with these three simple but powerful checkpoints. Personally, if I’m given any significant job to do, I make sure that:

  • Firstly, I confirm my understanding of what I need to achieve, and when by
  • Secondly, I list my biggest worries – what that might cause me to fail and anything that I just don’t know how I am going to do or whether I can do it in time, and then I do the bits of the job that can resolve my uncertainties and relieve my worries (or rapidly prove them well-founded) and play back the resulting, decisions, outcomes and implications
  • Thirdly, I get my head down and get the rest of the job done

My three steps are, in essence, Barry Boehm’s three common milestones. The problem with great practices like this, though, is that in the past they have tended to be glued together with bits of other great practice to form monolithic, prescriptive processes. So, we find Boehm’s milestones inside the Rational Unified Process, but mixed up with a lot of other guidance about the project phases to achieve the milestones, sub-dividing phases into iterations (normally at least two-to-six weeks long), the activities we perform in each iteration and the documents they produce that we then use to assess the milestone. But, of course, it’s hard to produce documents and get them reviewed, reworked and approved in one iteration. So, before we know it, all our projects are spending one-to-three months messing around with Vision documents and the like before any code is cut (irrespective of how “nearly ready” they were to get motoring on day one of the project). Whatever happened to “cutting to the chase”?

It just so happens that the original motivation for Boehm’s three common milestones paper exactly matches the challenges we face today as we seek to empower software projects to use the practices that best suit them: “The current proliferation of software process models provides flexibility for organizations to deal with the unavoidably wide variety of software project situations, cultures, and environments. But it weakens their defenses against some common sources of project failure, and leaves them with no common anchor points around which to plan and control.” To get back to Boehm’s original intent, we need a way of characterizing the state that our project needs to be in, for example before it is right to start sprinting, that is independent of whatever the appropriate means of getting there might be.

This is where we come back to our software development kernel and the domain model at its heart. This characterizes the key aspects of a project that we need to progress (known as Alphas) and the states that we need to progress them through to advance the project in a controlled way to a successful conclusion (without the wheels coming off). To define a major project milestone such as Barry Boehm’s first “life cycle objectives milestone”, we simply need to list the Alpha states that we need to achieve for this milestone. For example, some key state progressions required for the Lifecycle Objectives Milestone are:

  • The Requirements are Shared (scope and value agreed)
  • The Team has its Mission Defined and (ideally) a team has been Formed to achieve the mission
  • The Implementation has an Approach Selected (e.g. the language / platform must be agreed)
  • The Project has its Milestones Agreed (roughly what needs to be done and when by)

Depending on how far off we are from being where we need to be, we can set ourselves a target date for getting there and select the appropriate practices to help us get there on time. On a simple project, with a clear steer, and a lightweight approach to confirming what we need to confirm (as described in the previous Kernel Journal), we can get there in hours or days, not weeks or months. And so cut to the chase!