Client Case Study – Agile Adoption:


Case study synopsis 

Scrum image

This case study aims to highlight the exceedingly evident benefits and monetary savings to be gained from adopting agile in any organisation, as well as exposing the inefficiencies that plague most organisations and thus bog IT delivery down. This project is a shining example of how organisations can be transformed when committed to the agile process, and the massive advantages to be gained from doing so.

Take a sneak peak as to what we did here…


 Project context

Most organisations feel that IT is not delivering value or that IT is not delivering fast or efficient enough in response to business needs and changes within the organisational environment. This is often true and this project was no exception.

The following were motivators within the environment that triggered a consideration for adopting agile:

  • some areas of existing project delivery was really chaotic and always late.
  • lots of new client projects were on the horizon within these areas and existing project delivery was already chaotic.
  • some areas where project delivery was not chaotic only 1 client was supported, so questions were raised as to what will happen with new clients coming into these spaces.
  • business was not happy with delivery internally: both requirements and quality was a concern.
  • delivery timelines for projects delivered by an outsourced partner in India were too long, up to 12 months for 1 release per project / area per year. This posed a greater concern with the multiple simultaneous client take-ons scheduled.

Projects were being managed in the following way before the adoption of agile:

Detailed project plans were used from Microsoft Project to track delivery of project stage gates. Microsoft Project Server was used for this and reports were built on top of the project server database in order to measure financials. From a project management perspective, the focus was on each individual interacting with the project plan to capture time against a task on the project plan. The project plans were thus used by team members to look at their work in isolation.

Using this approach resulted in 1 person being allocated to 2 – 3 projects simultaneously. Further to these interdependencies between teams and team members communication in a collaborative approach was lacking.

We hoped to achieve the following benefits with the adoption of agile:

  • better visibility of work across the organisation
  • more efficient way of delivering on projects
  • ability to take on more work with existing staff
  • happier clients
  • better quality releases
  • more frequent releases
  • closer collaboration
  • flexibility in people planning and the way
  • shorter analysis cycles
  • shorter testing cycles
  • discussing requirements closer to delivery in smaller chunks support smaller release
  • better mechanism for documenting requirements in a more optimal way

The initial agile implementation started only in part of the teams within IT. That produced benefits up to a certain point. As these teams interacted with others within the organisation that were doing things the old way (as described above), it hindered the full benefits of an agile adoption. To overcome this it was suggested that a high-level assessment of the whole IT landscape is done in order to get a better idea of how to structure teams and ensure an effective agile rollout across the entire IT landscape.

The initial phase of the agile implementation was done across 120 people in 3 months. Further maturing of the agile implementation took up to 15 months.


Measuring key successes using agile metrics

Increase in team velocity

The problem often experienced with metrics are the risk we are running of people manipulating the metrics to get a desired outcome. In order to counter possible manipulation of metrics that can skew results we made use of baselining stories so that we always measure back to the same metric we originally defined. During estimation the Scrum Master, Product Owner as well as the Team will also challenge each other on estimations given to ensure it is accurate.

One of the metrics used to measure a successful implementation was focused on the amount of work delivered by teams that was suppose to increases as the team optimised delivery and streamlined how they work together.

Here are the statistics from 2 areas within the IT organisation for 3 months of delivery:

Team velocity - increase

Team velocity - release

Increase in number of releases

The number of releases increased drastically per year, without the implementation of an automated testing framework. Just focusing on changing the way people are grouped and how they work together made it possible to achieve these results. Releases could increase more if automated testing was put in place and the business gained more trust in the stability of releases.

No of releases

Decrease in number of people involved in delivery of more

Ideal no of people for the project load was determined and no new people were recruited, unless it was related to a new project and the existing people capacity could not provide for the project.

No of people

In Team A this translated to R1.2 million per annum to their bottom line

Decrease of team sizes

All the people from different areas were run as a single project team, excluding supporting services. No formal team boundaries existed outside of the grouping of people into business areas. The way people were allocated to teams changed and teams were broken down into teams of 5 or 6 people max per team per area or project.

Team size

