Request your demo of the Sigrid® | Software Assurance Platform:
The speed at which software is eating the world seems to be increasing. And it comes as no surprise when energy providers, telcos, and banks refer to themselves as software companies. However, breweries and publishers are just as serious when they refer to themselves in the same vein. This is far from hollow rhetoric as organizations are completely re-organizing themselves around the notion of agile software development. Among the most popular methods is the Scaled Agile Framework (SAFe).
As an IT strategy advisor, I have the opportunity to guide organizations during this transformation. A common struggle is how management needs to reassess its relationship with its development teams. Agile dictates that development teams need to be autonomous – typically a break from the past. Instead of development teams being told what to do, they are now free to decide how they work and even what they work on. How do organizations manage this self-management?
Let us take a step back. Irrespective of domain, empirical studies have long found that increased team autonomy positively affects productivity1. More recent studies suggest that developers benefit a lot from increased levels of autonomy2. We also know that happier developers, empowered to make their own decisions, produce better software3. This is good for everybody as well as management. The agile movement has adopted these findings with agile software development teams built around the idea of autonomy.
SAFe is pretty clear about development team autonomy, “SAFe teams — not their managers — determine for themselves what features and components they can implement in an iteration and how to implement them.“4 SAFe provides some suggestions regarding how, “Lean-Agile Leaders [can] provide the vision, leadership, and autonomy necessary to foster and promote high-performing teams. As a result, assigning work to individual team members is no longer required as teams are mostly self-reliant. This enables decentralized decision-making all the way to the level of the individual contributor. The primary responsibility of Lean-Agile Leaders then is to coach and mentor Agile teams.“5
Of course, being autonomous – deciding for yourself what to do – is also plainly more fun. Autonomous teams are more attractive to work for, and anything that attracts better developers is worth considering.
Empowered autonomous teams can quite starkly contrast with the traditional “just do as I tell you” culture that may have been in place before the transition to SAFe. I have had managers complain to me about the forty autonomous development teams they now had on their hands. Do you just let them do whatever they want? How about productivity? How do you match the costs with value creation? There has to be a way to centralize certain decisions without losing the benefits of autonomy.
They are not alone in asking these questions. The topic is discussed in the scientific community6, as well as in practice, Agile Alliance, an organization that supports the adoption of agile values and practices is still actively discussing how to align autonomous teams at scale. We are clearly all still figuring this out.
In practice, I see two extremes, from deciding almost nothing to deciding almost everything. Development team autonomy doubtlessly provides benefits and should be strived for. But these teams work on software, one of your most strategically important assets. Decisions that individual developers make regularly lead to huge risks and liabilities for the larger organization
These examples are all matters that autonomous teams may overlook or mismanage. Some teams will do great and some will not. The point is that management can absolutely not afford to leave these matters to chance.
At Software Improvement Group (SIG), we advise organizations to define and measure (at least) these three key factors: software quality (maintainability), software security, and software architecture. These policies must be defined SMART (Specific, Measurable, Achievable, Relevant, and Time-bound) and embedded within the development process.
Adherence should never be optional, and leadership should provide training that empowers developers to make the right decisions every time.
Tooling is key! Rather than using a tool that measures and reports thousands of violations, you need to provide a holistic solution that empowers developers to adhere to your key policies. They need to be supported and provided with accurate and actionable advice.
In addition, continuous measurement is required to mitigate the risks associated with these policies. Simple periodically auditing or working sample-based is highly likely to overlook policy violations that leave you vulnerable with potentially huge ramifications. Ideally, the measurement results that developers work on are aggregated empowering management to track policy adherence at the portfolio level.
To facilitate this, SIG developed Sigrid®, a software assurance platform that consists of continuous software measurement augmented with services that combine both technical and IT governance expertise. Sigrid® provides stakeholders at different levels in the development organization a continuously up-to-date overview of the state of quality, security, and system and landscape architecture. Most importantly, it effectively supports developers in adhering to clearly defined central policies, so that they can make maximum use of their autonomy in all other regards of their development work.
Development team autonomy is quickly gaining traction and while you should welcome the benefits this brings, you should also make sure that you don’t overdo it. Define which risks your organization wants to control, develop policies, actively steer upon these policies to ensure they are adhered to, and train developers where needed.
Interested to see how we help our clients can align autonomous teams at scale? contact me directly or fill in our contact form.
Footnotes
1 E.g. Trist, Susman and Brown. An Experiment in Autonomous Working in an American Underground Coal Mine. 1977. DOI: https://doi.org/10.1177/001872677703000301
2 E.g. Gustavsson, Berntzen and Stray. Changes to team autonomy in large-scale software development: a multiple case study of Scaled Agile Framework (SAFe) implementations. International Journal of Information Systems and Project Management: Vol. 10: No. 1, Article 3.
3 Graziotin, Fagerholm, Wang and Abrahamsson. What happens when software developers are (un)happy. Journal of Systems and Software Volume 140, June 2018, Pages 32-47. DOI: https://doi.org/10.1016/j.jss.2018.02.041
4 https://www.scaledagileframework.com/agile-teams/(retrieved, 6 April 2022)
5 https://www.scaledagileframework.com/lean-agile-leadership/ (Retrieved 6 April 2022)
6 See, e.g., Noe, Šmite, Paasivaara, and Lassenius. Finding the sweet spot for organizational control and team autonomy in large‑scale agile software development in Empirical Software Engineering (2021) 26: 101; https://doi.org/10.1007/s10664-021-09967-3
Author:
Senior Delivery Director, Benelux CE
We'll keep you posted on the latest news, events, and publications.
