Ivar Jacobson avatar

TechED by Ivar Jacobson

Barcelona is my last stop on an around the world trip that started Oct 17 from Stockholm. That morning I gave a talk to key developers at a key Swedish company developing key telecom products :). After my talk I rushed to the airport and flew to Tokyo to meet some key people from large software companies. After Tokyo I went to Taipei, followed by San Francisco and now Barcelona. This is my 6th around the world trip this year with one more to go before the end of year – three less than last year. As you can see I am slowing down.

Barcelona hosted one of the largest software conferences this year, the Microsoft Tech•Ed – Developer conference and yesterday I gave, together with my colleague Pan-Wei Ng, a talk on Next Generation Process (NGP). Here is the core idea of the talk:

The world of software development is constantly changing and evolving. New ideas arise all the time and existing ideas go in and out of fashion. Software development processes find it very hard to keep up with this rapid rate of change, especially as they find themselves quickly going out of fashion or becoming bloated as they bolt on more and more information. Teams find themselves struggling as they try to mix-and-match practices from various sources into a coherent way-of-working.

A new approach to capturing and sharing experience is required. In my company, Ivar Jacobson International, we have developed a fundamentally new way of managing software development that downplays the importance of process – in particular big process. Instead practices become important. A practice is a way of working with a clear beginning and a clear end. Following a practice should give a clear result of value. Instead of trying to give an academic definition, let me give some examples: Iterative development is a practice that you can imagine to use separately to how you specify requirement or define your architecture.

  1. Practices are First Class Citizens
  2. Practices can be made smart to truly help the developers in their work, this is achieved with WayPointer
  3. Practices can be used individually or in a multitude of combinations
  4. Process is just a composition of Practices, and
  5. Teams compose the process they need by selecting just the practices that they want to use

As you can see this is a paradigm shift. We move away from working with a big monolithic process (like RUP) to working with practices. Process is downplayed to just become a composition of practices.

To enable this, a number of innovations are required: innovations related to the way that practices are collected, presented and applied. We have developed two components to realize these innovations:

EssWork is a new set of tools for deploying practices in an organization. These tools allow you to author practices separately and to compose them to a process. They allow you to use a completely new way of learning, adopting, scaling up, and changing your selected practices. You use cards to describe your practices, to plan your project and to guide you in developing software. Cards are good because they force us to be very brief in describing process elements. You focus on the essentials, which makes practices very lightweight.

EssWork is available on top of several platforms: Eclipse, EPF, VSTS so you can have the same process independently from which vendor tools you use. On top of EssWork we have built a first set of eight practices called EssUP (Essential Unified Process).

EssUP is just a subset of all the practices we eventually will see on EssWork. Five of these practices are traditional Unified Process practices: use cases, architecture, iterations, components and products. Moreover, there is one practice which supports social engineering practices unique for agile methods, and one practice for process improvement derived from the process improvement camp such as CMMI.

However, we are not dogmatic about which practices you should use. You can replace any practice that we offer with a competing practice from your favourite methodology. You can also add practices that you have discovered yourself. Mix and match is our recipe.

Best of all: EssWork and EssUP are going to be Open Source! I can’t give a date, but it will happen as soon as possible.

The presentation was completely full (around 500 people) which was a fantastic result – there were people standing in the auditorium and watching on the remote screen outside So there is much to do going forward.

Various Podcasts were arranged. This is one:

UML 2.0 by Ivar Jacobson

For many years I travelled regularly to Japan. I became acquainted with many companies and many individuals. Several of my books were translated to Japanese so I got many “friends” there. However, since 2001 I have not been back to Japan, so I was very excited to return when I hit the ground in Japan two days ago.

I was invited to give a keynote at a UML conference in Tokyo. My presentation was on the Essential Unified Process with the Essential Unified Modeling Language, EssUP+EssUML. You already know what EssUP is from my previous postcards, but I have so far not described our work on EssUML.

UML was originally developed by a very tight team with Grady Booch, Jim Rumbaugh and I as members. We were nicknamed The Three Amigos – a term I never really adopted myself. Once we had defined what we wanted to achieve other methodologists from around the world were invited to participate. The core of the UML came from the work by the three of us, no doubt about that, but several other individuals made significant contributions. Grady, Jim and I had regular teleconferences in which most decisions were taken. We worked very efficiently. The first reasonably well-defined version of the language was UML 1.1 which was adopted by OMG in the fall of 1997, which was less than a year after we started to work seriously together. This must be a record for any kind of language standardization effort.

UML 2.0 was the next step in the evolution of UML and it was achieved in a very different way following standard OMG procedures. Now a committee with more than twenty persons took over. While we worked on UML 1 in an agile way, the committee worked on UML 2 in any other way than agile. At the UML World conference in Austin, Texas, June 16, 2005, during a panel discussion on UML, Steve Cook said something to the effect “UML 1 was excellent, whereas UML 2 is terrible.”

