Traditional software development projects are executed in a value-neutral setting in which:

• 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. Read More

Over the last few days a number of people have asked me the same question: “How can we get more accurate requirements?” While I agree it is not nice to answer a question with a question, in this case you might bend etiquette a bit because in reality this question can be hard to answer. For example, why is it necessary and which problem does it solve? Or, what exactly do you mean with accurate?  And do you have accurate requirements and you want more of those? And in that case, more than what? Or do you have inaccurate requirements which you want to become more accurate? And if so, how much more?

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. Read More

Iterative development is simple in concept: it is simply breaking a large project down into a series of smaller projects that deliver value in smaller steps. The hard thing about adopting it is that it requires the project team members and stakeholders to adopt a new set of attitudes and behaviors about how they work together to achieve a common goal. This requires subtle but significant changes on the part of all participants, especially if they have been working on conventional projects for many years. In short, these changes include the following:

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. Read More

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 More

In the last Kernel Journal we looked at the problem that Barry Boehm was aiming to solve back in 1995 when he first proposed his three standard process milestones (which later gained industry prominence as the milestones in the Unified Software Development Process and the Rational Unified Process), namely that “the proliferation of software process models provides flexibility”, but leaves us “with no common anchor points around which to plan and control.” [Barry Boehm, November 1995]. We looked at how a small set of domain entities with simple state progression models (which we call “Alphas”) can make these common anchor points much more practical and useful while ensuring that they remain process-neutral and do not become “document-driven”.

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.