Understanding the potential barriers to change will help you make the right choices of timing, project, and approach. Some of the more important questions to ask include in the following:

• How supportive is senior management of the change? The measurements and milestones
  they establish can easily derail an iterative approach, as is the case when they ask even seemingly
  innocent questions such as “When will the design be completed?” or “When will requirements be
  signed-off?”
• What is the scope of your authority to make changes? How much of the development lifecycle
  are you responsible for? For example, the requirements might have already been specified in a
  format and to a level of detail that would make it more difficult to adopt an iterative approach.
• What are the team’s feelings about the changes? How enthusiastic is the team about iterating?
  To achieve the transition to iterative development, you will need the support of the team,
  especially the other members of the leadership team.
• What else does the team have to do? How many other projects and initiatives is the team involved
  in? If the team is not focused on and dedicated to the project, the transition to iterative
  practices will probably be slower and take more time and energy to complete.
• What capability do you need to improve? It is important to understand the capability of the
  team and how well the current capability supports the proposed iterative approach. For example,
  is there any testing capability in the team? Testing will be needed from the first iteration, which is
  often a problem in companies organized around the phases of a waterfall approach.

The ideal characteristics of an iterative project, and an actual project’s characteristics should have: 

• a co-located team,
• of less than 10 people,
• who are highly-skilled,
• and largely self-organizing
• who operate with low ceremony,
• and who are minimally dependent on outside teams,
• with highly-engaged business representatives.

These perfect conditions, in fact, almost never exist, but understanding them will help you choose
projects that are better suited to an iterative approach.

When you start your first iterative project, factor the successful adoption of iterative techniques into
the critical success factors for the project and the career development objectives for the team members.
This is especially important if circumstances require an investment in training and mentoring
the team to enable the transformation to take place.

Conventional wisdom suggests that you should choose low-impact, non-critical projects to be the
focus of early change efforts to reduce the change effort’s risk and the potential for failure. The problem
with this is that although these projects are lower risk, their non-criticality usually means that
they are starved for resources and not considered “mainstream” enough to ever be taken seriously as
success stories. This dooms the overall change initiative. Low-priority projects are not visible enough
to engender the support needed to drive the change forward.

Instead you should:

• Look for a small number of must-do projects that have organizational focus and strong support
• Look for projects with a smaller set of stakeholders to keep communication simpler
• Look for projects with high internal visibility—ones that would make good success stories
• Choose projects that are shortto medium-term in length
• Staff the projects with the best people available (respected leaders)
• Organize projects to generate short-term wins—divide work into iterations
• Keep the project size small in the first few iterations and then scale up
• Focus on choosing the right projects and committing resources to them

Choosing critical projects sounds risky, but the reality is that only critical projects will get the attention
and resources necessary to succeed. The key is choosing projects critical enough to get resources
but that can start small and then scale up in a controlled way, not becoming too large before the
architecture and technical risks can be brought under control. Scaling up should be targeted for the
Construction phase but not before.

*The first post in this series can be read here

Before I describe the deck of cards, I’d like to set the stage for using the cards. We can view software development from three time-scales (see Figure 1). Successful software development process is in essence, being able to coordinate the three time-scales effectively.

• The broadest time scale covers from the beginning to the end of a software development cycle which is marked by several key business decision making milestones. This is of great interest to stakeholders and decision makers on whether development can proceed or whether the software is suitable for release.
• The next time scale breaks the lifecycle into time-periods – months, or weeks, or what is known as an iteration. It is a fixed time-box where a number of target objectives are to be met by a development team. If there are multiple teams, then each team would be assigned their specific set of objectives. This is where team leaders operate.
• The lowest time scale is what a team member does. The work done here can be in terms of hours or days depending on the complexity of the work.

Figure 1:The Three Perspectives to Software Development.

A major problem I see in many development organizations is the serious disconnect between the three levels. The objectives set at the higher level do not easily translate to work at lower levels. Lower levels are unable to see their contribution to higher level objectives. There is a  miscommunication between the levels, and poor coordination within the same level, which leads to blockages which should not even happen. We need to solve this.

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.

On a traditional project, change is viewed as a bad thing, and great efforts are undertaken to prevent it. Change disrupts the original plan, and it is the plan (and not value delivery) that is sacrosanct on a Traditional project.

Similarly, change must be embraced. Change results from new information, from feedback that something in the original plan will not result in the desired end result. Change is something that will occur as people get new information, but change is a good thing: it means convergence on the right solution.

Change is not the same as churn - churn results from the business not being clear about what it needs to achieve, or from the lack of a suitable technical solution. Churn is a sign that some basic assumptions about the project have gone horribly wrong, and the project team needs to stop and step back to reassess where it is going.

Aggressively attacking the project’s risk requires the process to be agile, not prescriptive. The project must be able to do whatever is required to address its most important risks and must not be limited in the set of activities that it can apply. For example, if the most important risk facing a project is the integration of several commercial products, then writing the requirements for the integration does not significantly reduce the risk; only the creation of an executable prototype that demonstrates that the products can work together truly addresses risk.