UML 2 is too big. Its specification is about 1,000 pages long! It includes many good ideas but it is written by tool vendors for tool vendors. No practitioner will read this specification.

There is a lot to be said about what happened in moving from UML 1 to UML 2. UML 1 needed a consolidation period for experience gathering and fine tuning, which it unfortunately never got. Instead the work on UML 2 started with a, too a large extent, new group of persons willing and wanting to change anything they didn’t fancy.

Grady and I were not involved in the UML 2 work. Many questionable changes were made. As an example, I found out that the committee had decided to change use cases from being what they always had been since I first introduced them to being something completely different. They claimed that I really didn’t understand what use cases were, and they had to fix it! Yes, this is a true story.

Once the decision to change use cases was taken, and I was informed about it, I wrote an email to the committee and expressed my severe concerns. I told them that I would not be able to support UML 2 if they changed the fundamental meaning of use cases. That email had no effect, the committee knew better! Thus I had to bring my concerns to top management at Rational. Rational made it clear to the committee that if changes of this nature were made, the user community would react very negatively and the reputation of the language would be seriously damaged. Rational expressed that this was unacceptable and more or less threatened to walk away from the UML 2 effort. Our two participants in the UML 2 committee were instructed to be very cautious with changes and to consult with a team of Rational experts before accepting any changes.

As you can understand this period was quite dramatic for anyone involved. There was a time when I believed I would have to publicly denounce UML 2. Fortunately, the UML committee came to their senses and I didn’t need to take such a dramatic step. Still, UML grew too much under the influence of a large committee. Today all UML fans suffer from this mistake.

However, at its roots UML is good. The basic techniques are proven as practical for many years. As an example, Ericsson could claim that it used UML already in 1969, because at that time we used component diagrams, sequence diagrams, collaboration diagrams, state charts and state transition diagrams (a combination of state charts and activity diagrams).

Thus on one hand UML has a sound base but on the other hand it has become too bulky. We know that with less than 20% of UML you can model more than 80% of all software systems. What we need to do is to extract these 20% that people need and define it precisely. We have started doing this and we call these 20% EssUML. EssUML is not a new language. It doesn’t even change UML. It is just a proper subset of UML.

EssUML is one more thing though. It presents UML in a way attractive to developers, quite unlike the UML 2 specification which intended audience is meta-modellers and tool builders. To achieve this we use a similar technique as when presenting EssUP. Every language element is represented by a card or a set of cards, and its description is usage centric (or use-case centric).

Now you may ask yourself, what are those 80% that we don’t need in the UML? In this case the expression “the devil is in details” could not be truer. The UML elements and their graphical representation in diagrams are simply overloaded with too many nice to haves that rarely are useful (or used). Essential UML is, as the name indicates, about extracting what is truly essential. What this exactly means in terms of diagram types and element types is a bit early to say but my personal opinion is that, e.g., Activity Diagrams (and all their associated element types and detail) do not qualify as essential. The experience is that it is not cost effective to develop and maintain this kind of diagram, especially if you also produce textual flow-of-events descriptions.

While they are not really defined as part of the language there is often (at least in tools) an artificial division into various types of structural diagrams, such as class diagrams, component diagrams, deployment diagrams, and package diagrams. I think this division often misleads people to believe that they need all these diagram types and that they are distinctly different from each other and that is of course not true. Anyway, going forward we will define this and also specifically what the 80% that we don’t need are. Every diagram and element type will eventually have a card describing its essentials, child elements, relationships and so on. In particular the card should focus on describing the use cases of the diagram/element.

As an example a card representing the component diagram (if we choose to have such a diagram type) could look like this:

Of course a card doesn’t contain enough information about the component diagram so we provide a guideline that goes a bit deeper. In most cases this is enough as developers will learn more as they use the diagram in practice.

The guideline is 2-4 pages and it describes the essential content of the diagram, its use cases, hints and tips and common mistakes. It also references the OMG specification and other UML books. However, in general developers don’t read much. There is a law of nature:

Law of Nature: People don’t read books

Over the years I have come to realize that even if people may buy books it does not necessarily mean that they read them. This is certainly true for manuals such as process manuals or language specifications. I believe we can get everyone in a team to read the cards. If we write really well we might get up to 25% of the developers to read the guidelines, but almost no one will read the books being referenced. Additionally we of course have to acknowledge that the Essential 20% varies a bit depending on the specific situation at hand, i.e., the underlying business reason for modelling in the first place can vary.

  • Are the diagrams/models key ingredients in driving the understanding and design as we go, or are they primarily useful as documentation to, e.g., the next project?
  • Is our intent to generate code for large parts of the system or do we model to simply illustrate key aspects of the system and its design?
  • What is the size, complexity and longevity of the product/project?

