Autonomous Teams: Do We Really Want Them?

Autonomous teams are often seen as the holy grail of software development, promising not only increased productivity but also greater employee satisfaction. However, in reality, we encounter many obstacles and we must ask ourselves if all teams truly want autonomy. After all, autonomy requires not only trust and the delegation of responsibilities but also teams willing to take on that responsibility. This talk takes a critical look at autonomous teams in software development.

Transcript

1. Autonomous Teams: Do We Really Want Them? Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. What Is Autonomy? •Team works mostly independently. •Team decides by itself.
3. Why Would We Want Autonomous Teams? •Autonomy is no goal but a means. •Does autonomy lead to “better” results?
4. Less Communication •More autonomy = less coordination and communication. •Therefore, more time to deliver value. •So probably better results
5. Self-determination •Make decisions where most information is available •Teams set goals themselves •Be creative in solving problems •Better job satisfaction •Probably better results
6. Discussion … often focus on tools & technologies. • Should the organization adopt microservices? • Serverless? • Kubernetes? Our research shows these are the wrong questions to focus on.
7. What is important is enabling teams to make changes to their products or services without depending on other teams or systems.
8. His [Sergey Brin’s] job … was to get out of the way if he felt his idea wasn’t the best. You need to have confidence in your people, and enough self-confidence to let them identify a better way.
9. Architecture Limits Autonomy Big Ball of Mud Partnership
10. Autonomy: A Goal for Architecture •Big Ball of Mud: Everything depends on everything •Each change might influence any part of code. •Forces teams in partnership i.e. close collaboration. •A well-structured system: impact of changes limited •I.e. sound architecture is a prerequisite for autonomy.
11. Microservices •Sound architecture: change impacts only parts of system •Microservices: part can be deployed independently …and can use a different technology. •i.e. more potential for autonomy •Enabling autonomy this way is an important part of my consulting.
12. Autonomy Less Communication More Productivity Self- determination Architecture Example: Google Example: Accelerate
13. Why Are We Still Struggling with Autonomy? •Advantages are obvious. •It makes no sense to explain them further. •We are looking for explanations why we are still not there yet. •Explanation is the first step to actually reach autonomy.
14. Like Air Crash Investigations •Investigation looks for reasons •Usually more than one •Often humans •Goal: Make sure it never happens again •E.g. change training
15. Management I The team is successful! How do they actually work? What if success ends? Can they be even more successful?
16. Management I Team feels like a black box. Not sure what they are really doing What is my role?
17. Management I Can you look at how we work here? Is the teams successful? I fail to see any major problems. Did you look at it in detail? Why would I?
18. Management •Autonomy means less control. •I.e. management will not know nor understand what teams do. •Can lead to insecurity •You need to be able to live with insecurity.
19. Management II …but what you suggest will never work with the people here. I am an external consultant. How can you trust your people enough? Autonomy and stuff is great.
20. Management •Management must trust teams to do the “right” thing. …and to speak up if something doesn’t work.
21. The Illusion of Control •The desire to control things explain lots of behavior. •Excessive planning and deadline “waterfall” •Excessive architecture rules •But things do change. •This becomes obvious in your first IT project. •But people still use these technique •i.e. they get an illusion of control
22. Leap of Faith Sabrina‘s stash @ Flickr
23. Leap of Faith •Wikipedia: “act of believing something that is unprovable” •“risky thing a person does in hopes of a positive outcome” •Consider trusting people •Yes, it appears to be risky.
24. Leap of Faith •If you truly trust people, people will step up. •If there is no QA, developers will likely invest more effort into testing. •I.e. less control might mean people take over more responsibility.
25. Audience? •Management •Architects •Developers •Other •Vote
26. Should Code Analysis be Mandatory for Teams? •E.g. test code coverage, complexity metrics, bad code patterns … •Yes, predefined goals •Yes, team sets goals themselves •No •Vote
27. Results from Technical Training 7% 59% 34% No Yes, team decides Yes, predefined goals 110 responses, random attendees from a technical trainings
28. Goodhart’s Law When a measure becomes a target, it ceases to be a good measure
29. Goodhart’s Law: Test Coverage •Test coverage: good measure for the quality of test. •Higher: more parts of the code are executed, so the test can catch more errors.
30. Goodhart’s Law: Test Coverage •Set a test coverage goal •Metric will be manipulated. •E.g. focus on trivial parts of the code •E.g. don’t check any results •E.g. just make sure no exception is thrown •….
31. Goodhart’s Law: Test Coverage •Test coverage increases. •But the tests won’t really catch more problems. •Test coverage is not a good metric for the quality of the tests any more!
32. Should Code Analysis be Mandatory for Teams? •Yes, predefined goals Goodhart’s Law will hit you •Yes, team sets goals themselves You are still enforcing standards •No True autonomy
33. My View •Code analysis is a great! •But: No, code analysis should not be mandatory. •Teams should decide for themselves! •I trust the teams to do the right thing. •I don’t want to waste time checking on their metrics. •Note: I might make it easy to do code analysis i.e. provide an infrastructure and guidance.
34. But what if they don’t deliver quality? I will hold them responsible. But they might use techniques they please. Mob / ensemble / pair programming Code reviews…
35. Results •Technical people, too, seem to prefer control over autonomy. •Lack of trust? •Confusing “good idea” with “must be enforced”?
36. Technology Stack: Another Example •Should we standardize the technology stack? •Pro: Team can best decide what the right tool is. •Con: Will end in anarchy •My take: “convergence hypotheses” •A team has many benefits from using the same technology
37. Technology Stack: Convergence Hypotheses •Teams have benefits from using the same technology. •Knowledge & infrastructure available •They will have a bias to use the same technology …unless there is a significant drawback …and then a different technology is fine …unless they irresponsible or irrational …and then there is a different problem
38. Technology Stack: Problems •Sometimes teams use specific technologies to improve their CV. •Sometime projects become a unmaintainable mess. •I.e. there has to be some guidance
39. Autonomy and View on Humanity •If you easily trust people, you will let them work autonomously. •If you don’t, you will control them. •This might or might not be based on your good / bad experience.
40. https://software-architektur.tv/2021/12/03/folge94.html
41. Some Standards Are Needed •Autonomy means less communication. •Communication = architecture (Conway) •Communication breakdown leads to architecture mess. …as Conway pointed out. •Architecture must provide conceptual integrity. •So: provide guardrails and enable communication •I.e. limit autonomy
42. Autonomy vs. 9-5 •Some people want to be told what to do. •Autonomy means being responsible. •Life is easier if you are not responsible. •They might still do a good job! •But then again, they probably make decisions in other contexts. •So: Provide them with more autonomy …and see that happens.
43. Autonomy Trust Desire to Control Enforce vs. convince Example: Tech Stack Example: Code Analysis Accepting limited understanding Some standards are needed Some want no autonomy
44. Conclusion
45. Conclusion •Autonomy seems to make sense •Many architecture modernizations try to enable more autonomy. •Main problem: psychological •Trust, living with uncertainty… •Leap of faith •Some standard is needed (tech stack, architecture) …but must it be enforced?
46. WIR SUCHEN MITGESTALTER:INNEN swaglab.rocks/karriere
47. Trink einen virtuellen Kaffee mit mir! https://calendly.com/ eberhard-wolff-swaglab/
48. Send email to ittage2024@ewolff.com Slides + Sample Microservices Book DE / EN + Sample Practical Microservices DE/EN + Sample of Continuous Delivery Book DE Powered by Amazon Lambda & Microservices EMail address logged for 14 days, wrong addressed emails handled manually