If we provide projects with at least one “how” (practice guidance) for each and every “what” (alpha state progression), then no team ever has to discover or invent new ways of working. But, if we allow teams to adapt or substitute any specific piece of practice guidance with an alternative means of achieving the same end, then we can empower teams to adopt a way of working that best suites the evolving needs of their project and team circumstances.

This approach has significant benefits for process quality auditing and assessment too. In the past, quality assessors within an organization have often had an up-hill battle to determine which process a given team thinks it should be following, before they can even start to assess whether or not it is an appropriate process and finally whether or not the team is actually following it.

Being pointed to a “tailor down” process like the Rational Unified Process has never been popular with quality managers in my experience. The RUP may document everything that any project of any size might ever conceivably need to do, but everyone knows that no project ever should or could attempt to do all of it. But determining and documenting which bits of process do or don’t need to be done is challenging and onerous for projects (and therefore is either not done well or not done at all). Likewise, assessing whether the bits of process that the project team is supposedly doing, together constitute a complete and coherent process that is “necessary and sufficient” is nigh-on impossible.

A process kernel on the other hand provides a process quality assessor with a simple process-coverage checklist. We know that each and every project needs to achieve each and every alpha state progression somehow. If the project team knows how they will go about trying to achieve each and every progression, then they have a fully defined process that is both necessary and sufficient (in terms of coverage at least). A process quality assessor can therefore be presented with a project team’s defined process in the form of the standard set of alpha state progressions, with each one pointing to the practice guidance that the project team is following in order to achieve the progression.

The current state of the project is easily assessed as it is expressed in terms of the progressions that the project has made, each of which points to the evidence that shows it has been achieved, expressed in the way the practice guidance suggests it should be. The process assessor also knows which practices should be currently “in play” and guiding the planning and execution of the current project activities and tasks – these are the practices that relate to the state progressions that the team hasn’t achieved yet, but is striving to achieve next.

The kernel thus enables process quality assessors to effectively and non-invasively assess what process is theoretically being followed, whether it is fit for purpose and whether it has been and is being successfully followed.

In the previous kernel journals we have looked at the many practical applications of a process kernel that is based on the key software development entities (known as Alphas) that software projects add value to by progressing through their value states. We have seen that there are many advantages to separating these “whats” (progressions) that we are trying to achieve, from the many possible “hows” (software processes and practices) that describe how we might achieve and evidence these progressions, including the ability to set objectives and track progress in a common and consistent way irrespective of what specific practices a project happens to adopt.

So, our kernel gives projects advice on what to achieve (first / next) without providing any specific guidance on how to achieve it. This is both good (because we are not telling software development teams exactly how to do their job) and bad (because we aren’t giving them any help at all on how to do the things that they have to do).

Clearly there is no shortage of advice out there in the form of the myriad of competing software development processes. But we have seen that they have traditionally suffered from being somewhat monolithic (“all or nothing at all”), and while many contain much useful practice guidance, it is difficult to find and use the specific piece of guidance that we need without getting tangled up in a huge, prescriptive process web of activities to follow and artifacts to produce (and templates to complete).

What we need is a way of accessing process guidance that enables us to find our way straight from what we are trying to achieve here and now (such as establish a shared understanding of the value and scope of a software system) to specific guidance on how we can achieve it (e.g. with use-cases and use-case scenarios).

This is what IJI have done with their EssUP process – provide access to guidance on how to achieve something, that is accessible directly from the progressions that we know our project has to achieve first / next. And we have provided this guidance as a set of modular practices, so that if an organization or project does not like a particular practice (such as the use-case practice), they can “swap it out” and “swap in” a different practice into the same process space instead (such as a traditional declarative-requirements practice or a user-story based practice).