The answers to questions such as these will of course have an impact on the process we use and follow, the amount of documentation we produce, and of course how much and how detailed we model.

As you know, I am a strong believer in that intelligent agents is the most efficient way to capture and disseminate knowledge and that is of course applicable for practices as in EssUP as well as for technological underpinnings like EssUML. I strongly believe in having intelligent agents to provide context-sensitive advice and training on line. They can help you by performing mundane tasks, recognize design patterns that you may want to apply, review your work, etc. These are some of the things that WayPointer can help you with.

My keynote in Tokyo was very well received. I was invited to come back to this exciting city and I will be back real soon. It was five years since I was here the last time. As it looks like now I will be back almost every month. This is wonderful and I really look forward to it.

Meeting with Dave Thomas by Ivar Jacobson

Meeting with Dave Thomas

The weekend July 8-9, Dave Thomas visited me at my country house in the Stockholm archipelago. Some of you have already met Dave. He is a very dynamic and colourful Canadian. He is very popular in some camps and he is feared in others.

His great strength is really finding innovative, competitive solutions to people's business problems which can be solved by software; and assembling and motivating people to move towards a goal. He looks many years ahead at the business/competitive climate and navigates a path through to a goal. He uses the best things he can find to solve the problems and doesn't generally constrain his solutions to the practices or technologies that are popular or widely available. If everyone uses the same process, technology and tools then he doesn't see where one gets competitive advantage since everyone can hire smart people. Hence he seeks strategies which others don't see and competitive opportunities to use them. This is why so many companies have problems today including MS, IBM but also companies like Fujitsu, Samsung etc. Unlike Google for example they did not think out of the box, they just run hard. MS has a hard time to understand enterprise clients, and IBM doesn't really understand how to build and deliver software as a service. Smalltalk was successful because Dave made IBM do it (The IBM Smalltalk), and Eclipse is successful because Dave created a strategy to disrupt the tool market. This is his real strength, managing software is something he does for fun. :)

The first time he visited my country house was 1988. At that time I had founded Objectory a year earlier and we discussed what I should do. He strongly believed in my vision and technology. He gave me some advice which included the following:

You should write a book about use cases and objects – no more that 150 pages. Then that book will become a market leader. He saw my hesitation. I said something like software development is serious work; you can’t describe that in 150 pages. He responded, of course you can’t, but people want simple solutions, they don’t want complex books. And, then you can come out with an improved version every year, and people who bought the first version want to by every other version. :) This is how you create market leadership. Of course, I should have done as he suggested.

Dave and I had a great time together at my country house as you can see from the photo below.

We did some good work together on EssUP and NGP as this picture shows: 

He likes our work and he will help us communicate it in the software community. I will write again about the specific results of the meeting which will come in the next few months.

EssUP Launches by Ivar Jacobson

Yesterday we launched Essential Unified Process in the UK. We had around 180 attendants and these were all invited by us. We wanted participants that could help us understand if we are on the right path.

I think we can count this event as very successful. We all felt very upbeat afterwards when we met at a pub.

In the picture above I am the guy who gesticulates. The others are from left to right: Agneta Jacobson (CEO of Jaczone), Pan Wei Ng and Ian Spence (both Chief Scientists of Ivar Jacobson Consulting) and Chris Littlejohns (managing director of Ivar Jacobson Consulting UK).

The most central idea behind the Next Generation Process (NGP) is that Practices are First Class Citizens and Process is just a composition of Practices. This is then followed up by three innovations (in no particular order):

  • Practice Separation and Composition. This is an idea I first presented at the Agile Conference in New Orleans in August 2003.
  • Practice User Experience using the card metaphor to move the focus to the developers away from the process engineers. This idea originates from Brian Kerr at Ivar Jacobson Consulting in the UK.
  • Practice Smartness using intelligent agents to make process active. This comes from Jaczone’s WayPointer.

Essential Unified Process is a first incarnation of the NGP. It is a package of practices…8 to be exact. It could equally well have been 5 or 10, the most important things are the practices and not the package. Apart from the three major innovations mentioned earlier, there are many other ideas in what we mean with NGP. We have alphas and betas, competencies instead of roles, aspect-oriented thinking, how we make EssUP agile with social engineering practices, etc. Ian Spence showed how we have created three games to play the cards. There is a process assembly game, a process planning game and a project game in which the team actually develops software. (We have a paper to be published in August in Dr Dobb’s Journal). Today, on the surface RUP is hardly recognizable in EssUP (but of course EssUP is a great way to move to RUP; it is also very easy to move a RUP customer over to EssUP).

NGP Infrastructure has been developed to prototype status. Pan Wei Ng demonstrated navigation through practices, authoring of practices and cards, composition of practices. I think it is fair to say that the audience was very impressed getting a glimpse of NGPI. Many people came up to me afterwards and said that our work on NGPI really gives us credibility. EssUP with physical cards is a good start. With an electronic version of the cards we give the card metaphor a face in the tool world. I believe that NGPI helps us to move people from being excited about EssUP to wanting to plan their first EssUP project, something our launch proved.

