Unified Process

There are practices and then there are Practices by Ivar Jacobson

The software development community has been talking about practices in an informal way for a very long time - more than 50 years. In the way the community talks, a “practice” is just something that people do, a habit they have that may be good, or perhaps not good. Talking about practices in this way makes for good conversation, but it is hard to figure out how to combine good practices into something meaningful.

I like to talk about practices in a more precise way, so I will refer to these as Practices (with a capital ‘P’). With a more precise definition we can do some interesting things: we can combine them (or compose them) in interesting ways, and we can separate them to allow us to replace a practice with a better one. Read More

by Ivar Jacobson

What they don't teach you at institutes of technology – how to be smart

I am slowing down a bit this year.  For many years I have made more than ten around-the-world trips and lots of local traveling, but this year I have made only eight. J  During this time, I have given a dozen keynotes and more than fifty other kinds of talks.  I am often invited to universities or institutes around the world, and I have been offered professor jobs, surprisingly even in Sweden.  Thus, I feel I have quite a good understanding of what they teach you about software.

Interestingly, most professors in software have never built any useful software.  This is natural since they have grown up in the academic world where software engineering is not as fine as computer science.  Of course, this is not true for professors in your part of the world, but elsewhere. J  Thus, most professors can’t possible teach in software engineering with any passion.

As a consequence new ideas about software engineering have come from practitioners around the world.  The best ideas come from practitioners with an appreciation of science, people that agree with Kurt Lewin: "There is nothing as practical as a good theory".  Examples of good theories were Newton’s laws, and Einstein’s relativity theory.  Most research represents useless theories.  Of course, this is not true in your part of the world. J

Personally, I adopted this motto thirty years ago and it has been leading my work all these years: components, use cases, Objectory that became RUP, SDL and UML, and now practices.  Many other people such as Kent Beck and Ken Schwaber have made similar contributions.  This is the true essence of software engineering and it stands on a sound theoretical basis, meaning it can be explained so others can understand it and practice it.  But, very few universities teach it and even fewer do it well.  As I said, this is of course not true for universities in your part of the world. J

However, these exceptional institutes that teach you software engineering practices don’t teach you how to be smart when working with these practices.  And this is fine.  I am happy if they teach good practices, but to provide real value, each practice needs to be applied in a smart way.   The software industry has the capability to help itself in this regard, but I really don’t see that happening.

Smart is about being agile, but it is also about doing the right things, the right way.   You can become smarter through training one practice at a time.  However, without experience your alternatives are too many and only a few of them are smart.  Experience is of course something you can get sooner or later, but it takes time if you must learn by your own mistakes.  This is where the utilization of what we call “smart cases” becomes essential.  We have a large number of smart cases that relate to working with people, teams, projects, architecture, modeling, documentation, testing, process, outsourcing, and many more. 

Each smart case has a key motto for how to be smart, for example:

·       People:  Software is developed by people, not by process and tools.

·       Teams:  A software team is like a sport team with all needed competencies to win.

·       Project:  Think big, build in many steps.

·       Architecture:  Start to build a skinny system, add muscles in later steps.

·       Testing:  Whatever you do you are not done until you have verified that you did what you wanted to do.

·       Documentation: Focus on the essentials - the placeholders for conversations – people figure out the rest themselves.

·       Process: Don’t throw out your baby with the bathwater: start from your existing way of working, find your pain points and change one practice at the time.

And on it goes.

All of this to say, we should learn software engineering practices at school.  We should shorten the time to get experience of practices by collecting reusable smart cases.  We have started this.  We hope others will contribute.  I think that would be smart by the industry. J

The problem with templates by Ivar Jacobson

Over the years I've come to regard 'templates' as one of the great evils of software process efforts. I was actually leading the Rational Unified Process team about 9 years ago when we made a big push to create templates for all the artifacts.  At the time I thought it was a good idea since a lot of people had been asking for them. I now regard the decision as having done a lot of damage.

 That statement is likely to shock some - surely I can't be arguing against having standard formats for organizing project information!  Of course I am not arguing against this - but I am against the way that templates are used in many organizations.  

In these organizations, people have little idea of the purpose of many artifacts or work products - they don't understand what they are doing or why, they just know (or believe) that they need to produce these work products.  The templates have been provided as a cheap way of rolling out the process - rather than actually building skills the templates are provided and people are instructed to simply fill out the templates to follow the process.

This approach is wholly ineffective. Organizations fail their people when they require artifacts without explaining why they are needed, or helping them to understand if they are needed, or helping them to improve their skills doing the real work that the artifacts merely document.

