Ivar Jacobson's Blog

Bij IJI staan we een practice-gedreven aanpak voor. Zoals met veel concepten en principes geldt ook hier dat een goed begrip van wat ermee wordt bedoeld essentieel is om er echt de vruchten van te plukken. Een manier om daar invulling aan te geven is om te kijken naar criteria waaraan je een goede practice kunt herkennen. Maar voor we dat doen, is het goed om eerst te kijken naar de definitie en kenmerken van een practice en een practice-gedreven aanpak.

Onder een practice-gedreven aanpak verstaan we onder meer “het samenstellen van een effectieve manier van werken op basis van relevante procescomponenten”. In plaats van moeizaam te proberen een procesraamwerk toe te snijden op een specifiek project draaien we het om; we selecteren alleen relevante procescomponenten en assembleren die tot een consistent proces. En zo’n procescomponent noemen we dan een practice. Use Cases, User Stories en Iteratief ontwikkelen zijn enkele voorbeelden van practices. Andere voorbeelden zijn Operationaliseren Systeem en Datamigratie. In deze context is het ultieme doel van een practice-gedreven aanpak “betere resultaten boeken met softwareontwikkeling”. Hierbij kun je dan denken aan betere software, goedkoper, sneller en een prettigere manier van werken. Read the rest of this entry »

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 the rest of this entry »

 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.