WayPointer is now a mature and proven product. Several persons came up to me and said that the latest version is a big step forward. WayPointer is already very effective when it comes to to the complete adoption of software development best practices by a team. With our practice-centric approach another role of WayPointer becomes evident. For each practice we can now offer cards and guidelines with the most essential knowledge and as additional leverage provide support from intelligent agents to help people both with the cards/guidelines but also with all the other more specific and context sensitive advices that are made explicit in books or elsewhere. WayPointer will of course also provide automation and real-time quality checks for the practices. Together these components provide an unprecedented framework for process dissemination. The story starts to get together in a wonderful way.

We have a fantastic story. People definitely see us as The Thought Leaders on Process. However, this is not enough for us. We don’t just want them to see us as thought leaders. We want them to come to us and ask for services and products. Thanks to our very strong team we can deliver that.  

A Practice Approach by Ivar Jacobson

I have just left the RSDC 2006 in Orlando. This was my 10th Rational user conference. It is my favorite conference because I always meet many friends from my days at Rational – both customers and colleagues. And this is where I introduce the latest thinking of our team on software development practices – including people from Jaczone and people from Ivar Jacobson Consulting.

This year I presented our work on Next Generation Process and its first incarnation: Essential Unified Process. Essential Unified Process is just a package of separate practices. Some of them are well-known to those of you who are familiar with Unified Process or Rational Unified Process. We have given these practice names like: Component, Model, Iteration, Architecture and Use Case. However, we also have some new ones. One is about Process Improvement, helping you to achieve many of the values with CMMI. Another one is the Team Practice which is about social engineering or with a more modern word: it is about (the core of) agility.

Much of my understanding of teams was formed many years ago as a soccer player. As very young I was a passionate player. I was playing soccer every hour awake. I was also coaching several teams at the same time as I was an active player. Soccer has always fascinated me. It is played almost in the same way all around the world. Millions of people can play it and billions understand and enjoy it.

There are many similarities between playing soccer and a project, such as developing software. At the core of it is the team. Even if the team consists of individuals, the individuals must be team players. The values of the team have in both cases an enormous impact:

A soccer team consists of eleven players. A player has some competences such as goalkeeper (one player only), defenders, midfielders and forwards. A player that is a good forward is usually not a good defender.

The soccer team also has some other members; the most important one is the coach. The coach doesn’t play himself, but has an important role in creating the team. Typically, a coach is someone who once played soccer himself but has grown and matured. (Are there any similarities to software? :)) He is a leader and makes the team adopt important core values. He selects the players to make up the team. He sometimes has to make hard decisions abstaining from top individuals because they aren’t team players – they don’t buy into the core values. In professional soccer, the coach is the buyer of players from other teams. It is clear that not all players have the same price or the same salary. The difference may be ten- or hundredfold. And that is a manageable problem in team building.

However, while preparing for, playing or learning from a match, we are all members of the team. Although we are aware that the team is made up of individuals and that it is individuals that make heroic achievements, the success of the team is dependent on the whole team and that every member of the team is doing a good job. It doesn’t make sense to say “We forwards were very successful today by scoring three goals. However, they (the defense) were not doing well; they let in four goals.” We are all part of the whole. We want to be proud of the team. There is an expression Proud People Perform which is very applicable here. No one is more important than anyone else. We respect one another, we help, we make mistakes, we repair them and we move forward. The goal is to win, to succeed – to loose, to make a failure is out of the question. We take precautions to get to the right place.

What I just described could equally well have been practices adopted by a software team. There are many good patterns in modern software development that are incorporated in the Team practice, and more will come.  

Essential Unified Process by Ivar Jacobson

After two very intense days in Ottawa I am on my way to China, Taiwan and Korea. Two intense but very memorable days. In Ottawa I gave two talks on the Essential Unified Process, the first to Statistics Canada while the second was a public seminar arranged by IBM Rational Canada.

The welcome I got at Statistics Canada was mind-blowing. Andrew Konecny who organized the event compared it to when Rolling Stones visited Ottawa in the summer of 2005: Sold Out. Around 250 persons attended the seminar and the introduction that Andrew gave was most memorable and made me feel very welcome. Every attendant got a black T-shirt with the logos of Jaczone, IBM Rational and Ivar Jacobson Consulting on the front and a listing of all my postcards on the back. It was really fun.

I presented the Essential Unified Process. So what is it?

The Essential Unified Process stands on the shoulders of modern software development practices. It is a fresh start integrating successful practices from three camps: the unified process camp, the agile methods camp and the process maturity camp. Each of them contributes different capabilities: structure, agility and process improvement.