Organizations are now free to choose the balance that is right for them between process consistency and process freedom. At one end of the scale an organization can provide a single set of cohesive practices that provide just one single standard way of achieving all the things that projects need to achieve. At the other end of the scale, they can allow projects to select any “hows” they wish from any practice guidance that is “out there”, and to freely refine and evolve these working practices over time. A project, for example, might choose to scope its system with a use case diagram and then drive the development and test of the system with user stories. Furthermore, as we will see in the next kernel journal, we always know whether the process guidance available to a team “covers all the bases” or not (i.e. whether there are any spaces left in which people are expected to “just wing it”).

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.

Een practice-gedreven aanpak vraagt om met een andere bril naar de totstandkoming en het gebruik van ontwikkelprocessen te kijken zodat tal van problemen worden opgelost die ons er vaak van weerhouden om echt succesvol te kunnen zijn. Deze problemen en de uitweg zijn goed beschreven in het artikel Enough Proces, Let's do Practices. Het komt er kortweg op neer dat organisaties en projectteams daadwerkelijk en van dag tot dag baat moeten hebben bij een ontwikkelproces. Het komt namelijk nog vaak voor dat een ontwikkelproces niet wordt gevolgt of dat het eerder een blok aan het been is. Ook kan het zijn dat de implementatie van een procesraamwerk als geheel gewoon te veel vraagt van een organisatie of te weinig oplevert.

Anders kijken naar het verzamelen en delen van kennis is een deel van de oplossing. Stel je eens voor dat je:

• Op een elegante manier de kennis van duizenden ervaringsdeskundigen kunt ontdekken, verzamelen en vastleggen.
• Kennis supertoegankelijk kunt maken.
• Zeer snel toegang krijgt tot de kennis die je nodig hebt, alleen die kennis, wanneer je het nodig hebt en niet eerder.
• Teams in staat stelt om met behoud van controle hun eigen innovatieve manier van werken samen te stellen, helemaal toegesneden op de behoefte.
• Stapsgewijs procesverbetering mogelijk maakt zodat risico’s worden geminimaliseerd.
• Nieuwe werkwijzen zeer eenvoudig kunt verweven met bestaande zodat je het goede kunt behouden en het nieuwe eerst op kleine schaal in de praktijk kunt beproeven.

Een practice-gedreven aanpak maakt dit allemaal mogelijk.

Volgens de definitie is een practice een manier om op systematische en verifieerbare wijze een specifiek aspect van een probleem op te lossen. Enkele kermerken van een goede practice zijn:

• Een duidelijke focus op een specifiek aspect van softwareontwikkeling
• Een aanpak om een probleem te duiden en de strategie om het probleem op te lossen
• Instructies om te verifieren dat het probleem daadwerkelijk is opgelost en,  indien relevant, een beschrijving van welk ondersteunend bewijs hiervoor benodigd is
• Een beschrijving van hoe de te volgen strategie in de dagelijke praktijk moet worden uitgevoerd.

Hierbij is het verder belangrijk om te weten dat een practice:

• Niet beoogt om een probleem in zijn geheel op te lossen.
• Daadwerkelijk door iemand in de praktijk kan worden uitgevoerd.
• Een helder begin en eind heeft.
• Een element van verificatie in zich heeft en zonder eigenlijk niet compleet is.

Simplistisch voorgesteld beschrijft een practice: wat moet worden geproduceerd, hoe je dat moet doen en welke bekwaamheden je daarvoor nodig hebt. En zou je in EssWork naar bijvoorbeeld de Use Case Essentials practice kijken, dan zul je zien dat een practice meer informatie kan bevatten zoals een workflow, hints en tips, veel gemaakte fouten, beschrijvingen van concepten en compleetheidscriteria.

Het simpelweg verzamelen van essentiële informatie maakt een practice echter nog geen goede practice. Met name de focus op een specifiek aspect van softwareontwikkeling (of teamwork) is zeer relevant. Deze focus kunnen we concreet maken door goed te letten op het onderwerp van een practice en het aandachtgebied waarbinnen een practice zich begeeft.

Binnen softwareontwikkeling kan een practice zich richten op drie aandachtsgebieden, de klant (customer), de oplossing (solution) en de inspanning (endeavour).

