Since agile software development has really hit the mainstream during the last few years, it is only natural that there are a lot of misconceptions around. Also, I have noticed that some misconceptions are more common than other ones. This blog entry is written to introduce you the three most common misconceptions about agile software development, which I have encountered during my short journey in the world of agile methods. These misconceptions are:
Self-organizing agile team do not need to be managed
Even though it is true that agile methods do not include similar management than more traditional project models, it does not mean that no management at all is needed. Claiming so indicates that the person in question has misunderstood the role of a self-organizing team. In principle, self-organization is a quite simple concept. It means that after the team has committed to complete a set of tasks during a specified time frame, it can organize itself freely as long as it fulfills the goals, which were chosen by its members.
However, the team does not decide what kind of features are needed. This is where the management steps in. Its role is to provide a prioritized list of features to the team, which can commit to complete either all or some of them during a specified time frame. The management acts as a shepherd, who decides which direction its herd will move. The herd will decide how fast it can move to the desired direction. This separation of roles is required because it ensures that the team is doing the right things (or at least the things, which seem to be right at the moment).
Of course, if your team is full of domain experts who are using their psychic abilities to identify the right direction at all times, the separation of roles is not be needed. Unfortunately, you are never this lucky. In a normal situation discarding the role of the management can lead in to a disaster if the team cannot see the forest from the trees.
Agile software development means that no documentation is written
This is one the most common misconceptions about agile software development. However, the agile manifesto does not state that no documentation is written. It states that working software is valued over comprehensive documentation. The obvious question is: what is the difference? In traditional software projects a lot of effort is used to produce documents like requirement specifications, technical specifications and test plans. In fact, these documents are often required before the project can proceed to the next phase. Yet, the sad fact is that most of these documents are not updated or read after the project has been finished. The effort used to produce them has been futile.
Agile methods take an another approach to this problem. Agile projects aim to maximize the value delivered to the customer by producing only the minimum amount of documentation. This approach requires that the team can identify the documents, which are truly useful and valuable to the customer. Delivered documentation might include a short architecture specification, installation instructions and a documented source code. By producing only a portion of the documentation written during a traditional software project, an agile project team can use more time for implementing the required features.
One of the key principles of agile software development is to maximize the value delivered to the customer. If a document truly fulfills this goal, it should be written. Saying otherwise has got nothing do with agile methods, but it has got everything to do with misunderstanding your ultimate goal, which is to maximize the value delivered to the customer.
Doing agile by the book is the only way
If you have just started using agile methods, it is often safer to do it by the book. Just read a couple of books about agile methods or hire an agile coach to help you through the transition phase. This should help you to get started, but do not make the mistake of believing that you are now being agile; because you are not.
You should soon realize that there are aspects of this approach, which does not seem like a good fit for your organization. When this happens you should not be afraid to replace the malfunctioning parts with new ones, which suits better to your needs. Remember that continuous improvement is one of the corner stones of agile methods. As long as your goal is to improve the status quo, you cannot go badly wrong. Remember that if the things, which you are trying out, do not work, you can always try something else.
Doing agile methods by the book even though it is obvious that it does not work for you is not being agile. It only proves that you are still valuing processes and plans over individuals and change. Using agile methods is not easy. It is hard because there is not one right way to do it. In the end, agile methods are just a set of tools. You must decide how to use them.
I have now described you the three most common misconceptions about agile software development, which I have encountered during my career. However, these are not the only misconceptions around. It would be great to hear your insight about them.
"Its role is to provide a prioritized list of tasks to the team"...
Surely management can't provide tasks to the team, they on have the necessary knowledge to know what tasks are needed? In my Scrum teams no tasks are derived from management, the team creates tasks, organises who does what and regularly meets it's commitments to the business.
I agree that management is needed however, but above the team to deal with upward reporting of estimates, resource management etc...
Arran, thanks for your comment.
Perhaps the term 'task' is a bit misleading here because I agree that the management should only provide a some kind of high level list of wanted features and prioritize that list. I was trying to avoid the usage of Scrum specific terms such as product backlog, but I see now that it might have been a better to use those terms instead. I updated that part of my blog entry to avoid further misunderstandings.
Again, thanks for pointing this out. I really appreciate it.
Ahh yes, makes more sense to me now. Great blog.
The most fundamental misconception about Agile is that most people see it as a specific way of working. This is bad. We should not do so.
Agile should be defined by what it is to achieve, i.e. by a goal.
This is important, because the best way to reach this goal may depend on your project (type of customer, type of contract, etc.).