The 6th annual Agile China was held in Beijing from September 1 – 3, 2011. Agile China is a summit of agile world enthusiasts gathering in China. For the past five years, it’s attracted world-class agile experts, such as Martin Fowler, Kent Beck, Dave Thomas, James Grenning, and Mary Poppendieck et al, and tens of  thousands of attendees across China and overseas. It represents the highest level of development and adoption of agile development in China.

This year’s conference proved to be another successful event. The three-day event was packed by some 700 attendees. The conference was opened by Mr. Wang Jun, General Secretary of China System and Software Process Improvement Association, the host of the conference, and keynote by Linda Rising, the authour of “Fearless Change”, followed by parallel sessions on agile training camp, agile new trend, and agile testing and quality control. People gathered to share their experience and to explore new ideas and  trends. The conference atmosphere was full of energy and excitement. Particularly, I truly enjoyed the free style of discussions and presentations – in a real agile spirit. Read More

We have seen in the previous kernel journals that a process kernel, defined in terms of the key domain entities, or Alphas, and their value state progressions, can give us a simple, shared view of what each and every project has to achieve (which is common across all projects), that is distinct and separate from how they might go about doing it (which may vary from project to project).

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.

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.

Read More