The Essential Unified Process is very different from other processes or methods in how it is presented. It relies in many ways on a new idea: Separation of Concerns (SOC or aspect-oriented thinking). When you apply this general idea it will be dramatically simpler to work. It will be much easier and much more pleasant to select your tailor-made software process. Most important, it will be more natural and intuitive to plan and execute a software project. To make this concrete let me describe a number of situation where we have applied the idea of SOC:

  1. The Essential Unified Process separates the essentials from the non-essentials. This allows us to create a core lightweight process with unprecedented growth potential. We have learnt over the years that very few people really read process materials whether it is in a book or on the web. Therefore it doesn’t make sense to give them a lot. Instead, provide the real essence and let them learn the rest the way they want. Some may want to learn it by studying and there are a lot of articles and books available to do that. Some will learn by working with people who have already gained the knowledge. The effect of this separation is that the process will be very light and easy to adopt and change.
  2. Each practice is kept separate from other practices. The Essential Unified Process comes with the essentials of our five foundation practices:
    1. Component Based Development,
    2. Model-Driven Development,
    3. Iterative and Incremental Development,
    4. Architecture-Centric Development and
    5. Use-Case Driven Development.

These practices have been used in 1000s of projects and proved to be very successful. By keeping them separate, we can simplify the process description dramatically. The process description is presented as a set of individual practices. Each such practice can be developed, adopted and applied separately from the other practices. This is a significant difference compared to the Unified Process where all practices are intertwined. Moreover, you can easily select only the practices you need without having to deselect activities and artefacts. You just select the practices you want and compose them with your already existing process.

  1. You can easily separate elements from your existing process from the elements of the Essential Unified Process. This allows you to improve what you already have, one practice at a time in an evolutionary way. You start from a generic platform and describe your own process using a very simple technique inspired by the game industry. Based on this we can add our practices without requiring a revolutionary adoption of all our practices. You take what you need and what you think your organization can adopt without taking any severe risks.
  2. It separates two different views of the process: the process authors’ view and the software developers’ view. In the past processes have almost entirely focused on the authors’ needs. The Essential Unified Process prioritizes the developers’ perspective. It uses techniques from the game industry to develop, teach, apply and use the process to make it lightweight and agile. And, I promise, much more fun.
  3. It separates explicit knowledge from tacit knowledge in a balanced way. Tacit knowledge is knowledge you acquired one way or the other – you have it in your “head”. Explicit knowledge exists in the form of descriptions made available to you. In the past the Unified Process tried to capture all knowledge in explicit form. Though this is a good ambition, it makes the process heavy. The Essential Unified Process makes only the essentials explicit. The rest is either tacit or referenced from the essentials. However, the most elegant form of dealing with knowledge is to deliver it through intelligent agents when needed – this is what we call a smart process. As you all know, WayPointer is the first commercial product that makes smart process available.
  4. It is prepared to separate creative work from no-brain work. This will allow developers to spend their time on what humans are good at – being creative – and leave the no-brain work to intelligent agents. Once again, this is made possible with WayPointer.

Our long term vision for the Essential Unified Process and WayPointer is to move from a ‘process’ era when everyone is forced to think about process to an ‘invisible process’ era, a time when we don’t talk specifically about process but take it as a given.

Now you may wonder: Does WayPointer support the Essential Unified Process? The answer is indisputably; YES! WayPointer already today supports the core of the foundation practices. Over time as the Essential Unified Process grows WayPointer support will grow too. As an example, the first released practice, “Use Case Driven development” is fully supported in the upcoming release of WayPointer. 

A Visit to Costa Rica by Ivar Jacobson

I have just had some fantastic days in Costa Rica where I was invited to speak at an architecture conference sponsored by Microsoft and Club Investigacion Tecnologica. My speech was about the Essential Unified Process which I will tell you more about it in another postcard. Today I want to tell you about a completely new experience for me: the canopy.

Yesterday, I got up early to go to the rain forest. My driver Luis picked me up at 8 am and we drove for three hours to get to a large and active volcano. We were lucky. The volcano roared just as we got out of the car for a view of it. A roaring volcano is frightening and it makes you feel very small. It spit out huge blocks of stone rolling down the slopes with tails of white dust. When the volcano had spoken it became so quite that you could hear all kind of sounds that were new to me. Monkeys were hi-hoing to one another, birds were calling one another and Luis told me it was time to move on.

We came to a farm where Luis put me on the back of a horse and then he said “goodbye, see you in the evening”. The horse took me on a one hour ride in the company of other horses -- with attached tourists. I am not a rider. I have been on a horse twice before. The first time the horse started to gallop, and since no one had told me how to steer, it ran straight towards a big fence. The horse was smart; it didn’t run into the fence but stopped just in front of it. However, I didn’t stop. That could have stopped my career. :) 

