Process Improvement

Are you ready for iterative development?

Are you ready for iterative development?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

De wereld van Practices – Wat is een Practice?

De wereld van Practices   Wat is een Practice?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

The Kernel Journals 7: SatNav for Software Development Projects

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).The Kernel Journals 7: SatNav for Software Development Projects

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.


 

Each Iteration Results in a “Release”

To ensure that the project is making progress, each iteration is forced to produce something tangible: a “release.” This release can be:

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

An Iteration Has a Distinct Set of Activities

An Iteration Has a Distinct Set of ActivitiesEach iteration is unique. It involves undertaking a unique set of activities to produce a unique version of the product that objectively demonstrates that the iteration objectives have been met.

Because of this uniqueness, each iteration requires its own iteration plan. The iteration plan contains the details of all the activities that the team is required to do to meet the iteration objectives. The amount and style of activity-level planning required for a project is dependent on many factors including the project risk, team size, experience levels, and the manager’s own preferred management style.

For some projects, an informal plan describing the goals to be achieved and listing the tasks to be undertaken is sufficient; you can leave the scheduling and allocation of the activities to the development team. Other projects require more comprehensive plans that describe the activities and their allocation in greater detail to work out the dependencies between the tasks to be performed by the various team members. Read More

What is an Iteration?

What is an Iteration?

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:

Read More

The Kernel Journals 5: Making the Invisible, Visible

The Kernel Journals 5: Making the Invisible, VisibleThe 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.

Read More

Navel gazing is not a bad thing

Navel gazing is not a bad thingI 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”?

How to stop thinking about business as “the customer” and IT as “the vendor” by Ivar Jacobson

How to stop thinking about business as “the customer” and IT as “the vendor”In my last three blogs, I discussed how we can close the gap between the business and IT. I summed up the way forward with the advice to stop thinking about the business as the customer and IT as the provider. Instead, let them work together in teams (similar to members of a soccer team), responsible directly to management.

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

Read More

The Kernel Journals 4: A Cure for Document and Template Addiction

The Kernel Journals 4: A Cure for Document and Template AddictionMany organizations have achieved a degree of process maturity (reliability, discipline, consistency) only by paying a very heavy price – they have become addicted to documents and document templates.

Unfortunately, it can happen all too easily. Most processes end up being document-centric even though they never set out to be so. They start by offering useful process guidance on how to progress the project in a controlled way, in the form of a set of activities, each of which is defined in terms of the artifacts it produces. Most artifacts are documents of some kind and the process helpfully comes with templates for each document – a template is better than having to start with a blank sheet of paper, after all. The project milestones we need to pass through are evidenced using the documents, and the whole thing hangs together nicely. Read More

Page 2 of 3123