
Everyone has been a part of a project, willing for it to be over, disliking the results 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.
The entire team needs to be behind the revolution of agile 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 its success. In the end, Bray's team was 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 Bray'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, Bray 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, Bray 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 bastardised 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 8 000 users of a mission-critical financial application and selling 90% of the multinational'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 versus IT. The latter was one of the first things that Bray'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:
"1. Sprint planning;
2. Backlog grooming;
3. Prioritisation;
4. Analyse, develop and test;
5. Demonstrations; and
6. 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. Bray says: "The end goal of agile is high collaborative, high trust, a self-organising team of people who deliver outcomes. That's when I know that our team has done its 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 its 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, teams delivered more features in a shorter space of time; 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.
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 versus 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 one being the beginning, saw 1.7 units of work per day. Release two shows when the team started implementing the mechanics of agile and sat at 2.1. Finally in release three, which is when the teams fully embraced the principles of agile, showed 3.3 units of work per day. Defects in UAT in release one were at 45%, and by release three, 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.
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.
Bray 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 led directly to a reduction in costs. "Look at budgets in relation to capacity and its 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 - it's 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 as 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.
Bray 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, Bray swears by the five drivers of success:
1. Understanding the paradigm shift that is agile;
2. Agile starts out as a discipline, that the process can be mechanised, but ultimately must become inherent in all that you do;
3. Empower and educate yourself, your team and therefore your business. That is, make yourself dispensable by sharing your knowledge;
4. Fail fast. Agile is an empirical process; and
5. 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. Bray 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."
Saratoga has an advisory capability to organisations. Bray and his team have worked with many different companies, seeing enormous success based on agile delivery. For information on Saratoga, please e-mail: mohamedb@saratoga.co.za 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 Saratoga's graduate vacancies.
Share