CodeStep UK

01268 451 696

CodeStep UK's new "ICE Race" Lifecycle

From our experience of working with many customers and suppliers we have learned an Agile process is not good enough.

The misconception about Agile is that it is flexible - and that flexibility gives room to move and change

But it also creates gaps in the management, oversight and delivery that can cause failure, cost overruns and miscommunication

Introducing ICE Races

Our Integrated Cycle of Engineering (ICE) process uses a digital tracking tool and multiple "Races" to deliver a streamlined and coherent approach to these problems.  It isn't replacing, or incompatible with Agile - but ensures that any project is properly executed to an engineered standard

A "Race" is simply defining the process to manage:

  • Requests for change
  • Acknowledgements from stakeholders
  • Confirmation of the process
  • Engagements of the delivery team
  • Starts and Successes

Every RACE can combine other Races.  At every second Stage - new RACEs can begin

Where possible and appropriate, we also use our DreamServer DSX Technology to provide an Integrated Lifecycle process to deliver software in a managed and automated way

 Quick Contact

  (Open in new window)

Let the RACE begin!

All Races begin with a request to deliver.  The first race defines every stakeholder, every decision tree and every authorisation level needed to ensure a streamlined communication mechanism keeping everyone involved up to speed with the development of any service

One Request - leads simply to 2 choices

When a REQUEST is received - it must be properly documented, defined and understood via the ACKNOWLEDGE step from every stakeholder.  Too many Agile users do this in different ways, to different standards and often to different people.  Agile development can stall and fail because the right people were not consulted at the right stages 

Once a request has been Acknowledged it may already be properly documented, with stakeholders simply asked to CONFIRM the race, or stakeholders can request that more steps are required via another "Sub-RACE".  This simple binary choice keeps things simple, and ensures there are no misunderstandings and everyone is informed

Optional Sub-Races allow the "fleshing out" of detail and ideas or understandings - they can be created by any stakeholder before they confirm the previous Race

When any Sub-RACEs created by the 2nd stage are complete, each stakeholder can CONFIRM the RACE can run

Requests, Details and Stakeholders Confirmed

Only when all stakeholders have Confirmed their agreement and no other "sub-races" are still running - the active race will ENGAGE and START the request

The first Race

When a new project is started for a customer - a simple structure will allow everyone involved to know what decision making processes the customer and suppliers need, which stakeholders must be notified and who has the ultimate decision to Direct the race

The "Race Director" is usually the customer - and the person ultimately responsible for choosing whether or not a RACE can Start.  Once this person signs off with the confidence every stakeholder is happy, the delivery team will engage and start the process of building the solution using CodeStep's "3-2-1 Launch Control"

Sub-Races create more wins

It is important at every stage of Acknowledgement that stakeholders are given the chance to start and "Direct" their own Races.  By allowing any stakeholder to direct a race - everyone can be sure that the required level of detail is provided to ensure a swift and perfect delivery each time

When the RACE is finishing - it's time for the FLAG !

When the race is complete there needs to be a flag so everyone can confirm the delivery is complete.

The FLAG ensures everyone is happy and:

  • Feature Requests are Complete
  • Lessons can be Learned
  • Agreement to Launch and Deploy the solution
  • Goals for the future are Identified

A good project is never finished.  Business demands innovation and efficiency - and it's important for every RACE that improvements are made for the next one

All Stakeholders are invited to confirm Features are Complete for each Race - and at the same time identify any problems or issues where Lessons can be learned.  

An Agreement from everyone records a successful race and a Launch can commence

Often new features are identified as essential and a new Race needs to start before a project is launched - or they can simply be recorded to ensure there are Goals defined for future Races

When the project is complete, it's time for the ICE!

When every race is complete and a solution delivered - all the history, knowledge and decisions made are frozen to later help produce an engineering document allowing a solution to be accredited - but more importantly - to ensure the future of the solution continues no matter what changes get made, or who the team includes

But the work doesn't have to stop - Our projects on ICE are still designed to grow!

