With the Agile iterative software development methodology widely accepted as the best way to get to market faster, most large South African companies embrace the concept. Many even believe they have ‘gone Agile’ when in reality they have not.
By Rouan van der Walt, team lead and client account manager at Retro Rabbit
In over 20 years of using and consulting around Agile approaches, we have seen it attempted, and fail, time and again. There are a number of key reasons why this occurs: a misunderstanding of what it should look like in practice, over-reliance on Scrum Masters, a ‘waterfall’ corporate mindset and culture, and occasionally also red tape and egos.
However, make no mistake: Scrum Masters are important because they help development teams to understand what it truly means to be agile.
‘Over reliance’ comes into play when they are not left to do what they should be doing but instead end up performing tasks they should not be doing, turning them into a team member. Rather, they should be seen as consultants to the team, not members of it.
Scrum Masters as Pas
This brings us back to over-reliance on Scrum Masters, as noted above – they have an important role to play but they are intended to be facilitators who guide a team through the Scrum methodology. Their job should be done once the team is Agile, and they should move on to another project or team. In practice, however, many corporations stick a Scrum Master in a team and declare it to have achieved the goal of being Agile.
Because the Scrum Master initially has everyone’s contact details and schedules meetings, the team members come to expect them to continue managing admin tasks indefinitely – much like a personal assistant.
As a result, the team members don’t take on responsibility for their own collaboration and communication.
Agile in practice
Many companies are under the misconception that ‘Going Agile’ means sending all their employees on a three-day course to learn Scrum and then implementing it in their teams. But what is not understood is that it is much more than a methodology – it’s a mindset and way of working. And if the organisation does not get buy-in from employees and stakeholders, it always fails.
For many companies, it is a buzzword, and they don’t really know how to apply it. They may want to be Agile to get products out as quickly as possible, but at the same time, they hamper their own efforts by insisting on processes, forms, meetings, and authorisations that slow things down.
Many believe that simply following a framework approach will make it happen for them. The bottom line is that it’s not enough. Now we get into the real jargon – standups and retrospectives.
Many businesses have standups – short, daily meetings to discuss progress and identify blockers. Or they have retrospective meetings – meant to evaluate how the last iteration, sprint, or work item went, specifically around the development teams dynamic processes, and tools.
These meetings are meant to enable teams to take ownership. Standup’s should provide a clear view of what everyone is working on and where help is needed. But when you have, for example, 50 people in a standup, the value of the individual is often lost with only 3 or 4 at most really engaging and capable of delivering value.
The same can be said about retrospectives which strive to highlight areas in need of improvement. But too often team members work to check lists for sign-off – this approach will not lead to successful outcomes. In a nutshell, it doesn’t work.
If you have 50 people from the project team in a single daily meeting, nobody can add real value. People simply zone out or continue working and wait for their name to be called. For genuine impact in line with Agile approaches, these Standups should be broken down into groups of no more than eight to ten people – perhaps a feature stream or task team. The team leads could then have their own Standups at intervals.
Traditional and waterfall organisational culture
In large, traditional, and hierarchical organisations, it can be a challenge to successfully implement Agile. Where everyone has a clearly defined role and responsibility, people don’t want to overstep boundaries. This mentality doesn’t align with Agile, where everyone gets involved across the task or project.
In highly structured enterprises, there may also be more red tape to get through, slowing down processes. Red tape in large organisations tends to seep into the mentality of the people – they almost look for stumbling blocks.
Where there are very structured roles and departmental responsibilities, employees can pass the buck and assume less responsibility than they would in an Agile environment – this is the antithesis of agile which is about taking ownership.
Another challenge is where organisations have a layer of management stakeholders who are reluctant to flatten hierarchies and relinquish control. Where people are overly concerned about their title or whose opinion matters most, they undermine the objectives of the Agile approach, in which every team member at every level should feel safe to offer input and suggestions.
Some personalities may have a need to be indispensable and want to maintain sole ownership of a role or specialisation. This creates a single point of failure and a risk for the organisation, and flies in the face of Agile approaches, in which knowledge is shared across the team.
Buy-in
Ownership is the key to Agile mindset. While Retro Rabbit has always had this mindset, we don’t necessarily push it into all environments: in some corporate structures and cultures, waterfall or hybrid approaches may prove more appropriate.
But where an organisation needs to move quickly and leadership has embraced it, it is important to strive for change and guide Agile methodologies throughout the organisation to ensure it delivers real value.