Customer – Ieder software project heeft een klant en ieder process dient het perspectief van die klant mee te nemen om ervoor te zorgen dat de juiste oplossing wordt ontwikkeld.

Solution – Ieder software project dient werkende software op te leveren en ieder process dient te een team een set van werkwijzen te bieden die het team helpt om op productieve en constructieve wijze goede kwaliteit software te ontwikkelen.

Endeavor – Softwareontwikkeling is een serieuze aangelegenheid die normaliter vele weken in beslag neemt, vele verschillende belanghebbenden raakt en meestal een team van specialisten vereist. Ieder practisch process dient een set werkwijzen te bieden voor het effectief plannen, leiden en bewaken van de benodige inzet van het team.

De onderstaande figuur geeft een overzicht van onder andere de werkproducten en activiteiten van de Use Case Essentials practice.

Use Case Essentials Overview

Wat bij nadere bestudering opvalt is dat alle activiteiten en werkproducten geel van kleur zijn. Dit betekent dat ze allemaal binnen het aandachtsgebied Solution vallen. Waren ze groen geweest, dan zouden ze binnen het aandachtsgebied Customer zijn gevallen of het aandachtsgebied Endeavour wanneer ze blauw zouden zijn geweest.

Samengevat geldt dat bij een goede practice alle werkproducten en activiteiten ultiem binnen één aandachtsgebied vallen. Uitzonderingen zijn mogelijk of soms noodzakelijk om de practice te kunnen laten werken. Zo kent de Architecture Essentials practice een Coach Team activiteit (Endeavour) om ervoor te zorgen dat een team zich een software architectuur goed eigen kan maken.

Behalve een eenduidig aandachtsgebied is er nog een manier om een practice een goede focus te geven en dat is het onderwerp van de practice. Een goede practice heeft ultiem één en soms een beperkt aantal onderwerpen. Een heel specifiek onderwerp van de Use Case Essentials practice is de Use Case Module, zie ook de onderstaande figuur.

Use Case Module Practice Card

In het kort is een Use Case Module een set van flows of delen van een use case die gezamenlijk door het ontwikkelproces gaan. Aan de linkerkant van de bovenstaande practice card staat een state machine of toestandsdiagram die de levenscyclus van een Use Case Module gedefinieerd. De figuur laat zien dat een Use Case Module vijf toestanden kent.

Op Scoped moet duidelijk zijn welke use-case flows, special en supplementary requirements de use case module omvat.  Op Specification Agreed moet er overeenstemming zijn over de inhoud van de Use Case Module. Op Realized moet duidelijk zijn welke componenten op welke manier gaan samenwerken om tot een executeerbaar systeem te komen. Op Implemented moet de Use Case Module executeerbaar zijn. Tot slot moet op Verified de executeerbare Use Case Module voldoen aan de specificatie.

De mogelijke toestanden van de Use Case Module maken inzichtelijk in welke volgorde de Use Case Module door het ontwikkelproces gaat. Of anders gezegd, op welke manier stapgewijs voortgang kan worden geboekt. Een onderwerp van een practice noemen we ook wel een Alpha. Alpha’s zijn die dingen die een softwareproject altijd heeft, ongeacht het type project of de aanpak. Verder zijn Alpha's ook niet tastbaar en zijn werkproducten nodig om er iets over te kunnen zeggen. Practices geven als het ware invulling aan Alpha’s. Alpha hebben ook verband naar planning en beheersing; ze geven inzicht in waar je bent en welke activiteiten je moet uitvoeren om van de ene toestand naar de volgende toestand te komen. De status van werkproducten vormen hierbij dan de bewijslast waarmee kan worden aangetoond dat een bepaalde status is behaald.

Samengevat geldt dat een goede practice ultiem één Alpha heeft waar alle werkproducten en activiteiten betrekking op hebben. In de praktijk kunnen we hier iets losser mee omgaan om een practice goed te kunnen laten werken.

