• Gebruikers verwachten andere  functionaliteit dan waar ze oorspronkelijk om hebben gevraagd.
• Gebruikers eisen functionaliteit die ze nooit zullen gebruiken
• Gebruikers geven tegenstrijdige of conflicterende requirements

Om meer succesvol te zijn, zijn een aantal veranderingen noodzakelijk. Eén daarvan is dat informatie-analisten meer gefocust moeten zijn op gewenste resultaten in plaats van systeemeigenschappen (features). Een andere is dat informatie-analisten zich meer moeten verdiepen in de onderliggende oorzaken in plaats van zich tevreden te stellen met een lijst wensen. Gefocust zijn op resultaat en het boven water krijgen van de onderliggende oorzaken kan een heel karwei zijn en het is gemakkelijk om de twee door elkaar te halen of vast te lopen. Een slimmere manier waarbij meer rekening wordt gehouden met taalgebruik, vraagstelling en (on)bewust gebruikte van kaders of context frames biedt dan uitkomst.

De term context frame is jargon, maar heel gemakkelijk uit te leggen met een voorbeeld. Ik ben er namelijk zeker van dat jij mensen kent die altijd en soms tot vervelens toe antwoorden met “ja, maar”. En hoewel er zelden een negatieve intentie achter, voelt het maar al te vaak wel degelijk zo. Communicatie-experts zeggen dat je beter met “ja, en” kunt antwoorden om zodoende de negatieve lading er af te halen. Maar als je het mij vraagt, is het beter om (on)bewust steeds het juiste kader of frame te kiezen om zo het gewenst resultaat of de gewenste respons te krijgen. Vergelijk bijvoorbeeld de onderstaande zinnen:

• Met het project gaat het prima, maar we moeten deze risico’s wegnemen
• Met het project gaat het prima en we moeten deze risico’s wegnemen
• Met het project gaat het prima alhoewel we deze risico’s moeten wegnemen

Wanneer je deze zinnen leest, merk dan op wat naar boven komt. En merk dan dat iedere zin iets anders aanvoelt of een andere focus aanbrengt?

Wanneer maar wordt gebruikt, dan hebben de meeste mensen de neiging om vooral aandacht te geven aan het tweede of laatste deel van zin, ofwel dat risico’s moeten worden weggenomen. En wanneer en wordt gebruikt, dan ervaren de meeste mensen beide zinsdelen als even belangrijk. En wanneer alhoewel wordt gebruikt, dan neigen de meeste mensen ernaar vooral stil staan bij het eerste deel van de zin, ofwel de status van het project. Het feit dat risico’s moeten worden weggenomen wordt dan als minder tot irrelevant ervaren.

Wat we hieruit kunnen leren is dat het wijzigen van één woord een bepaald aspect meer of minder kan belichten en daarmee de wijze waarop we dingen ervaren kan veranderen. “Kaders (frames) sturen de aandacht en beïnvloeden hoe gebeurtenissen worden geïnterpreteerd” (R. Dillts, 1999).

Binnen taal kom je veel verschillende soorten kaders of frames tegen. Welke activiteit zou je bijvoorbeeld liever op jouw softwareproject willen aantreffen: herstelwerkzaamheden (rework) of refactoring? Hoewel ze in essentie hetzelfde zijn, gok ik op de laatste (met dank aan Craig Lucia voor het voorbeeld).

Wanneer je wilt ingaan op resultaten in plaats van wensen, dan wil je juist niet diep ingaan op probleemgebieden. En andersom geldt dat wanneer je wilt ingaan op problemen of achterliggende oorzaken, dan wil je het juist niet hebben over visievorming. Het gebruik van het juist kader is een manier om daarvoor te zorgen. Wanneer je gewenste resultaten wilt identificeren, dan dien je ervoor te zorgen dat de focus ligt op het behalen van één of meer doelen, gewenste toestanden of het vinden van een bepaalde oplossing. Gebruik hiervoor vragen zoals:

• Wat heb je nodig?
• Hoe is het om….te hebben?
• Hoe kunnen we merken of meten dat we …….hebben waargemaakt?
• Welke middelen hebben we beschikbaar om ......mogelijk te maken?