Minimising key man dependencies

A skills transfer plan was defined in certain areas and implemented. This was done to ensure more cross skilled team members in areas where keyman dependencies existed. Implementing this on a project with deadlines was really tough and stressful for the new learners. In the end 5 extra people were made available to run this specific annual project, where there used to be 1, so this was a huge success and put this area in a much better place.

The areas where a deliberate skills transfer plan was not driven, we still experienced key man dependencies. This is still a problem and causes delays and bottlenecks on projects.

By implementing this we minimised knowledge locked in pockets.

Knowledge spread

The power of visibility

In the production support space we introduced Kanban using Jira Agile. Having the work visible assisted teams to reduce the amount of calls not worked on very quickly.These calls were closed within a 6 week period.

Visibility - calls not closed


Key Learning points

Applying partial Scrum disciplines to an already running release

In Nov 2012 when we started working with one of the areas, they were already running a release with an offshore team. The offshore team was not familiar with agile at all and the deadline was tight. We decided to not disrupt the already running project too much and decided to introduce some key aspects of agile, namely reviews & daily standups. The outcomes include:

  • Increased collaboration that resulted in a reduced testing cycle and less changes towards the end, but rather continuously throughout the process.
  • It was indicated that this was one of the best releases in years with this team.
  • The release was delivered on time
  • Working with the offshore team was streamlined and the client is happy with how agile assisted them to better utilise an offshore team

Put agile metrics in place from the beginning

We focused on putting agile metrics in place later in the process. This was not the right approach and should have been done upfront, so that cycles and releases could be compared with each other and used as motivators throughout the process.

Financial actuals was not visible

Incorporating the capture of budgets against the new way of estimation using story points was not automated or put in place at the beginning. The old approach had this developed and in place already, so it was no longer as easily accessible as in the old methodology and it took more discipline to do it as the process was now manual.

Reducing team interdependencies

Grouping people together that work on projects, while making sure that they are not sitting idle. Some people can be grouped together in cross-functional teams, but others should be grouped around product areas. We used a hybrid approach to get the best team configuration across the whole of IT.

Not enough business involvement

This was specifically relevant for areas where a line of business system was being used by the internal business and not by external clients.

The agile rollout should have involved internal business in training and more in-depth exposure to agile from the beginning. As this was not a mandate as part of the project, the business did not understand the change in process and the benefits of them attending meetings with IT or being more involved with IT delivery. This caused them to not participate in scheduled reviews or plannings. There was also a lack of understanding their priorities and their requirements in depth.

The latter resulted in the following:

  • the wrong things being prioritised for IT delivery
  • the delivered item was not 100% speced
  • not 100% buy-in
  • not understanding the process and terminology

Better client involvement

Enough business involvement on projects where clients were external was a problem initially at the start of the agile implementation. Later on, as the agile implementation matured clients were more closely involved in projects. This resulted in faster releases.Less issues are identified during formal UAT.

The power of collaboration and a common goal

Having a common goal and grouping people together in smaller teams that works towards the same goal is invaluable. Daily short intervals of collaboration do guarantee better delivery.

The power of agile tooling

Although metrics on delivery was not measured from the beginning, the use of Jira Agile as an agile tool for delivery made it possible to retrieve the data easily in retrospect. In today’s organisational landscape, having information readily and responsively available at your fingertips is really NB.


Ongoing challenges

  • Finding a balance between protecting the integrity of your product while still delivering on client specific projects.
  • Getting the sales team to commit to realistic timelines using the known teams’ capacity.
  • Getting teams to not change scope in sprint as can be seen on the project burndowns.
  • Some parts business is still not participating. They do not pitch or participate and then it results in not taking ownership or accountability.
  • Some parts business is still not participating. They do not pitch or participate and then it results in not taking ownership or accountability.
  • Implementation of automated testing: Limiting form of unit testing in certain areas, with no automated testing is in place.
  • Release cycles get to a point where more time is spent on testing than actual development.
  • It is also very difficult to get started on the implementation of automated testing. Although automated testing framework was implemented and provided as part of a POC, this has still not moved forward.