The usual result of providing standard templates is that people often blindly fill out the template sections, not knowing what to put in them, feeling compelled to fill out every section because it's there.  Mindlessly filling out templates is a waste of time - the results are valueless, albeit standard, and do not contribute to positive project results.  

I am not arguing for eliminating templates, however - there is some value in having a standard way of formatting and organizing information, but there needs to be some real information in the results produced.  The real problem is lack of knowledge and skills needed to do the work - this is where effort should be spent, not in standardizing templates.  Once people have expertise in doing the work, a consensus can be reached in the organization about how to document the work.  "Templates" will emerge out of that.

Yes, RUP is my baby by Ivar Jacobson

 I often get the question:  “RUP was your baby, but how do you look upon RUP today?”  In an interview a couple of years ago I responded jokingly: “Yes, RUP is my baby, but you know babies grow up and some of them need correction.”  RUP was created in Sweden under the name Objectory.  This was in 1987. 


Objectory was really new since its base could be used to describe all aspects of software development.  Our focus was to identify all of the rules that we use when we develop good software: what are good use cases, good components, good test cases, etc.  The literature in software engineering was totally empty in this space at the time. In order to do this we used object modeling to describe Objectory.  Now we could let the base grow forever – technically speaking.    Any company could make their own new process using Objectory.


Objectory became very successful.  It survived the merge with Rational in 1995.  The next version was named Rational Objectory Process, but after the success of UML, the name was changed to the Rational Unified Process or RUP as we all know it.  In the work of merging the two companies, the process content grew significantly.  However, hidden behind the size, our innovation of how to create a process base and the rules for goodness survived.  The crown jewels of Objectory had survived!


Thus, RUP is one of my babies.  The challenges with Objectory and consequently with RUP were serious. 


  1. Adoption
    Although our way of working in creating a process base was new and great, adoption became quite expensive.  To truly be successful with the adoption and consistent usage was to involve customization, mentoring and consulting which most customers couldn’t afford.  Thus the success rate was too low.
  2. Growth
    RUP was developed inside one company and all new ideas from the outside world had to be filtered by our own people and added to RUP.  It goes without saying that ideas come from anywhere in the world and by having a process be company owned makes it difficult to assimilate these great ideas.  The use of community much like what has been done with open source models would allow for continuous input and improvement.  This also allows for scrutiny. 
  3. Execution 
    All processes are paper-ware and often managed by people who don’t use the process.  This quickly becomes a problem in most organizations because the process becomes a religious document and not a realistic one.  This then has the effect that what teams do and what the process tells them to do is often not in synch.  And since the team is in charge (doing the work) the value of process becomes small.


These challenges paved the way for the agile movement.  The different agile methodologists have one thing in common: they hate RUP.  But that is NOT very smart. There are lots of good ideas in RUP.  Many companies have made the effort in adopting RUP and done so quite successfully.  This has provided them with a very competent staff and something to build on for the future.


However, “the baby needs correction”, and I and my company have done so.  The adoption problem is attacked by focus on the essentials and being light instead of trying to be complete.  We use cards and game boards to describe the process.  Moreover, you don’t need to adopt a complete process all at once, just adopt a practice at the time.  The growth problem is not a problem anymore, since we downplay big process and we make instead practices first class citizens.  Practices can come from any source including the RUP and much of the practice work we have done is in support of RUP adoption. Practices can be composed to create your own way of working.  Finally, the execution problem which is the hardest to achieve, is for the time being our little secret, but you are welcome to learn more about it by studying EssWork and EssUP. 


Trust me, this is very smart.

Software development a la mode by Ivar Jacobson

The style in which we develop software is as fashion influenced as the clothing style, maybe even more.  We don’t dress ourselves dramatic different more than every five to ten years, but when it comes to software we change our development style dramatically every five years. Just a few years ago the Unified Process was a la mode and every software organization was adopting UP one way or the other.  Just 2-3 years ago the hottest style was Extreme Programming XP, but now I hear very little about XP.  Now, everyone is running after the next “silver bullet” Scrum.


But what about Scrum, isn’t it fantastic?  When I for the first time met Ken Schwaber, a father of Scrum, I said: “What I like about Scrum is that it describes how really good project managers motivate people and run an iterative project.”  I continued: “…and its beauty comes from being agnostic to how you actually do things…you can pick your own way to do requirements, design, code and test.” I summarized: “Can I label Scrum ‘a common sense project management approach’?”  “Yes”, said Ken, “that label works”.  After this introduction we had a lot to talk about.


I can assure you that the founders of Scrum didn’t view their baby as a silver bullet, but with all the pressure from people who love fashion and want to create buzz, they may very well have to accept that they have created a silver bullet.