Merk op dat de eerste vraag uit de lijst gevaarlijk kan zijn wanneer die in isolatie wordt gesteld omdat je dan namelijk de kans loopt te blijven zitten met die ongewenste lijst met wensen. Gebruik het dus alleen als startpunt en vraag dan door, bijvoorbeeld met de overige vragen uit de bovenstaande lijst. Let er tevens op dat alle geïdentificeerde resultaten positief worden geformuleerd en zijn gericht op de toekomst. We zullen straks ingaan waarom dit verstandig is.

Wanneer je oorzaken wilt identificeren, zorg er dan voor dat je focust op ongewenste symptomen en hun effecten. Gebruik hiervoor vragen zoals:

• Wat is het probleem?
• Wat mankeert er aan de huidige situatie?
• Waarom is het een probleem?
• Hoe weet je dat het een probleem is?
• Wie heeft het probleem veroorzaakt?
• Wat heeft het probleem veroorzaakt?

Realiseer dat te veel blijven hangen in problemen en oorzaken op zichzelf geen waarde heeft omdat het uiteindelijk gaat om het oplossen van problemen in plaats van ze te hebben. Zorg er daarom voor dat problemen, symptomen en oorzaken altijd wordt geanalyseerd in het licht van gewenste resultaten.

Zoals aangeven is het herkennen en kiezen van het juiste kader en het positief en toekomstgericht formuleren van gewenste resultaten belangrijk. Het komt namelijk vaak voor dat gewenste resultaten op een negatieve manier worden beschreven en dit leidt in de meeste gevallen tot onverstandige beslissingen. Neem bijvoorbeeld de eis of wens “Ik wil minder fouten ten gevolge van onduidelijke requirements”. In veel gevallen hebben organisaties geprobeerd om dergelijke problemen op te lossen door middel van meer formele processen en meer gedetailleerde beschrijvingen. In de praktijk blijkt echter dat dit in de meeste gevallen alleen maar leidt tot meer problemen. De oorzaak is de focus op het voorkomen van fouten of zoals in dit geval beter proberen te doen wat al is geprobeerd. Een alternatieve vaak meer succesvolle oplossing is te kiezen voor een ander samenwerkingsmodel met achterliggende disciplines en snelle terugkoppeling. Dit komt vaak pas in beeld wanneer je meer alternatieven gaat zien en een manier om dat te doen is door negatief geformuleerde resultaten eerst positief om te kaderen (reframe). Dit kun je doen door vragen te stellen als: “Wanneer je minder fouten hebt tengevolge van onduidelijke requirements, wat ervaar je dan?”.

Uiteindelijk gaat het er om (on)bewust het juiste kader te kiezen en slim gebruik te maken van taal. Je hoeft me niet op mijn woord te geloven, maar ik stel voor dat je proef op de som neemt. En wanneer je dat doet, dan zou je wel eens verrast kunnen zijn met het resultaat.

The best way is to integrate needs analysis into the way that you discover requirements.  As new requirements (and I include user stories as  kind of requirement), make sure you understand what the need is behind it.  Use the questions I mentioned in the webinar (Getting to Needs: Seeing beyond wants and wishes to find the real source of business results)  to expand your knowledge of why they "need" the system to work that way, and offer alternative solutions as you see them.  The offering of alternatives will stimulate a discussion that will either confirm your understanding of the need or help you refine your understanding.  If the alternative is actually a better way of solving the problem you will demonstrate your understanding of the need as well as help to build a reputation for adding value that will in turn improve your ability to collaborate with your business partners.

Je zou kunnen zeggen dat dit gewoon spelen met woorden is. En dat klopt! Maar is het formuleren en communiceren van requirements niet feitelijk hetzelfde? Voor meer heldere requirements zijn een tal van zaken benodigd. Er is echter een belangrijk element dat vaak over het hoofd wordt gezien, namelijk inzicht in de structuur van taal en de wijze waarop taal wordt geïnterpreteerd.