De eerder getoonde overzichtskaart van de Use Case Essentials practice laat bijvoorbeeld meer Alpha’s zien dan alleen de Use Case Module: Opportunity, Requirements, Change, System, Defect, Test, Project, Risk en Task. Bijna al deze Alpha’s zijn afkomstig uit het model dat onder EssWork zit. Dit practice onafhankelijke model of Kernel maakt het mogelijk om meerdere practices samen te smelten tot een consistent geheel. Met practices kun je dan op relevante plekken Alpha’s aanvullen met relevante informatie, in dit geval use case specifieke zaken. Zo is Change geïntroduceerd om grip te krijgen op wijzigingen. En is System aangevuld met essentiële content in de vorm van mogelijke Changes en één of meerdere Use Case Modules en het inzicht dat deze worden beschreven middels een use case model en supplementary requirements.

Op dit punt aangekomen hebben we de definities en de essentie van practices en een practice-gedreven aanpak en enkele kenmerken van goede practices in het kort behandeld. Uiteraard valt er nog veel meer over te zeggen. Wanneer je meer wilt weten, bekijk dan bijvoorbeeld de video over Practice Execution of stuur me een email: elcardozo@ivarjacobson.com

De onderstaande figuur geeft een overzicht van onder andere de werkproducten, activiteiten van de Use Case Essentials practice.

Wat bij nadere bestudering opvalt is dat alle activiteiten en werkproducten geel van kleur zijn. Dit betekent dat ze allemaal binnen het Solution aandachtsgebied vallen. Waren ze groen geweest, dan zouden ze binnen het Customer aandachtsgebied zijn gevallen of het Endeavour aandachtsgebied wanneer ze blauw zouden zijn geweest.

The alphas, when used with common milestones such as the Unified Process Milestones, can actually give us much more than this – they can provide a project status and health dashboard that can be used by the customer and supplier organizations to assess the current status and health of any / all projects, irrespective of which processes or practices they are following. The graphic below shows just such a dashboard, with a set of kernel alphas and a traffic-light status for each alpha, which is derived by comparing where the project is now (the state machine to the left of each traffic light) with where it needs to be to achieve the next project milestone (the state machine to the right of each traffic light).

In Kernel Journal 5: “Making the Invisible Visible” I described how we can easily “skin” a process kernel, by providing a portal for projects to capture, share and agree the essential project information that is needed to achieve each state progression (for example, using a set of templated Wiki pages). Once we have done this, we can make the alpha dashboard much more useful to the project teams themselves, by flagging which sections of the project portal need to be updated and agreed to get the project to where it needs to go next.

This gives us the equivalent of a Satellite Navigation System for our software projects project that enables us to:

• Set our journey destination and waypoints (milestones)
• Track where we are now, compared to where we want to be
• Get guidance on what to do next in order to progress towards our destination.

The kernel Alphas are the core, key, critical, central, essential conceptual entities that we need to manage and progress in a controlled way in order to ensure a successful outcome for our project. But, like all concepts, they have the distinct disadvantage of being invisible. A project manager is convinced that his project is important and that managing its progression to a successful conclusion is critical. But if, as an outside assessor, I were to say “bring me this project of which you speak so that I may gaze upon it and assess its status” he would be stumped. He can show me plans, people, documents, but he can’t show me “the project”. These key concepts are the elephants in the room that no one can see because …  well , because they are invisible. To be useful, they need to be made visible and real, so normal people can interact with them.

In our first blog I talked about how domain models can be used to simulate the execution of a business by adding attributes to them and slapping a few crude user-interface screens over them. And we can do exactly the same with the Alphas that are the domain entities in our software development process kernel. This has become known in my sad, process-geeky world as “skinning the kernel”.

A great way to get a quick-and dirty but fit-for-purpose “skin” in place is to use a Wiki: one Wiki page for each required view onto the alpha states and attributes. Wikis are useful because they solve many process problems in one:

• Where do we put our key information as we gather it?
• How do we communicate the information to all our stakeholders?
• How do we get agreement and consensus?
• How do we record key agreements and decisions?

We capture the key project information where people can see it, contribute to it, refine it and agree it.

To help projects focus on the key project information (the Alpha attributes) and to help them to capture it in a simple, structured, concise and consistent way we can provide a simple set of Wiki templates. (After all it’s better to have a template than to make each project start from scratch with a blank Wiki each time).

(But wait, oh no, not templates!!  We’re not supposed to use templates, because we are recovering document template addicts. How are we going to we stop ourselves becoming addicted to this (admittedly small, lightweight and relatively harmless looking) set of templates?

Fortunately, we already have the antidote in place. Our templates can’t become ends in themselves, because we know that they are only a means to the end of progressing the states of our key Alphas. We can easily define who needs to assess which states and when (e.g. “the product owner needs to agree the target date and scope of the next release before we start incrementally developing the product release”). We then close the evidential loop by stating where the evidence is to be found:  “based on the information in the Wiki Project and Requirements pages. If the assessing party is happy that the progression has been achieved, based on the evidence they see, then the progression has been achieved (even if there is the odd spelling mistake on the Wiki!).

So now we have a simple way of executing our development project by capturing the information we need to progress our project in a controlled way to a successful conclusion. And, once again, this is more than just process theory. I have seen many projects use this approach to reduce their documentation overheads from dozens of documents totaling many hundreds of pages (which of course virtually no one ever read) to a dozen or so Wiki pages which told everyone exactly what they needed to know about the project and its status, when they needed to know it (including CMMI SCAMPI C appraisers in one case, as it happens).

I have met hundreds of organizations that are trying to improve their way-of-working. What I have found most interesting is that the vast majority of these organizations are looking for the solution outside of the company. They are either benchmarking with other similar organizations or running after the latest fashion in the industry. However the perceived benefits are not always there and the answer is usually much closer than they know.

Good industry standards are one thing, but many things that are good for a specific company are not necessarily transferable to another company with another background and culture.

In reality many solutions can be found inside the company. There are top-performers, top performing teams and projects in all companies and if we could repeat the good behavior from those individuals and teams, the organization could improve tremendously. However we need a structured way to capture that behavior so that it could be easily understood, distributed and reused; this is where using Practices makes perfect sense. Practices is a way to effectively describe the Essentials of Things to do, Things to Produce and the Competencies needed for a specific area of concern.

What good practices do you have in “your belly button”?

The misalignment between business and IT is an interesting conundrum that many businesses face today – regardless of industry or organizational size. Most experts believe that approximately 60 to 80 percent of the IT budget is allocated towards operations, spent on managing day-to-day activities. Nonetheless, according to industry surveys the majority of CIOs would prefer to spend much more of their IT budget on innovation. Trends such as sourcing and IT commoditization are the results of companies trying to divert a greater portion of the IT spend from the operational areas to the areas driving innovation and next generation IT solutions.

Most CIOs would much rather be recognized as a business strategist than as an operational guru. However, the reality is far from such ambitions.

How many times have we heard that IT does not deliver what the business requires?

We all know that this is not because IT doesn’t want to deliver what the business requires or that the business doesn’t want them to deliver; it is because there is a big gap between the two. The gap can be dependent on many things. And one of those is communication - including improper organizational lines of communication and lack of a common vocabulary.

According to the Gartner report “Gartner Perspective IT Spending 2010”, we will see some initial IT growth in 2010 with more growth to follow in 2011. Gartner states that “Leading the IT organization in 2010 requires a clear vision for melding technology, business process and financial management into a cohesive view of IT investments and priorities.” I couldn’t agree more and as we move into 2010, I hope to see more IT leaders becoming a driving force to business change and success.

Throughout 2010 I will continue to blog on this topic of aligning business and IT and I will be counting on the IJI technical subject matter experts and our leading consultants to weigh in on this topic and provide their knowledge of how successful organizations align software development to the real needs of the business.