I think Scrum is a great project management practice.  It also includes some good social engineering work patterns which make it agile. 


However, that is all it is. 

  • You still need all the other practices that a good master of software needs to excel in, such as requirements, tests, architecture, components, modeling, configurations, and tools, etc.  This is all quite basic but important stuff. 
  • You also need to know how to build complex architectures such as SOA, PLA, EDA, and EA, architectures that are not just paper-ware but executable. 
  • Finally, Scrum is not enough if you want to know how to scale to large distributed organizations which may have outsourced projects.


What would make sense to do?

  • If you already are a Scrum fan you can say that you need Scrum++ where the Scrum stands for the tip of the iceberg and the ++ stands for the bottom of the iceberg which constitute all the other good practices that you will need.
  • If you are not a Scrum fan, you could consider replacing your current project management practice with a Scrum practice.  You can still work as you did before so you don’t need to throw out the baby with the bathwater.  However, you would use Scrum for project management for smaller projects.  For larger organizations you will need more.
  • In both cases you need to use modern social engineering work patterns as you need to be agile.


The ability to mix and match practices from different camps is what I and my company have been working with over the last four years, and now we can do it.  That will allow us to move forward and stay away from the silver bullets, the hype, the buzz and the fashion and treat software with the respect it deserves.


This would be smart.  Smart by the industry. 

Who Loves Process? by Ivar Jacobson

Right now I am in my home in Switzerland to take a break and ski. I ski during the days and I work mornings and nights. Sleep takes too much time so I do as little as possible of that.:) One of the questions I often get nowadays is “Does Process come from the top or from the bottom?” Before answering I will start with two questions that I usually ask during my presentations. “How many of you love process?” In a group of 750 people, I usually see 3-5 raised hands. These are of course the people who work with process implementation, and they don’t have to follow a process themselves. Then I ask provocatively “How many of you hate process”. Now I get a very different answer. Usually 60-70% of the audience raise their hands!

Why is it like that? I believe that in many larger companies process has been pushed down on the people who know how to develop software. This won’t work anymore. The competent will speak up to get the process they want, which is good. What worries me though is that the pendulum will swing over to the other extreme. Instead of process push-down we will get process pop–up.

People do as they want. If every team gets their own process, they will not be able to learn from other teams, they will not get common set of tools and they will not harvest reusable assets. What we really need is a balance between push-down and pop-up.

For a very long time (since 1987) I have told my clients that one of the most important success factors for process adoption is to identify both a sponsor and a champion for the process improvement. The champion is a developer with many years of experience, great competence and with high credibility among his comrades. The sponsor is a higher level manager who wants to improve the way his organization develops software to support the company’s business. Without support from both don’t bother to adopt any new process.

Another of success factor is to use experienced people to coach the team adopting the new process. However in many cases management wants process but doesn’t want to invest in coaching. They just hope that people will adopt the process offered to them without proper coaching. As a consequence a lot of organizations have failed in process adoption. Management tried a shortcut, but it became a detour. The money an organization spends on product development is a factor of ten higher than the money it spends on proper coaching. For twenty years I have told my clients that without adequate training and coaching don’t bother to adopt any new process.

A third success factor is to balance the need for process from the top (the management) and from the bottom (the developers). This is true for any process whether it is a software development process or a business process. Only working from the bottom is a very slow process, and working only from the top creates a lot of resistance. Unfortunately, in many organizations management pushed down process on people counter to our recommendations. The developers were not enthusiastic but they tried to adopt the new process. That was not easy. Management believed their people were using the process but the developers did what they wanted to do, usually what they always had done. We got a gap, sometimes a huge gap, between what the process said and what people actually did. We call it the process-project gap. Thus we got failures and people started to hate process.

We need to change this. My recipe contains four ingredients:

  1. Reduce complexity. Instead of adopting a big process consisting of many practices, adopt a practice at a time. This will significantly reduce the complexity of process improvement.
  2. Balance the push-down from the top and the pop-up from the bottom, instead of just doing one or the other.
  3. Allow teams to change the practices so they work in their projects. The way you really work must be fed back as a change to the practices. We want a process that is alive and not just a dead book. This allows us to close the gap. One challenge here is of course that traditional process hard-heads will demand that all deviations from the described practices must be documented and perhaps even be given formal exemptions. If that is necessary then people will feel that it is easier to do what is demanded than to do what is right. What we need is a utilitarian perspective on process rather than dogma. :)
  4. Activate the practices and bring them alive in a way traditional process has never been able to do. While activated, a practice can help with all kinds of things. It can review what the developers are doing and suggest corrections. It can automate mundane tasks transparent to the developers. It can train the developers on the job reducing the need for classroom training and traditional human mentors. The selected practices should give context-sensitive help to the developers. This means that they should only give the developers help when they want it and only the help they really want and no more. The goal is to give the developers more time to think and create and to remove a substantial part of the no-brain work that developers suffer from today.