Our Integrated Cycle of Engineering (ICE) process is designed to keep old systems up to date with little or no effort.  Using our DreamServer DSX Technology - old applications can be republished with new features and improvements, often without any re-coding or re-working.  We designed our solutions to be updatable right down to the code level - and to be done in an automated and managed way

Keeping RACEs simple, and still Agile!

A race can work with multiple methodologies - importantly though it isn't designed to replace then

One of the most common styles in recent times is Agile - but Agile doesn't deliver standards

Our online tool will help alleviate this problem - ensuring all Requets, Acknowedgements, Confirmations and Engagements are historically visible and just a few clicks away from the important Success and accreditation

CodeStep.UK's simple ICE RACE & FLAG strategy will help to ensure projects last a lifetime, are delivered as efficiently as possible - and communication is managed at every step

CodeStep UK's 3-2-1 Launch Control

No matter what standard or methodology ultimately used, our Launch Control process is independent and offers a pressured delivery schedule to keep our team and customers fully informed

Every Project will have a number of stages where "things are still being worked out".  We call this the Alpha Stage.  There can be multiple Alpha stages, but throughout the delivery customers will have the chance to login to the solution and see the progress as new features are added.

Most often we allow for 3 or 4 major "Alpha" versions to be delivered before a solution starts to settle into the final stages of delivery and launch.

With all software solutions, there are always changes, modifications and improvements that are identified by both us and the customer during development.  Simple tweaks to interfaces for better layout, fine tuning of performance or additional tools to help streamline user workflows

We usually offer 3 x "Beta versions" to run this process.  The first is the collection of all original requirements hopefully delivered "bug-free" - but perhaps need tweaks to help users work with the new tools.  Further Beta versions will be produced incorporating any change requests the customer needs

Next comes 2 x "Release Candidates".  The first is released as if it were a final version - but gives the customer the opportunity to perform User Acceptance Testing (UAT) or field research to ensure the solution meets their requirements.  Any feedback is implemented in a single, final release candidate version.

Once the user has completed the UAT process and any issues are ironed out - the final and most important "1 x Final Release" will be delivered.

It's that simple.  Defined, documented and ready to launch into the real world.

The Agile process became lazy - the Race to fix it begins here!

The Agile method has been around for a while - but unfortunately it became hijacked by laziness, poor documentation and poor standards.  We monitored many different projects, people and businesses and have been shocked to see Agile misused and misunderstood in many different scenarios

Plus, without a properly documented process - a solution can never be accredited to any ISO or public standard

An "Agile-only" project is a recipe for disaster!

Decisions can be forgotten, lost and overridden without the correct people knowing.  Costs can get out of control and in the worst case people don't benefit from the time they've committed, and we've even seen some people not receive payment, despite verbal promises that because a project is "Agile" costs would be passed on.  The truth however is very different! 

Often managers are replaced by others that have no idea of the history or what has been agreed. Worse, multiple managers each make decisions without talking to the others - confusing the delivery team or creating conflicts later on

We don't allow our suppliers to miss out on the chance to be the best at what they do - and nor will we allow our customers to miss out on having a world class solution delivered

By ensuring every Agile request is run to our simple new RACE standard - every person can be assured they have the chance to direct their decision process in a historically trackable way - every stakeholder knows in advance the resources, time and costs required - and every business owner can be sure their solution can be carried forward with all the knowledge of the past permanently attached to the lifecycle of the solution

Adding RACE to Agile doesn't mean endless paperwork!  Agile was designed to streamline the process and we don't want to take away from that.  But good software demands certain standards - so our new online tools integrated with customer solutions can ensure a minimal effort is required to keep solutions trackable and to a high standard. 

Combined again with our DreamServer DSX Frameworks - we can deliver an engineered and ISO compatible standard of service

An Agile RACE engineered

Our experience allowed us to monitor, audit and challange the standard ways of working

By engineering our solutions - we can make sure everything we deliver is on spec, and more imortantly - can last a lifetime