Why do Scrum Masters work for specific companies?

A typical response to this question is - Scrum Masters would want to work for a truly Agile organisation. However, South Africa does not have fully Agile organisations yet. That is a harsh statement, but very close to the truth. None of the South African companies, especially the large corporates can honestly say that each sprint results in a shippable product or feature.

If every sprint in the organisation results in a feature pushed to production, then this is the exciting start of continuous delivery.

Often an organisation’s view of Agile is a team that does stand-ups and makes their work visible on a board. That is merely the start. Moreover, this does not make any team an Agile team.

Luckily this can be fixed in all cases. To become truly Agile, you have to persevere, reflect, adapt and evolve. An Agile transformation is a journey more than a destination. Having said that, we need a clear goal. The ultimate aim is to unleash continuous delivery. This is where sprints (with a shippable product at the end) go from bi-weekly cycles to daily and even hourly events. Naturally, to be able to do this, Development and Operations need to become one. Otherwise, your actual deployment might take longer than the sprint cycles themselves.

You have probably heard of the term DevOps. This points to the integration of the development and operations efforts that are required to become one smoothly integrated team.

Sound easy? It is not.

To integrate Dev and Ops means to be technically equipped before even starting to look at the different teams. Regular deployments need to be supported technically and with the bare minimum of governance. This can only be achieved if the system, including the architecture (software and enterprise), is designed correctly. Many organisations are not able to have a DevOps discussion due to legacy systems and software designed around large annual or bi-annual upgrades. Added to this, a considerable amount of governance and processes make such ‘big bang’ deployments risky.

Imagine an environment where every feature business wants could be developed quickly in iterations. Where the Product Owner spends time with the right team and the features (outcomes) are pushed to production within moments. The risk is minimal through a lighter governed process.

This speaks to accessibility – that of feature teams (as opposed to product or programme teams). Technical teams would ideally have accessibility to business representatives during the development phase. Teams then have accessibility to release more frequently without cumbersome processes. If organisations release more frequently, risk becomes less, roll back is easier, and no burdensome governance is required around this action.

Have you ever thought how demoralising it is for teams if the work they sprint through goes to the shelf at the end of the iteration and sits there until the next release which is months away? This is how you lose the sense of urgency and miss the opportunity for a quick feedback loop from your customers.

If it was possible to put a status on Agility or rather the Agile or Digital transformation, I imagine it like this:

1. Budget decentralisation & commercial agility - this speaks to an organisational structure where multiple business units are created within big corporates forming smaller teams. This behaviour supports Agility. Further to this is commercial Agility where budgets support delivery streams and not projects. This puts the emphasis on Business (Product Owners) taking ownership of the backlog since it directly impacts the budget. (Representing 10% of agility)
2. Team structure – cross functional teams with mixed professions serving demand from one or multiple business areas (Representing 20% of agility)
3. Servant leadership – this element is critical to support an Agile transformation and can be detrimental if not approached correctly. Managers become leaders supporting teams and individual professions accordingly (Representing 20% of agility)
4. ‘Pull’ culture – no command and control, but rather a supporting servant leading culture where teams pull work from a prioritised backlog (Programme backlog, Project backlog, Sprint backlog) created by Business (Product Owner) (Representing 20% of agility)
5. Regular deliveries – MVP’s that are shelved are not ideal as we want to get the value soonest. Agile is built around quick feedback loops after regularly delivering value. DevOps integrations and system agility is part of supporting regular intervals and deployments (Representing 20% of agility)
6. Agile Culture – the famous ‘Spotify engineering culture’ YouTube video is a testament to a truly Agile culture. The fundamentals of an Agile culture is trust, transparency, courage and respect. (Representing 10% of agility)

The above items are all 100% required, but since most people can associate with checklists – this is my mental Agile organisational checklist.

Back to Scrum Mastership

Every Scrum Master and Agile Coach needs to tap into a COE (Centre of Enablement) or a network where high-level topics and learnings are shared. Things like: How Agile are we as a division and also as an organisation? What can we focus on next to improve our Agility? How does SA perform in terms of Agile if compared to the rest of the world? What is the best approach to transforming a traditional deliver member/team/organisation?

If I were a Scrum Master, I would like to know that the organisation is serious about embracing Agile and that I am part of the COE leading these initiatives. As a Scrum Master Consultant at DVT, I would like to know that I can make a difference and that I am supported in my career with regards to exposure and continuous learnings.

This is the only way we will be able to fast track Agility within the South African workplace - by giving Agile focus and aiming for continuous delivery. At DVT, we have the privilege to consult with many organisations as Agile Coaches and Scrum Masters. Our COE meetings, in the form of a lean coffee session, assist our Scrum Masters and Agile Coaches to learn from one another. The added benefit is that we, as a group of Scrum Masters and Agile Coaches are exposed to many different corporates, and can learn from various organisations. What a privilege.

If you are interested in becoming a Scrum Master or joining our 'scrummies' team, feel free to send us your details, and we will be in touch.

mfrench@jhb.dvt.co.za