This is a piece I wrote for the engineering newsletter while working as a developer at Autodesk. The intent was to understand why our team was struggling to adopt Agile principles and practices. It was published in February 2016.
Why write this piece?
If you were asked “Can a company cultivate an agile culture,” what would you say? Your response might fall somewhere between the processes the company actually follows, and what the company tells itself about those processes. And if we look at companies like Google, where no one says they follow Agile, is it possible they can be Agile, without necessarily following Agile? In the words of Jeff Sutherland, the father of Scrum, "they [Google] are Agile as far as I am concerned no matter what they are doing."
If you were asked “Can a company cultivate an agile culture,” what would you say? Your response might fall somewhere between the processes the company actually follows, and what the company tells itself about those processes. And if we look at companies like Google, where no one says they follow Agile, is it possible they can be Agile, without necessarily following Agile? In the words of Jeff Sutherland, the father of Scrum, "they [Google] are Agile as far as I am concerned no matter what they are doing."
I spent a week having one-on-one discussions with colleagues from different teams within M&E about Autodesk’s Agile culture and adoption. I interviewed 16 people from 7 different teams. I ended up gathering way more information than I can summarize here. What I heard from everyone was that Autodesk wants to be collaborative and wants to improve processes; we just may not have the practices or culture to do it seamlessly quite yet.
The Practices
What came up over and over again is the perception that we are often too focused on process (such as Scrum), at the expense of engineering quality. Robert Martin, one of the signatories of the Agile Manifesto, explains in a powerful talk how companies adopting Scrum often fail to get the full benefit of Agile because they don't adopt the technical aspects of it. Martin Fowler coined the term Flaccid Scrum to explain this.
What came up over and over again is the perception that we are often too focused on process (such as Scrum), at the expense of engineering quality. Robert Martin, one of the signatories of the Agile Manifesto, explains in a powerful talk how companies adopting Scrum often fail to get the full benefit of Agile because they don't adopt the technical aspects of it. Martin Fowler coined the term Flaccid Scrum to explain this.
Our estimation techniques (read: grooming and planning meetings) may not be getting adopted by our teams. This lack of adoption alludes to what could be understood as too much of a focus on process, simply to satisfy a system, rather than as a useful exercise in planning. This has led to general dissatisfaction with many of our current Agile practices.
Several colleagues expressed that during retrospectives, we simply aren’t producing to capacity, and often fill in time simply to go through the exercise. It was also shared that we often have too much discussion around small tasks, and too little discussion about the important stories, lending again to a focus more on process than on agility.
Where we seem to be doing well is with our code review processes. We also seem to have achieved a level of consistency in certain technical aspects, which is also a step in the right direction.
The Culture
One of the points raised from discussions with colleagues was the lack of understanding around Agile methodology. While we say we are an Agile organization, we still iterate in a waterfall fashion, often in silos, with a heavy dependence on QA after the fact. What we need to do is encourage and educate everyone about the salient cultural and technical aspects of Agile.
One of the points raised from discussions with colleagues was the lack of understanding around Agile methodology. While we say we are an Agile organization, we still iterate in a waterfall fashion, often in silos, with a heavy dependence on QA after the fact. What we need to do is encourage and educate everyone about the salient cultural and technical aspects of Agile.
In 2010, VersionOne conducted a survey which found that the primary barrier to furthering the adoption of Agile was the inability to change organizational culture. Allen Holub, an educator and popular Agile consultant, talks about the reasons why Agile usually fails in The Death of Agile. You might be noticing how the emphasis here is on the adoption of culture and principles, beyond simply following Agile processes.
What is great is that I’ve seen a few teams at Autodesk with cohesion on ideas about engineering practices. But in other teams, personal responsibility and enthusiasm to learn and implement proper techniques is lacking. For a lot of those teams, sprint commitments seem to drive the process, and in response, developers cut corners in order to ship features at the expense of quality. This has been asserted by several colleagues.
But how do you change culture? What we may need to look at are fundamental concepts regarding our current culture. For one thing, our rewards programs compel people to think at an individual level rather than at a team level. Implementing Agile with these types of conventional metrics may not get us the desired outcome. Mary Poppendieck illustrates in her article the issues that arise with a traditional reward mindset in an agile culture. It’s hard for developers to advertise accomplishments in improving quality and engineering design principles because it’s not a concept easily presentable in a visual manner. One of the things we do today that reify this is our hackathons; they are designed to focus only on end-products and not on techniques and engineering practices. These were also concerns raised by several colleagues.
What can we do today?
Some of the simple ideas put forward by my colleagues included 1) an objective 3rd party observer to streamline our scrum process, 2) a committee to standardize code quality, 3) more engineering training, 4) engineering hackathons, and 5) more direct involvement by leadership in motivating teams to improve code quality.
Some of the simple ideas put forward by my colleagues included 1) an objective 3rd party observer to streamline our scrum process, 2) a committee to standardize code quality, 3) more engineering training, 4) engineering hackathons, and 5) more direct involvement by leadership in motivating teams to improve code quality.
Karine Roy and I are collaborating with experienced colleagues on how to setup a culture of code quality and to encourage teams to adopt it.
Looking at what is happening at other companies, SAP has an Agile Software Engineering course that teaches their developers agile programming techniques. And Spotify was built around an engineering culture that has maintained their success, even with substantial growth among their engineering ranks.
Amar in his recent quarterly all-Hands articulated that Autodesk should be in the ranks of Google and Amazon in terms of quality products. It’s a great vision. But in order for that to become a reality, our engineering practices and culture need to be aligned with that goal. We need a clear approach to improving code quality and developer integration, and it is the organizational support to build such a culture that will be indispensable.
Additional resources:
No comments:
Post a Comment