From now on my horse was very kind. He knew he had a bag of flesh on his back and that he needed to keep that bag from falling off. Nevertheless, I had a tough time to hold on to the horse and it was all very painful. The saddle was as hard as if it was made of steel. I am glad I was not on a two week tour, but just on a one hour trip. My lower body was in severe pain, the skin was gone and I could hardly walk, sitting was out of the question.

I didn’t need to sit though, because now we had reached the canopy. In the rain forest wires about 1.5 cm thick were stretched from one point to another, lower point, about 900 meters away. The idea was for me to slide along the wire from the higher point to the lower point all about 60 m above the ground. I got a harness on my lower body which was attached to a rail via a strong elastic rope. The rail was to slide on the wire. I also got a one cm thick glove to control the speed and to keep my body from rotating while sliding.

Before going on this trip people had told me that some people never get back from the canopy so don’t go. Well, saying that was the best way to get me to do it. Scary? Yes. However, once on the wire it was fantastic. It was a new experience, like skiing or snorkeling the first time. I loved it. The area had 10 such wires and I did them all. Afterwards I was very relaxed and enjoyed a great dinner with a view of the sunset over the beautiful volcano. In his ambition to make me happy Luis had even invited a young Finnish tourist to share dinner with us. I was too exhausted to pay her any attention, so Luis had to entertain her himself. In fact he did that so well that he totally forgot about me and I could drop off on our way back to the hotel.

I really want to come back to Costa Rica to again meet Luis, Jimmy, Roberto and all the new friends I made.  

Being Agile by Ivar Jacobson

Rational’s Software Development Conference 2005 is over. It has been a very exciting week. I must admit I am a bit exhausted. The days were packed meeting customers or giving presentations. The nights became very late having fun meeting friends – both old and new.

Jaczone and Ivar Jacobson Consulting shared a booth and it is no exaggeration to say that we got a lot of attention. “I was really taken with the crowd at the spotlight theatre presentation by Dr. Ivar Jacobson and the demo of WayPointer. Standing room only and it wasn't even lunch time!" said Buell Duncan (General Manager, IBM ISV & Developer Relations). At this theatre presentation Tata Consultancy Services announced their work with WayPointer to make their own process active. TCS reported a more than 20% productivity gain (!), increased quality and ease of learning using WayPointer.

Jaczone and IJ Consulting gave a total of 5 presentations, all very well received. My own presentation was titled “Beyond Agile: Smart” – a thought-provoking title. This is a talk that has been cooking for more than a year. I still was not sure about how it would be received.

- o -

Today everyone wants to be agile. It is pathetic to see how basically every speaker has added the word agile to the title of their talks. I haven’t done it. I haven’t done it, for two fundamental reasons.

All my work over the years has, as I soon will explain, strived to make software development more agile.

  1. Agile is not enough, we need more. I want agile+++.
  2. What I actually want is to get smart software development. That is why the title of my talk was “Beyond Agile: Smart”.

Thus we all agree that we need agile software processes. We all agree with the four statements in the agile manifesto. We agree on many agile principles such as iterative development, continuous integration & testing, use only what you need, etc.

However, we have different ways to get there. The so called “agile methods” primarily rely on tacit knowledge. Tacit means implicit knowledge (achieved ad hoc and undocumented). The Unified Process relies primarily on explicit, structured knowledge. This is a big difference that has not come through in the debate. In previous postcards I have discussed this difference, see for instance my postcard from 2004, September 30, Minneapolis.

This postcard is to some extent a repetition of what I wrote then but I will also talk about some new stuff. I will clarify the difference between being just agile and being smart with four new manifesto-principles. I will extend the concepts of pair programming, as in XP, to many other kinds of pairs such as pair architect. However these pairs will be virtual pairs assisting you with knowledge and making you smarter. We will get there soon.

A process or a method being agile to many means that its definition (description, book, web site, etc.) is light, i.e., it is sketchy. Thus when working according to it in a project, you have to use tacit knowledge and therefore the project is agile. This may be true in many cases, but in larger organizations you usually have a lot of people with different tacit knowledge. This creates a lot of difficulties working together. People need guidelines in the form of explicit knowledge to work consistently and create good software. Thus, a very important insight is that: 

   A light process may make a project heavy.

We also know that too much explicit knowledge such as in the Unified Process (UP), can make projects heavy, if they have to select what to learn, learn it, apply it and update it with new explicit knowledge as they learn more.

However, if we in some “magical” or say smart way dramatically can reduce the work to select, learn, apply and update the knowledge in UP, the situation will be different. If we can deliver the knowledge you need, and only that knowledge, and exactly when you need it and not before, then the size of the process doesn’t matter. Whether the process “book” is 100 pages, 1,000 pages or for that matter 100,000 pages will be irrelevant for ease of use. Thus, the more the better! You will only get just what you need and when you need it. And the bigger book, the more real on-line mentoring you will get.

