Someday we must become professionals! by Ivar Jacobson

We software people run after the latest fashion.  Five years ago we ran after RUP, now we run after Scrum, and in five years we will run after something else.  At each transition we start over, failing to learn anything; we fail to keep what is working and improve what is not.   In my two latest blogs I have talked about how we can diminish the tiresome element of religion and fashion when it comes to methods and processes.  This is a precondition if we are to ever become software professionals.

The solution looks somewhat like this:  all methods have quite a lot in common.  After all, they are all used to develop software, and there are certain things that always need to be done when you develop software.  Let’s call this the “kernel”, a kind of elementary process which is the mother of all methods.  With this kernel as a base all methods can be described in a uniform way, as extensions to this base.

An important insight is that every method is a soup of practices, whether or not the practices are explicitly called-out.  For example, RUP consists of many integrated practices, while Scrum essentially consists of only one practice.  Scrum is about project management, so for simplicity we call this practice Scrum.  Both RUP and Scrum also contain a number of important patterns, such as Scrum’s agile work patterns.  However, for simplicity we will leave these patterns for another day.

The kernel is used to describe the practices of each method you care about.  The kernel clears away the cosmetic differences such as the same thing being called by different names in different methods.  For example RUP talks about iterations whereas Scrum talks about sprints, but they really mean pretty much the same thing. By doing this we can clearly see the real differences between different methods.

In the long term, doing this for the most well-known methods around the world, we would as a result have practices harvested from these methods in a practice library.  We would have practices that overlap, e.g. iterations from RUP and Scrum.  We would also have practices that complement one another, e.g. use cases and Scrum.

What is the benefit of this?

You won’t need to throw out what you have but you improve your existing way of working one practice at a time.  You would start by looking at your existing way of working as a set of practices. Then you look for your pain points and complement your existing way of working by removing your practices that are not working and replacing them with practices that you think will remove the weaknesses.  Once you have understood the kernel and its usage, this is usually all done in less than two days with an experienced consultant.  In a large organization with many different ways of working, you can use this approach to successively improve each way of working without forcing everyone to use the same method or process.

This approach will make it easy to adopt new practices without having to change the other practices you have.  Imagine that you already introduced the kernel and described your practices a couple of years ago.  Then you would be able to introduce Scrum easily by replacing your existing practice for project management by Scrum without having to make any major modifications to your other practices.  Looking into the future, Scrum will most likely be replaced by a new practice, and you will be able to do that easily, too.  That is very smart.

3 Comments
  1. Craig | December 9, 2009 at 11:56 pm Reply

    avatar

    Ivar, have you published your Kernel?

    Cheers
    Craig

  2. Ivar Jacobson | March 18, 2009 at 8:10 pm Reply

    avatar

    Sorry for my late reply, but I have been traveling a lot lately.
    The kernel has four kinds of elements:
    1) Things to Manage or Produce, such as Opportunity, Specified System, Implemented System, Executable System, Team, Backlock, Project and Way of Working.
    2) Things to Do, such as Understand the Need, Ensure Customer Satisfaction, Accept the System, Specify the System, Shape the System, Implement Software, Test the System, Release the System, Establish Project, Steer Project, Support Team, Conclude Project.
    3) Competencies: Customer Representative, Analyst, Developer, Tester, Project Lead.
    4) Patterns to Apply, and here we have all the agile work patterns, modeling patterns, process improvement patterns, etc.

    Thus, your suggestion was not far from the terminology we have chosen.

    Thanks
    Ivar

  3. Rolf | March 10, 2009 at 11:40 am Reply

    avatar

    Ivar,

    what are the activities (or “things”) in the kernel? Something like the following?
    Requirements, Prototyping, Design & Spec, Design Inspections, Coding, Code Inspections, Change Mgt & Conf.control, Testing, User Doc & project doc, project management?

    Capers Jones uses a 25-items list of project activities for estimation and measurement purposes, from wich the above examples are taken.

    Cheers!

    Rolf