In my daily work as an Agile Coach in Automotive, I always encounter a (more or less) fix set of myths and misconceptions about Agile. Although these myths do not occur exclusively in the automotive sector, it seems that they are far less common in other industries. Perhaps it is because Automotive – on a large scale – has adopted Agile methods relatively late. As I believe that Agile transformation based on misconceptions has a deleterious effect on the implementing organization, it is a personal concern of mine to dispel such myths.
In the following, I compiled a list of the eight most common and persistent misconceptions of Agile in Automotive:
#1: Agile means being faster
Being faster or to reduce time to market is one of the most prominent reasons why organization want to implement Agile development methods like Scrum. However, Agile does not mean that you will deliver faster rather it means you will deliver more often. Speed in terms of Agile means developing the right thing through prioritization, gathering valuable feedback continuously, and skipping requirements not worth implementing.
#2: Agile is a ruleset
In order to successfully implement Agile in your organization it is not enough just to apply Agile practices like Daily Stand-ups and to use Agile artifacts like task boards. It is much more important to establish an Agile mindset, i.e. to internalize the Twelve Agile Principles stated in the Agile Manifesto. At the end of the day, it is about taking everything as a lesson learned, adjusting actions according to gathered feedback, and proceeding toward desired outcome, resulting in continuous improvement.
#3: Agile is Scrum
Often, people confuse Scrum with Agile – or even worse, they refer to single Agile practices, such as Daily Stand-ups as being agile. Agile is an umbrella term for a great many of Agile approaches: Scrum, Kanban, eXtreme Programming – just to name a few. If you are only familiar with Scrum, consider learning about Kanban and eXtreme Programming too. You might discover there is a wealth of possibility for improving your team’s process.
#4: Agile means no documentation
A classic. The thinking that being Agile means documentation is not needed is a common misconception of those inexperienced with Agile. It is most likely a misinterpretation of the Agile Manifesto that states: “We value working software over comprehensive documentation”. It does not say to omit documentation. In Agile and especially Scrum, documentation is being treated like any other deliverable. If needed, it even gets estimated and prioritized like any other user story.
#5: Agile means just “hacking” code together
Often, Agile is put on a level with being technically undisciplined, but the truth it is vice versa. Agile is a very disciplined way of continuously delivering software (or any other product increment). The ninth Agile Principle of the Agile Manifesto states: Continuous attention to technical excellence and good design enhances agility. Being truly Agile means you have to test, you have to gather feedback, you have to regularly ship product increments, and you have to continuously adapt your plan.
#6: Agile is only for software development
Although the focus of the Agile Manifesto is on software development, Agile can be applied in a variety of dynamic business contexts that experience great volatility and variability. If you look at the roots of Agile software development, you will inevitably find references in lean manufacturing and organizational learning. These ideas originated outside software development in the beginning. Agile may also be applied to non-software projects, such as mechanical and hardware projects. Even human resources or purchasing can adopt Agile practices.
#7: Agile is the silver bullet
At the moment, in Automotive, Agile development is in the spotlight. However, the solution must match the problem and there is no reason to get dogmatic about a certain approach. There are contexts in which Agile is not the best choice, e.g. where customer requirements are clear and stable, where time to market is not critical, where environment is changing slowly. Here, traditional development approaches, e.g. Waterfall are valid. However, if that is not the context in which we operate, we must choose an appropriate development approach. If requirements change constantly, if the market is volatile, if the competitive pressure is high, if the complexity steadily increases, Agile is probably the right approach.
#8: Agile is easy to implement
It is true that Agile approaches are easy to understand but it is equally true that they are hard to implement. Often, team and management underestimate the effort for implementation. People do not oppose change they rather oppose to be changed and the organization normally find it easier to make things more complex than to simplify them. In most cases, agile implementations “by the book” do not work and tailoring is crucial. An experienced Agile Coach is money well spent.
Even though Agile methods and practices already have several years under their belt, Agile myths and misconceptions remain unabated. Now, at first glance, it might seem that such misunderstandings are not all that bad but unfortunately they are. Usually, those mistaken perceptions lead to condemnation of Agile methods and practices. Started change programs may be canceled in the middle, people affected are unhappy and sought improvements are reversed. From my point of view, the only solution for this problem is the constant clearing of those misconceptions – even if it feels like a Sisyphean task.
And now it is your turn! Tell us, which misconceptions regarding Agile you already have encountered in automotive context?
Author: Sergej Weber, Process Consultant and Agile Coach at KUGLER MAAG CIE