This is what we can do with intelligent agents. Every developer has an online agent, or as we say, a virtual mentor. The virtual mentor is able to select what you need know, teach you exactly that, help you apply what you learnt and learn itself from your experience. With WayPointer we have proven that this technology really works. Much more will happen in the years to come, but already today, as experienced by TCS, substantial increases in productivity, quality, user experience, etc. can be made.

XP talks about pair programming. With these virtual mentors we talk about:

  • Virtual Pair Programmers
  • Virtual Pair Analysts
  • Virtual Pair Designer
  • Virtual Pair Tester
  • Virtual Pair Project Managers
  • Etc.

A process supported by intelligent agents, such as the Unified Process with WayPointer, is much more than an agile process. It is a next generation process. It is beyond both agile methods and traditional processes such as UP. I call such a process a smart process.

A smart process is agile (as defined by the agile manifesto) but it is also more. I have formulated four manifesto-principles to define a smart process and I call them Manifesto for Smart Software Development:

  • Make well-known knowledge explicit over keeping knowledge tacit
  • Active process over passive process
  • Let models be code over letting code be models
  • Team capability over dependency on individuals

I am not sure that these four principles will be the most important, but they work for now. I can’t see that methods or processes that primarily rely on tacit knowledge ever can compete with smart processes. Together I hope we can make the software world smarter and not just agile.

If you want to keep up with how our work on smart methods evolves, sign up on www.ivarjacobson.com and we will keep you informed. 

A Long Trip by Ivar Jacobson

I often get the question if I have any jetlag travelling as I do. It is understandable that people ask about this. After the Rational Software Development Conference 2005 a month ago my schedule became hectic. I will give you a résumé of my travelling. Unfortunately, I can’t be specific when it comes to business meetings.

May 26, Thursday evening I left RSDC’05 in Las Vegas and went to San Francisco.

I spent the weekend in SF to work and meet with friends.

May 30, Monday Redmond, Seattle

May 31, Tuesday Minneapolis

June 1, Wednesday I went to Chicago to board a flight to Stockholm, Sweden.

June 2, Thursday I made visa arrangements for India and I met my family in the evening.

June 3, Friday I left for Mumbai, India. I arrived very early Saturday morning and spent the weekend sightseeing and swimming in the pool. I love Indian food so it was relaxing. June 6, Monday Agneta Jacobson (CEO of Jaczone) arrived late Sunday night. Together, we had customer meetings the whole week. Monday and Tuesday in Pune, Wednesday in Mumbai, Thursday in Bangalore and Friday in Chennai. Late Friday night I went to Singapore and then continued directly to Seoul. I arrived late Saturday afternoon. I spent the Sunday in Seoul trying to recover (by reading emails).

June 13, Monday IJC Korea participated in the KCIC conference, a kind of component consortium. I gave a keynote on Unifying Foundation and one of our Korean consultants Jung-Nam Kim gave a talk about our approach to components. We also had a booth which was very visible. The conference was quite successful for us, so now our team has a lot to follow up on. In the evening we had a great dinner at an Italian restaurant. We all felt a little upbeat.

June 14, Tuesday I went to Beijing and I had a great dinner with a few people from a customer of ours. They have tried to adopt RUP on their own so now they are ready for our help!

June 15, Wednesday we participated in a large software conference in Beijing. I gave a keynote on the topic “What you don’t get from CMMI: Good Software”. The talk was very well received and we got many leads to work with. Before my talk I had two interviews with Chinese weekly magazines.

After the talk I went to the airport to fly to Austin, Texas via Chicago. A very long trip.

June 16, Thursday I attended the UML & Design World conference and I gave a keynote on the subject “Beyond Agile: Smart”. Before I started my presentation I said that today I will tell you about the greatest mega-trend you ever have seen. Last time the world saw something similar was in the mid 50s when we got (passive) software. All my work on Component Based Development, use cases, UML, RUP and aspect-oriented software development is important but just micro-trends within the passive software mega-trend. Active software is a coming mega-trend. After my presentation I asked the audience if they agreed with me that what we are talking about is a mega-trend. I was surprised to see that as many as 50% raised their hands!!! I also asked how many didn’t agree and about 10% raised their hands. At the least my talk created an interesting discussion. A lot of people came up to me afterwards and expressed their gratitude.