We have had a period of process push-down. The pendulum is now swinging to the other extreme – process pop-up. After a few oscillations the pendulum will hopefully swing to a new position where we will get processes that balance both the need for governance and for the need for creativity.  

Software Engineering meets Social Engineering by Ivar Jacobson

There is a conflict between people who support Software Engineering approaches (such as Rational Unified Process RUP) and people who support Agile methods (such as SCRUM or XP). This is understandable since the two approaches are described in an incompatible way. However that is unnecessary, since the ideas behind the two are in all essentials complementary. The trick is how to combine them in a way fair to both of them.

In the software world we like swinging. We are swinging from one way of working to another way of working -- from one extreme to the other. Some people have been swinging for their whole life and have had enough of it.

Once, about five years ago, when I spoke in Singapore for a small group of 50 people, a senior guy stepped up, very frustrated, and told me that UML and RUP would be dead in five years and I would be gone as well. I like provocations so I asked him calmly what he based that upon. He told us that he had worked with software his whole life. “In the 60s we all worked with assemblers, then we got Cobol and Fortran, then we got database design” and he continued describing a zigzag path with new methodologies in every step: “structured programming, structured analysis and design, object-orientation, components and so on.” He felt it was awkward hearing about a new standard modeling language. I told him that there was another path: Assembler, components with assembler, component with a programming language, components with structured programming, components with objects and now components with objects and aspects. And we have all the time used a modeling language that can be described as UML.

Well, I am still here and I intend to be here for many more years…knock on wood. The guy who was so unhappy became even unhappier next day when he was fired by his boss. However, it is true that UML and RUP have lost some momentum, but they are far from dead. They are just taking a break while the world is swinging.

We are swinging from the extreme of doing everything with UML following what many believe is a prescriptive Software Engineering process. And we are swinging to another extreme called Agile. Very young people are having their first swing and now they are Agile. Middle-aged people, what a cute label, are right now swinging from the extreme of working with Software Engineering to another extreme called Agile. We swing and our companies swing with us.

Today everyone is agile. Of course. Everything else would be silly. Let me say it loud and clearly: I am a big fan of agile. My teams at Ericsson were extremely agile.

However, most people I talk to have a fuzzy understanding of what agile really is about. I participated in a panel discussion with agile evangelists in the UK last March. The organizers had hoped I would be against agile. They were surprised. The audience asked us to define agile. The panelists claiming they were agilists started to ramble. They repeatedly said that the most important property of agile was that it was iterative. That is dead wrong. Iterative development is one of the key practices in RUP and it has been around long before RUP. It was previously called spiral development and created by Barry Boehm in the late 70s. So I had to help explain what agile is:

Agile is about three things:

  1. Most important, agile is about social engineering. This is what actually made agile different. It is about how to work as a team, how to make people motivated, how to collaborate, etc.
  2. Agile is about lightweight. Instead of relying on explicit knowledge like in RUP, agile relies on tacit knowledge. In RUP we tried to write down what we know are good practices. However, since people don’t read process books, it doesn’t make sense to have them. Instead agile assumes that people have knowledge in their heads that is enough to develop good software. This can of course be debated but that is what it is.
  3. Agile contributes some technical practices. This is the weakest part of agile. Very little is really new. Iterative and incremental development is as I already have said an old idea. User stories are a special kind of simplified use cases. Most interesting new idea is test-driven development. I am not claiming the agile technical practices are uninteresting, just saying that if it were just for these ideas we wouldn’t have been excited about agile.

As you see Software Engineering and Agile tackle different aspects of software development. Software Engineering’s strengths are about technical practices and Agile’s strength is about social engineering. Thus here the two are very complementary.

That Software Engineering is straightjacket and Agile is light is harder to tackle. The question is can we get the best from both worlds here. Yes, we can!

Finally, the Software Engineering camp has a set of technical practices, the different agile methods have other sets of partly overlapping practices. Can we find a way to live with both? Yes, we can!

To do that we have had to invent a new concept Practices. We don’t talk so much about process anymore; instead practices are first class citizens. Process is just a composition of practices. Instead of talking about second generation processes that are passive and monolithic (big process), we talk about a third generation process which is active and practice-centric. If you already now want to have a peek at a third generation process, please go to my web site www.ivarjacobson.com 

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:

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.  

Page 1 of 212