The optimal path to success is via failure

How Agile delivery transcends

Everyone has been a part of a project, willing for it to be over, disliking the results that they’re getting, and feeling like the project is rigid and they are restricted in their ability to implement innovative solutions. Agile is a tool known by many, used by some and truly understood by even less.

By Rebecca Maserow

The entire team needs to be behind the revolution of Agile in order for it to be truly effective. Mohamed Bray from Saratoga gives an overview of how he has not just adopted Agile, but how his team embodies the ethos of Agile, and how it’s helped his clients save millions of Rands.

The case study discussed below is an example of Agile in action and gives an idea of it’s success, in the end Mohamed’s team were able to reduce project budgets by 38% and helped the cost per unit of work fall from almost R40,000 to under R25,000. See below the vision of Agile that helped Mohamed’s team reach this success.

Agile is more than just a methodology

A quick aerial view of Agile is plan – do – check – adjust. These four stages run olympic circles around projects until not just a solution is found, but the best solution is found and maintained. If Agile had a tagline, Mohamed suggests it would be that failure is your best friend, a necessary force guiding learning and innovating, “you’ve got to try stuff in order to learn how to get it right.”

Agile is already adopted by many in the industry, however Mohamed believes there is still a change of perception that needs to take place, “everyone in the IT world thinks of Agile as a methodology, it’s not, it’s a way of being, you either are or you aren’t.”

“Many people have bastardized Agile into a methodology, forced it to be a process. But it’s a culture, a mindset, and a set of characteristics. There are aspects to the concepts of Agile that are mechanical, but really what you are after are the principles of Agile. Agile delivery is a paradigm shift. In order for people to change you have to let people see, feel, touch. It’s the only way.” In the case study, the stakes were very high, with over 8000 users of a mission critical financial application and selling 90% of the multi-national’s products. Delivery was affected negatively due to a growing backlog of issues, the software was buggy and there was a distinct split between business vs. IT. The latter was one of the first things that Mohamed’s team changed; making business and IT sit on the same side, adopting Agile and using it as a tool to remove obstacles from the workflow, encouraging a more dynamic interaction that involved mutual learning.

“We started time-boxing things in sprints in order to benchmark. These are the mechanics of it. It goes:

  • Sprint planning
  • Backlog grooming
  • Prioritization
  • Analyse, develop and test
  • Demonstrations
  • Retrospectives

These steps work to change behaviour, to force the team to work in a different way.”

Agile rests within the ability of the people, to ensure that you get the best results, the team needs to be finely tuned with the same objectives. Mohamed says “the end goal of Agile is high collaborative, high trust, self-organising team of people who deliver outcomes. That’s when I know that our team has done it’s job.”

For this company, there was no holistic understanding of the solution – not only was the technology antiquated, but there were no architecture guidelines and keeping things up to date was not a part of their routine. This is where projects start to go sour; what businesses tend to do is look at costs and either save or throw money at the problem in the way of tools, resources or people. Morale becomes strained from being forced through team building, training etc. “In actual fact, reduced cost and improved morale are outputs of better collaboration, high trusting and a better organised team, not more training and team building.”

The first stage is to acknowledge that there is a problem, then to accept that what is needed is a paradigm shift. Teams need to be forced to see a different way of working, “quality naturally improves and then when coupled with efficiency will lower costs naturally, this triggers the boost that teams need.” A linear scale will see a paradigm shift with productivity, quality, costs and morale all improving.

In terms of productivity of the company was that teams delivered more features in shorter space of time, that they were significantly quicker to market with their cross-skilled technical BA and test team. The quality massively reduced bug counts through improved development and testing streams, post production warranty items were fewer and maintenance and support loads were reduced.

The shift from storming to performing

Subsequently, the costs were positively affected; reduced cost on the maintenance and support team and project delivery budget was reduced by more than 20%. The best result was that the team’s morale moved from “storming” to “performing”, there was a visible difference in team trust and relations and the business vs. IT division had naturally pivoted and become business and IT.

“You need to fail as part of the journey to finding the solution, so we benchmarked everything we did, because we wanted to see every inch of improvement and where it came from. Therefore, in doing, you’re teaching that every time we work together we collaborate in some shape or form. We needed the team to learn together and to teach each other. These are the principles of Agile.”

The progress has been benchmarked into three releases; release 1 being the beginning, saw 1.7 units of work per day. Release 2 shows when the team started implementing the mechanics of Agile and sat at 2.1. Finally in release 3, which is when the teams fully embraced the principles of Agile, showed 3.3 units of work per day. Defects in UAT in release 1 were at 45% and by release 3 were down to 23%. As people worked better, the quality naturally improved, because they were doing the right things at the right time; working on the most mature requirements and having access to business to validate requirements. Whereas previously business would provide IT requirements and say ‘your job – work it out’. This is totally contrary to Agile which builds trust for better outcomes at the end of the day for the business.

Mohamed says “We constantly filled the bath with work items. If the business was not quick enough to get requirements to us, we became proactive and worked on defects. Housekeeping became an inherent part of the job. This in turn affected the maintenance and support teams freeing up two thirds of the people to work on other projects and saving the company on maintenance and support budget. This was a direct result of improved quality which meant less need for post production support.”

Such improvements lead directly to a reduction in costs. “Look at budgets in relation to capacity and it’s peak performance,” cost per unit of work includes analysis, design, development and test. “Understand costs from multiple angles – monthly, annually, per team member, per sprint, per unit of work, per complexity item – its about having many lenses on the same issue. And we reduced the cost per unit of work from just under R40,000 to just under R25,000.” Relative cost opposed to absolute cost, costs per unit of work came down, making a direct saving in absolute cost which meant project budgets reduced by 38% in total.

Mohamed says, “Find a way to cost requirements; business understands numbers. They struggle to understand technical complexity and size of work. Having the right mix at a higher cost does not always result in higher budget overall. So we had to convince the business to make an investment in the team to build the capacity with the right skill set and numbers. This is how we managed to achieve a return on the investment in the team structure. For the first time, we were so ahead, that the business team could not get requirements to us fast enough. This was a total inverse of the year before when the team couldn’t ship fast enough. For the first time the business understood what it would cost them to come in and shop and what they could get for their money!”

Become dispensable

“The only way to make yourself indispensable is to make yourself dispensable” – John C. Maxwell

To get to this point, Mohamed swears by the 5 drivers of success:

  • Understanding the paradigm shift that is Agile
  • Agile starts out as a Discipline, that the process can be mechanised but ultimately must become inherent in all that you do
  • Empower and educate yourself, your team and therefore your business. That is, make yourself dispensable by sharing your knowledge
  • Fail Fast. Agile is an empirical process
  • Deliver business value at all times

“Traditionally in the industrial world, knowledge is power; if I know more than you I have power over you. Your knowledge can also become an anchor, and Agile teaches you to teach others, freeing up yourself and empowering your team. Share freely, you’re not giving your position away – you’re actually freeing yourself to take broader positions.”

In this particular case study, the team was exhausted. Mohamed and his team brought in Agile which catalysed people to think differently about work. It is a completely people-centric initiative. “Agile focuses on people. Methodologies focus on procedures, and tools. The optimal journey to success is via failure, it’s a process of elimination.”

INSIDE SARATOGA: An Interview Series on Leadership

Saratoga has an advisory capability to organisations, Mohamed and his team have worked with many different companies seeing enormous success based on Agile delivery. For information on Saratoga please email [email protected] or call +21 (0) 21 658 4100. If you are a student graduating and would like the opportunity to join and learn from some of the best minds in the business, please see our Graduate vacancies.