After the keynote, I participated in a panel on UML, specifically why UML adoption rate is so low. Only 10% of the developer community has adopted UML. My explanation is that we don’t have really good tools and that UML is too complex for most people to learn…we need smart tools. The most interesting comment came from Steve Cook, now with Microsoft, earlier with IBM. He suggested that UML was very good but UML 2.0 was bad. He meant that the core ideas of UML are excellent. He went on and suggested that we restart the work and build a small subset of UML that we make available. The rest can be added in domain specific languages. Steve, I hope I got you right. Then one of the other panel members (Randy Miller from Microsoft) said that the Objectory tool was many years ahead of the tools when it was available in 1995. [In fact, I think, Objectory supported this small subset of UML features that we need, but ignored much of the nitty-gritty details.] Randy said in public that no tool has yet become as good as the Objectory tool in 1995. I have heard similar things many times. Anyway, forming a core of UML features could be a great thing. I believe the same is true for the Unified Process. Make it simple to understand the core. We can add more with technology such as WayPointer.

In the evening I went via Denver to San Francisco. I was working on emails and business stuff the whole weekend, but Monday I took a day off to go to Napa Valley with friends.

June 21, Tuesday I went to London to meet customers and to give presentations.

June 23, Thursday night I went to Sweden to celebrate a Swedish Midsummer.

Today Friday June 24, is Midsummer Eve. This is a day we celebrate with friends and family.

Next week on Tuesday I will go to Beijing and on it goes.

Do I have jetlag? No, because my body never really knows what it means not be jetlagged!  

CMMI by Ivar Jacobson

May 19, 2005


This year has been very exciting so far. I have traveled around the world four times and done lots of additional local flying (such as flying around in the US, in Europe or in Asia). There is nothing as rewarding as making other persons successful, regardless of whether these are customers or individuals in my companies.

Today we launched Ivar Jacobson Software (IJS) in China. This took place in Beijing where we have our Chinese head office. In the morning we held a high profile press conference. More than twenty reporters, more than ten Chinese government officials, and many locally renowned scholars and researchers attended. I held a talk titled “From Vision to Impact: Transforming Software Development in China”. I outlined a vision for making Chinese software development more competitive internationally, analyzed the reality of change and demonstrated how we can help.

Then an exciting moment came. I was asked to remove a cover from some hidden object, and boom: a balloon exploded and thousands of colored paper chips filled the air. The mood in the room rose to a climax and out from below came the company plate, see picture below: 

During the press conference, representatives from Chinese government and our partner IBM Rational delivered their welcome notes to our opening in China. Last but not least, IJS and CVIC SE (a local Chinese software company) signed a memorandum of understanding on building a business partnership.

This shows the Chinese software community that we want to build mutually beneficial partnerships in China.

In the afternoon, we held a public seminar. More than 150 software individuals, from different parts of the software community attended. I talked about “What CMMI cannot give you: Good Software” – a thought-provoking title.

- o -

The whole CMMI thing is based on this so called “law of quality”: The quality of a product is largely determined by the quality of the process that is used to develop and maintain it.

I think Deming discovered this law around 1950. And he had great success in Japan by improving the quality of manufacturing processes. There are a few things that are vague in the above law when it comes to software development.

First, what is quality in software? The quality of software is a much broader concept than that of common goods, such as automobiles. The quality of software has gone way beyond defect rates. (It seems though that many still haven’t got it.)

Second, manufacturing and software development are of different nature. There have been lots of debate on this topic and no common understanding has been reached so far.

Third, how large is largely? In what dimension? What if it doesn’t help the dimension (getting good software) I care about at all? That is exactly the case with CMM & CMMI.

The Chinese government has in a very direct way supported its software industry to adopt the Capability Maturity Model CMM/CMMI. They have done so inspired by the success of the Indian software industry. The Chinese software industry hopes to attract foreign companies to outsource software development to China by being able to offer high quality software and skills to low cost. As an effect many Chinese companies have made substantial investments in moving their people to higher levels of CMM, some companies even to CMM level 5. However, this has not resulted in western companies significantly moving their business to China. Why not?

CMM/CMMI focuses on describing the way you develop software and it helps you measure it. However, it basically doesn’t care about what kind of software you get from your process. Why should any company - from the west or from the east - care at all about how you internally develop software for them? Well, maybe they should care a little bit, but not much. However, what they really should care about is if they get good software or not. Good software is many things. Some of the most important things are that the software must meet business requirements, that it gives great user experiences and that it can gracefully change for the life-span of the business (that is for ever). CMM/CMMI is silent about what to do to get good software in these respects. This explains my title of the talk: “What CMMI cannot give you: Good Software”.

In fact CMM/CMMI can have an opposite effect on a software development organization than the desired one. It can reinforce a process that results in bad software and thus make it harder to introduce a process that results in good software. Jokingly, I sometimes say that this is analogous to paving cow-paths. You get better cow-paths, but you will still have cow-paths instead of roads. Therefore the right way is to first identify a process that is proven to produce good software and then introduce CMM/CMMI. If you do it this way you will get good software and you will produce the good software in a way that can be improved and measured.

My final words were (please remember that a good process is a process that results in good software):

It is easy to make a good process measurable,
but it is hard to make a measurable process good. 

Page 6 of 812345678