Daniel, een goede vriend van mij, vertelde me eens wat hij had meegemaakt met een projectteam dat goed in de problemen zat met zogenaamde niet-functionele systeemeisen. Het team wist dat er niet-functionele eisen waren die cruciaal waren voor het slagen van het project. Echter, de klant werkte in hun ogen niet echt mee en was ook niet in staat om deze eisen goed te verwoorden. Uiteindelijk werd een doorbraak geforceerd met behulp van het conflictmodel: (lees hardop: “Dus je wilt een systeem dat niet te gebruiken is en waardoor alle gebruikers met de dag steeds meer gefrustreerd raken”. Het schokeffect creëerde inderdaad een opening, maar ik ben er zeker van dat jij het met mij eens bent dan de meeste klanten het niet op prijs stellen om te worden gebruuskeerd, toegeschreeuwd of afgebekt. En gelukkig zijn er een meer vriendelijkere en elegantere manieren.

Neem bijvoorbeeld niet-functionele requirements zoals: betrouwbaarheid, gebruiksvriendelijkheid, efficiency, onderhoudbaarheid, portabiliteit en stel jezelf de volgende vraag: Wat hebben deze kwaliteitsattributen gemeenschappelijk vanuit het oogpunt van taal? Het antwoord is dat het allemaal zelfstandig naamwoorden zijn terwijl het eigenlijk werkwoorden zijn. Of met andere woorden, het zijn vermomde actieve processen die worden behandeld alsof het (fysieke) dingen zijn. Dit fenomeen kom je overigens overal tegen in allerhande situaties. Wanneer iemand je bijvoorbeeld vertelt dat hij of zij een depressie heeft, dan voelt die persoon zich eigenlijk gewoon naar. En hetzelfde is aan de hand met plezier of lol. Je hebt geen plezier, je voelt je goed.

Op dit punt vraag je je wellicht af waarom het gebruik van zelfstandig naamwoorden in plaats van werkwoorden nu eigenlijk een probleem is. Het blijkt dat het veel lastiger is om een probleem op te lossen wanneer het achterliggende proces verstopt of verborgen is. En in ons specifieke geval betekent het dat het veel lastiger is om requirements helderder of meer precies te specificeren en te communiceren. Zo is de kans op het gebruik van jargon veel groter als je processen behandelt alsof het dingen zijn: “Aha beschikbaarheid, en wat is dan de mean time between failure”. En voordat je het weet is de klant je al helemaal kwijt. Meer fundamenteel beschouwd is het zo dat het brein dingen als statisch of onveranderbaar ervaart terwijl processen impliciet als veranderlijk en dynamisch worden ervaren. En dit betekent dat wanneer je vanuit proces redeneert het veel makkelijker is om tot de essentie te komen en de helderheid van requirements te verhogen. En het betekent ook dat je beter in staat bent om over requirements te onderhandelen of de impact te reduceren zodat waarde kan worden geleverd tegen realistische kosten en doorlooptijd.

Laten we een concreet voorbeeld nemen. Een klant zou het volgende requirement of systeemeis kunnen opgeven

• Het systeem moet een beschikbaarheid hebben van 100%.

Sommige analisten zullen direct de haalbaarheid of realiteitszin van 100% beschikbaarheid ter discussie stellen met een grote kans om de klant kwijt te raken. Wanneer je genoeg weet van het probleemdomein en de klant het jargon begrijpt, dan is vragen stellen over de onderliggende processen een elegantere aanpak, bijvoorbeeld:

• Wat is de gemiddelde tijdspanne in een jaar dat het systeem niet beschikbaar mag zijn?

• Wat is de gemiddelde tijdspanne in een jaar dat het systeem niet beschikbaar kan zijn ten behoeve van onderhoud?

• Wat is de maximum toegestane tijdspanne benodigd om het systeem opnieuw te starten nadat het niet beschikbaar is geweest?

En wanneer je eigenlijk geen idee hebt wat de klant nu eigenlijk echt wil of wanneer je vermoed of weet dat de klant concepten als beschikbaarheid niet helemaal begrijpt, dan is het eleganter om meer contextvrije vragen te stellen zoals:

• Hoe is het om een systeem te hebben dat 100% beschikbaar is?

• Wat zou er gebeuren wanneer het systeem maar 90% van de tijd beschikbaar is?

Ik kan niet garanderen dat klant meteen alle antwoorden heeft, maar in bijna alle gevallen zal de discussie  nu eenvoudiger en vriendelijker verlopen omdat we het proces achter het requirement hebben gedenominaliseerd.

Een goede manier om nominalisaties of vermomde processen te detecteren is door te testen of je het onderwerp (zelfstandig naamwoord) van de zin in een doos kunt stoppen, ook al is het een enorm grote doos. Of dat je het uit het raam kunt gooien of in een kruiwagen kunt stoppen. Wanneer dat niet mogelijk is, ga dan op zoek naar de onderliggende processen. Kun je gebruiksvriendelijkheid in een doos stoppen? Of beschikbaarheid? Of software?

Een standaard zoals ISO/IEC 25000 geeft categorieën en belangrijker metrics, ten behoeve van evaluatie en verificatie van niet-functionele requirements of kwaliteitsattributen. Deze metrics geven een uitstekend startpunt voor het doorgronden en verkennen van de onderliggende processen.

Er zijn nog veel meer taalpatronen die, wanneer ze worden overtreden, de effectiviteit van communicatie negatief kunnen beïnvloeden. In alle gevallen gaat het om het verdraaien, weglaten of (over)generaliseren van de werkelijkheid. En in mijn visie is dit een belangrijke bron van obstakels die je vaak moet overwinnen wanneer je behoefte hebt aan meer heldere requirements of andere problemen op dit vlak hebt op te lossen.

De lijst met taalpatronen is te omvangrijk om hier te bespreken en wellicht iets voor een volgende keer. Mocht je meer willen over taalpatronen, dan is het NLP meta-model een uitstekende bron. Maar plaats gerust een reactie wanneer je meer wilt weten of vragen hebt.

• Every requirement is treated as equally important
• The delivery of technical components is seen as of equal importance to the delivery of usable systems
• "Earned value" systems track project cost and schedule, not stakeholder or business value
• A "separation of concerns" is practiced, in which the responsibility of the development team is confined to turning software requirements into verified code rather than delivering business value
• The actual desired outcomes of the project are ignored in favor of implementing the largest number of requirements possible

No wonder so many projects fail to deliver the desired business results! Unfortunately this includes many iterative software development projects where the developers iteratively implement the requirements rather than delivering business value. Any management system that rewards things that are easily measured (like implementing requirements) without a clear and direct tie to business value delivered is headed down the wrong path.

Delivering value is not the same as delivering code: it is easy to deliver a lot of code without delivering much business value. The code delivered and tested must do something useful for the business. This is not the same as delivering what the business asks for - much of what is asked for is never used and delivers no business value. We clearly need a means for finding and implementing the requirements with the highest business value first, and separating wishes from real needs.

The key to understanding the business value derived is to map requirements back to the desired outcomes for the project: a requirement not related to a desired outcome is clearly not important to the business. The connection to iteration planning is that early iterations should implement requirements related to more important desired outcomes, with one clarification: technical risk cannot be ignored. This apparent conflict can be resolved by recognizing that desired business outcomes require that technical risks are resolved early because a technically infeasible solution is incapable of delivering any desired outcomes.

As a result, planning iterations entails choosing the right set of risks and requirements for each iteration to ensure that the iteration’s results make measurable progress toward the delivery of the desired business outcomes. As progress is demonstrated, as everyone can see that key technical issues are being resolved, and as the achievement of desired outcomes becomes increasingly apparent, confidence in success increases.

You might say: “Hey, that’s just playing with words”. Well, that’s right and so is writing and communicating requirements. In order to get accurate requirements you need a number of things. However, an often overlooked element to writing accurate requirements is understanding the structure of language and how language is perceived.

My friend Daniel told me a war story once about a software project team that had huge problems with so-called non-functional requirements. They knew they were out there and crucial, but the customer was not really helpful and capable of expressing them. In the end they forced a breakthrough by playing hard ball; (read out loud) “So you want a system that is very hard to use and frustrates each and every user all day long”. The shock did indeed create an opening, but I’m sure that, you like me, feel that most people do not like to be shocked, yelled at and bullied. Luckily for us, there is a nicer and more elegant way.

Let’s have a look at non-functional requirements like reliability, usability, efficiency, maintainability, portability and ask yourself the following question: What do these quality attributes have in common from the viewpoint of language?  The answer is that they are all nouns where in reality these are verbs. Or in other words we are actually dealing with active processes in disguise because we are treating them like (physical) things. This phenomenon happens all the time and in all kinds of situations. When somebody tells you he or she is having a depression, he or she is actually feeling bad. The same thing with having fun. You don’t have fun, you feel good.

By now you might wonder why using nouns rather than verbs is bad. Well, it turns out that when process is lost or hidden it is much harder to solve a problem; or, like in our case, accurately specify and communicate requirements.  When you keep treating processes like things, often jargon is required to discuss it. For example: “Oh, what’s the mean time between failure then” and before you know it you have completely lost the customer. And more fundamentally, the brain perceives things as rather unchangeable or static while processes are implicitly perceived as changeable and dynamic. This means that it's much easier to get to the essence of the meaning, increase the accuracy of requirements and to negotiate or down scope so that business value can be delivered at reasonable cost and schedule.

Let’s for example look at availability. A customer might issue the following rather bold requirement:

• The system must have an availability of 100%.

Some of us will question the unrealistic need for 100% availability with the chance of losing rapport or close contact with the customer. When you know enough about the problem space and the customer understands the jargon, a better  approach is asking questions about the underlying processes. For example:

• What is the average period of time within a year the system is allowed to not be available?
• What is the average period of time within a year the system is allowed being unavailable for maintenance?
• What is the maximum time allowed for restarting the system after failure?

And when you haven’t got a clue or you have the idea the customer really does not fully understand concepts like availability, it is more elegant to ask more context free questions like:

• What is it like when the system is available 100% of the time?
• What will happen when the system is only available 90% of the time?

Maybe the customer does not have all the answers, but the discussion will be much easier and friendlier now because we have denominalized the process behind the initial requirement.

A good way to detect nominalizations or disguised or hidden processes is to test if you can put the sentence’s objective (noun) of a given requirement in a box, albeit a large one, or throw it out of the window.  When you cannot, go after the processes behind it.  Can you put usability in a box? Or availability?

For non-functional requirements or quality attributes standards like ISO/IEC 25000 provide categories and more important metrics for evaluation and verification purposes. These metrics do provide a good starting point for understanding and exploring the underlying processes.

There are more language patterns that, when violated, obscure or negatively affect effective communication. In a way they are all translation problems that cause information to become distorted, deleted or (over)generalized. To me this is a one source of obstacles you have to overcome when you are in need of more accurate requirements. When you want to know more about these language patterns, a good source is the NLP Meta-Model, but feel free to drop me a line when you want to know more or have questions.

Iteration: A self-contained mini-project, with a well-defined outcome: a stable, integrated, and tested “release”. Let’s look at the three aspects of this definition in more detail.

A software development project produces a new release of a software product by transforming a set of users’ requirements into a new or changed software product. With an iterative and incremental approach, this process is completed little by little, step by step, by splitting the overall project into several mini-projects, each of which is called an iteration.

From the perspective of the development team, each iteration can be considered to be a self-contained
project. This approach is very powerful because it enables the development team members to focus on meeting their immediate objectives and ensures that the results generated are frequently and objectively measured. The management team needs to ensure that the iteration objectives form
a credible part of the larger overall project.

The management team needs to reinforce this way of working by ensuring that each iteration has the following:

Clear objectives

Each iteration must have clearly defined objectives that are understood and agreed upon by all the parties involved in the project. This unifies the efforts of everyone involved in the project.

Measurable evaluation criteria

For the objectives to function as the unifying theme for the team, it is essential that they are complemented with measurable evaluation criteria that enable the performance of the iteration to be objectively assessed.

A committed team

The team must be singularly committed to working together to achieve the iteration’s objectives.The team succeeds or fails as a whole, and all team members must do everything under their control to meet the objectives set for the iteration; all effort should contribute to achieving the iteration objectives.

A schedule

As well as agreeing on the objectives for the iteration, the management must agree to its schedule and under- stand how it impacts the plans for the project as a whole. Scheduling an iteration can be as simple as setting the iteration’s start and end dates and understanding how the iteration fits into the overall project plan.

An objective assessment

To close out the iteration, it is essential that the results produced are objectively assessed against the iteration’s objectives and evaluation criteria. Assessment should be conducted on a continual basis during the iteration and summarized at the end of the iteration. Without objective assessment it is impossible for the success or failure of the iteration to be judged and for the project to be controlled.

Doing these things ensures a well-defined and measurable result for the iteration that can be tied directly to the overall success of the project. In the next post, I’ll look at The Iteration has a Distinct Set of Activities.

It will not be an easy journey, but here are some steps along the way:

Management needs to:

1. Make IT an integral part of all business units by:
   • Funding IT related projects directly from the business’ budget, and charging business units for their direct utilization of IT. Today, IT is often an “overhead” expense, and business units rarely see the direct cost of what they ask for.
   • “Playing on one team”. The team building starts when the business has identified a project and selected a project lead (coming from the business or from the IT or from wherever) and given her/him a budget. The project lead then selects the team needed to become successful using his/her budget. Some of these will come from the business side and others from IT such as analysts, developers, testers, etc. IT is from this perspective seen as a resource center. (IT has other roles such as leading the way into the future.)
   • IT spending needs to be perfectly aligned with the needs of the business, and the business needs to pay for what it asks for.
2. Choose a technically competent CIO who understands and is respected by the president and the business unit managers, a CIO who can train his/her colleagues in the value of modern technology, a CIO who can lead with enthusiasm and passion. Give him a significant seat at the executive management table.
3. Let IT and business units collaborate during the chartering of projects to define the problems to solve, or the goals that are to be reached, and to work together to find creative technical solutions to these problems, stimulating innovation.  Today, too often, the business requests or demands a solution based on a limited understanding of what might be done, and often based on an incomplete or flawed understanding of the problems to be solved and the goals to be met.  Working together, with a focus on really understanding what is needed and what can be done to meet those needs, better solutions can be devised and pursued.
4. Recruit and promote IT leaders who have business sense, that is, who understand the business and have a proven track record for delivering innovative solutions.  And in the business units, recruit and promote people who can create value by solving problems using innovative applications of technology.
5. Promote IT discussion that value communication in business terms and not in technology terms by continually focusing on how technical solutions will create business value.
6. Stimulate cooperation and collaboration between IT and business units by ensuring that representative of both speak with one voice and avoid one-way 'monologues'.

The projects and the teams

1. Prioritize the projects based on the business value that they will deliver over their planned lifetime, and considering the full lifecycle costs and benefits, not simply the initial costs and benefits.  Most project funding requests fail to consider the long-term costs and benefits of applications, resulting in unfunded long-term support costs.
2. Both business and IT must participate in the development project as if the business depended on it - which it should if the project is worth doing.
3. Measure the performance of the project against the goals established in the business case, and hold the team, with representatives from both business and IT, accountable for these results. Even before the project delivers, measure results in business terms such as the number of business scenarios that have been implemented and tested - don’t measure progress in terms of completion of documents. When you publish internal progress measures, always present them in business terms.

Product (software)

Derive software architecture from the business model – for instance starting from the business use cases, the business entity objects, the workers and translate these to a road map representing the system's major components and their collaborations and fill the map with executable code, project after project.

Method (process)

1. Apply practices that may get the business side and the IT to collaborate and which, if correctly performed, result in measurable success. Then the two sides will win together.
2. Develop iteratively: deliver frequently and encourage requirement modifications after each delivery.
3. Formulate requirements and tests as use cases: specify, develop, test and validate–a little at a time, starting from the essentials, over and over again until your customers accept
4. Plan product releases together: understand the purpose and intention of each release, ensure the product addresses the real business needs, synchronize business and development plans, involve the right people
5. At the right time, understand everybody's commitments.
6. Use a dash-board: look at what’s important: better, faster, cheaper, happier, and present it intuitively using the language of the business.
7. Organize cross-functional teams, one for each business feature: bring all the skills (marketing, product design, software development, financial, business process experts) necessary together to make the change.
8. Formulate business processes as business use cases: lean business design, just model the bits of the business that are being changed, identify increments of business change so change can be made early and often. An agile approach to business modeling.

These are steps on the path to reducing the gap between business and IT, making the IT and the business true partners and removing the customer-provider relationship that is not working. The goal is of course to generate revenue, reduce cost, and improve the customer experience. It's smart for business, and that will be smart for IT.

1. Avoiding Confusion – there is a big and noisy world of competing processes and methods out there. How do software development teams find the right practices for their specific needs?
2. Team efficiency – do we really want our development teams to constantly have to reinvent new solutions to old process problems when they should be focusing on writing great software?
3. Supporting Diversity – some software engineers need / want more explicit practice guidance than others. How do we provide just enough guidance without being overly prescriptive?
4. Consistency – if every team works differently, how do we get resource mobility / flexibility?
5. Governance – how does the sponsoring organization manage the risks associated with its investments in software and ensure visibility of progress towards a successful outcome?

We face the following Hegelian Dialectic (I graduated in philosophy – you have to humor me!):

1. Thesis: Prescriptive process kills the golden goose (development team creativity and motivation)
2. Antithesis: Removing the prescriptions can distract, confuse and frustrate the team and its stakeholders
3. Synthesis: We need some kind of smart practice framework that enables us to provide clear direction on what needs to be done and just enough default standard guidance on how to do it, but enables teams to easily refine or replace practices that are not exactly right for them.

This smart practice framework is known as a process kernel. In this short series of blogs I will describe in a little more detail at what a kernel is and report on my experiences of using process kernels in practice to enable my customers to find answers to some of these seemingly intractable process problems.