Key Activities

Our processes help us to deliver stable solutions in the quickest time possible enabling our clients to gain benefits sooner.

We achieve this by adapting standard Agile techniques to our needs, enabling projects to move forward in series of short cycle sprint iterations (typically two weeks).  At the end of each stage, our clients gain visibility and even access.

Below we discuss the key events in this process.


At IDC, we start by producing the design language and prototypes, or visual representations, of significant areas of the solution.

These are undertaken by a designer with the assistance of the product manager (also referred to as the analyst) and finally verified by the technical team.

Once these are signed-off by the client then the project begins.

NB: additional design-builds may occur within step 3.


The product manager, the scrum master (project manager) and the technical team hold a Sprint Planning Meeting to negotiate features undertaken in a sprint iteration.

The product manager prioritises the features (referred to as stories) most important for the business. The team selects the amount of work they feel they can implement within this sprint.

Towards the end of the meeting, the team breaks the selected stories into an initial list of sprint tasks and commit to undertake the work.

The scrum master updates the stories to a sprint backlog using a scrum storyboard (reporting tool).

Meetings typically take four hours, clients are welcome to attend.


During an iteration, each team builds, and test the Stories developed in the course of the planning meeting.

Built-In quality practices are an integral part of each iteration and include:

  • Test-First (manual and automated)
  • Continuous Integration
  • Refactoring Pair work
  • Collective ownership


At the same time and location, the technical team members spend a total of fifteen minutes reporting to each other in a stand-up meeting.

Each team member summarises what was done the previous day, what will be undertaken today, and any potential impediments they face.

The daily scrum meetings are not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting.

The product manager often attends but the scrum master facilities the meeting and ensures the storyboard is always up to date.

The scrum meetings are an excellent way for the team to disseminate information.


After completing a sprint execution, the team conducts a Sprint Review Meeting to live demonstrate a working increment to the product manager and ideally the client.

After the demonstration, the product manager reviews the commitments made at the original sprint planning meeting and declares items considered shippable and therefore done. Incomplete stories are returned to the Product Backlog with product manager’s revised priorities, the scrum master updates the storyboard accordingly.

By interacting with a piece of functioning software the meeting is an opportunity to inspect and adapt the product as it emerges, and iteratively refine everyone’s understanding of the requirements.

Iterative development allows the creation of products that could not have been specified up front in a plan-driven waterfall approach.

The meetings can take two to three hours.

After this meeting, the scrum master and the technical team conduct a separate retrospective meeting to reflect upon decisions and approach with the aim of improving overall efficiency. 

After this stage, we return to Step 2 until the entire project is deemed to be complete.

Return to Analysis

As business needs change or clarified, the Product Manager can revist areas of the analysis