The fundamental problem with conventional waterfall approaches is that they postpone risk mitigation to the point where it can become too costly to recover from the risks. The waterfall approach tends to mask the real risks to a project until it is too late to do anything meaningful about them.

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”).

The business does not really care how agile we are, they want to see results.  They want to be able to set targets, see improvements, and understand the benefits and the quality of the results being generated by IT. Only then can they begin to put the value of Agility into context – the context of the value and improvement generated by the move to agility.

I’ve seen this conundrum many times.  At IJI, we get involved in many Agile transformations –very large scale Agile transformations.  One of the key enablers for success is to be able to demonstrate that things are getting better.  Not just better in the short term, during the first flush of enthusiasm when the A players are adopting the new techniques, but in the long term as we continue on our journey of continuous improvement - seeing improvements in every quarter, every six months, and every year.  Large scale Agile transformations are not things that happen in a few weeks.  You start to put things in place and then you continue to improve, inspect and adapt as you go forward.

You need a way to make visible where you are and where you are going.  You need to do it in a way that everybody understands. 

What we see is that most measurement programs do not really achieve those kinds of goals.  A lot of them add very little value.  People look at the wrong things. They have lots of numbers, lots of quantitative measures but very few qualitative measures. They tend to measure the things that are easy to count rather than the things that are important. They tend to collect secondary rather than primary measures. For example rather than measuring, and communicating, the quality levels of the software produced, they will tell you the defect detection rate. Rather than measuring the effect of agility they will measure the number of people who think they’re agile. This leads to the classic question being asked by the business; “OK, now we’re all agile what difference has it made?”  

There is also too much focus on short-term rather than long-term measures. Remember, the transformation is likely to take more than a few months and you need to be able to show continuous improvements and not just the initial impact of introducing the new ways-of-working.

You need to find a set of measures where things are very intuitive; where everyone can understand the measures without having to have a training course or deep knowledge of IT. You need simple measures where the direction of improvement is clear. The best measures are simple and easy to understand.  They are not complex derived measures; they are not indexes that take into account project length, cost over-runs and things like that.  They are not measures based on theories that are not based on anything.

Let’s measure the things that really matter.  Let’s look at the effects, as well as the causes.  Let’s make sure we have evidence that Agile is a better, faster, cheaper, and happier way of working than what has gone before.

A new attitude is required regarding the way that projects deliver business value. The project team must start to focus on delivering immediate and realizable value back to the business.

A new attitude is required toward uncertainty and change: teams must recognize that change happens and there are always uncertainties, so in order to be successful they must purposefully work to manage change and reduce uncertainties.

A new attitude is required regarding team working and accountability. The project teams will • need to be assembled and encouraged to interact in new ways.

Most significantly, a new, more progressive attitude is required for the estimation, planning, and management of the project itself.

With new attitudes in place, the adoption of iterative development practices becomes easier. If the project team and stakeholders have the wrong attitudes toward iteration the early iterations are more likely to produce personal friction than project progress, in some cases generating enough opposition to prevent the project from being able to produce effective results.

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.

• A prototype that is used to demonstrate some specific capability
• An “internal” release that is used to elicit feedback and that serves as the basis for further development and testing
• An “external” release that is shipped to customers in some form

The following is our definition of release:

Release: A stable and executable version of a system.

The production of something executable during each and every iteration is so important to the iterative approach that some people even go as far as to assert that “The goal of an iteration is an iteration release: a stable, integrated and tested, partially complete system.”

In every iteration, all the software developed by all the teams involved in the project is integrated into a release. This series of releases provides the project with regular technical visibility points where the state of the project as a whole can be considered.

The idea that each iteration produces a release can seem confusing if you think of a release as something that is delivered to people outside the project team. When we use the term “release” we mean something that can be executed and evaluated, including things that are only evaluated internally such as prototypes, as well as external product releases. The early releases are incomplete versions of the system that demonstrate particularly important characteristics required of the system and address the major technical risks facing the project. As the project progresses, functionality is added incrementally
to the software produced by the earlier iterations until sufficient functionality is available
to enable the system to deliver real business value. After this point, subsequent releases can continue to be developed that implement additional capabilities.

An iteration’s release becomes a product release when you decide to release it to an operational environment for unconstrained use by the user community. Many of the releases produced will have the level of quality and completeness required by a product release, but not all will be worthy of release. For example, the release might contain insufficient functionality to be useful to the users, or the users might not be ready to receive the release. Each consecutive release should be marked by:

• A growth of functionality, as measured by the implementation of additional functionality during the iteration
• Higher quality, as measured by a reduction in the number of product defects
• Reduced risk, as indicated by estimate fidelity, risk magnitude, and stakeholder confidence

When planning an iterative project it is important to understand the purpose of, type of, and audience for the release to be produced by each iteration.