Show all posts
5 years ago

10 Most Common Mistakes in Agile Adoption. Part I

They did it again. Companies are making the same mistake during agile adoption over and over again. We’ve made some of these mistakes as well. If by any chance you see something familiar in the list below, read on and find out why it is a mistake.


1. Start With a Tool

It is not always bad to start with a tool. If you want to dig a pit, you most likely want to find a shovel first. You can dig manually, without a tool, but it will take enormous amount of time.

Agile development is something different. A tool will not provide immediate effect and will not solve most of the problems by the mere fact of its existence. Moreover, you will put effort into tool adoption, shading more important goal — agile adoption.

We encounter this mistake quite often. People come to TargetProcess web site, register for a trial, install the tool and try to use it. They start to ask questions and it’s getting clear that they have no experience in agile development neither agile process established. Sometimes they don’t know what a Burn Down Chart is and how to use it. Sometimes they know nothing about iterative development. It happens. The only piece of advice we can give is to get rid of the tool and dig deeper into agile domain: become familiar with basic concepts and try some process with simplest tools like whiteboard and sticky notes. Then decide whether you need a more sophisticated tool.

2. Start With a Process

Starting with a tool is obviously a bad idea. Most companies start with a process. It is a less serious, but a more common mistake. So you read about Scrum, it looks easy initially. You apply all Scrum practices and after some sprints see that development somewhat improved, but not as drastically as expected. Excitement goes away and process degrades.

What are the reasons? Why has it failed? Most likely people didn’t get the core values of agile development. Process is the mechanics, while values are the core of any agile adoption. The first thing any company should do before trying any process is to focus on agile values such as: communication, collaboration, feedback, trust and passion. It is nearly impossible to apply a good development process if you compromise any of these values. As an agile champion you should enforce these changes. Sometimes these are company-wide changes, sometimes team-wide changes, but still it is absolutely required to apply them.

The fastest way to adopt agile is to start with people and culture. I can’t stress this enough. And it is quite obvious! But why so many companies (including ours) have made this mistake? It is blazingly hard. You will have to change culture, and that will be met with a resistance. You will have to change people and most likely you’ll have to fire some of them. It is a hard and complex process, there are not so many people in the world who know exactly how to apply it. Most of us have no such experience and skills, so we fear this change. We try to start with something easier, something we know. We try to start with a process, with a tool, or with hiring an external consultant (which is good, but not enough). We should fearlessly start with the hardest but the right thing.

Agile manifesto is very deep indeed. If you read it carefully and set the principles as a cornerstone of agile adoption, you will success eventually.

3. Development Practices Are Enough

Extreme Programming is a very cool agile software development process. I think it includes Scrum. Many people may disagree, but in general if you do XP fully, you don’t need Scrum. Interestingly, that developers tend to apply technical practices like TDD, Continuous Integration and even Pair programming, but pay less attention to such things as communication, integral team, having customer on-site and retrospectives.

Why is it like that? Developers are techies, and techies like technical stuff, while often disrespect social stuff. Many of them are introverts, they don’t like meetings, they don’t like to chat with people extensively. They do like to communicate about technical things and do that with passion. However, communication with customer is not about Clojure or fancy lambda expressions, it is about business. It’s business problem domain, and it’s not that interesting for them.

Again, agile is more about people and less about technology. Many practices are focused on people. Pair programming makes for more communications between developers. Customer on-site makes for more communications with end user. Retrospectives boost communication about team, processes, etc. It is absolutely required to apply practices that focus on communication, adoption and fast feedback. It is absolutely required to pay more attention to people, improve their skills, improve technical excellence and shift mindset.

4. Scrum is Enough

Is it possible to adopt agile without technical practices at all? No, it is not. However, it is a less severe mistake than the previous one. If you apply Scrum right, you will inevitably decide to try some technical practices at a retrospective meeting.

The true mistake will be to rely on Scrum solely as a process that will solve all the problems. It can do that, but only if you are open-minded and willing to try various things: from pair programming to BDD. Best coaches believe that Scrum should be adopted in tight pack with XP technical practices. This is a good advice to follow.

5. CSM Knows Everything

Certified Scrum Master is not a demigod. Yes, he has some basic knowledge about Scrum, but in many cases that’s just it. He may have no hands-on experience neither strong theoretical background. He should not act as a PM and prescribe what to do and what not to do. Team should decide. The only real things SM should care about are teams impediments and meta-process. By meta-process I mean a set of rules/procedures that allow team to reflect and improve existing development process.

Common manifestation of this mistake is phrases like “I insist we should change iteration duration from 1 month to 2 weeks” or “I strongly believe we should keep doing code reviews”. It might be that he is right, but it does not matter, the language speaks for itself. There should be no “I” in SM phrases, there should be “We”. Otherwise agile adoption will fail. If SM doesn’t believe in team, the team as such will not gel and will degrade eventually.

Read Part II for last 5 mistakes.

  • Martin Proulx

    I agree with you Michael that Agile adoption means a significant culture change. I prefer using an incremental approach for a lasting and successful adoption ( As such, “Start with a process” may not be the best approach but it is a good step in the right direction.

    Needless to say, the organization can't stop at that step and should move on to the leadership styles and culture changes but starting with trying to change the culture will prove to be very (very) looooooooong and funding for such an initiative will dry off way before anybody sees positive results.

    Starting with the process at least has the benefit of showing some improvement early on. As they say in change management, show short term wins in order to help with overall adoption.

  • Michael Dubakov

    Sometimes it is true. Small wins can be good motivators. And cultural changes should follow quickly after that. Otherwise agile adoption has high chances to degrade and fail.

  • Katrin

    It's very important to have a clear goals why you are adopting agile. The main mistake is start a process because of process, use a practice because of practice. Agile should help to solve some problems and achieve some results. If a company or team doesn't understand why they need agile there is no chance for success. Motivation is a key. People should know benefits. The worst thing if a motivation isn't proper because of bad understanding what agile is.

    I believe that it makes sense to start by small steps. It's enough to start from retrospective; then team will decide how to move forward. Different teams/projects might have different set of practices. It's also something to consider. To my mind the main mistake it's start from everything at once: tool+ development practice + process + etc without motivated team, vision and goals.

  • George Dinwiddie

    Very nice, and I look forward to the next installment. I'm afraid I would have a hard time limiting the list to 10 mistakes. I took a different tack to this question in but I like yours, also.

  • Pierre-E. Dautreppe

    I would even say, if there should not be “I” in SM phrases, there should not be “You” neither.

    It's a common error I have seen, separating himself as “knowing things” from the team members that are “doing mistakes”. This is also linked to your point 3: forgetting communication, …

  • Baere

    Together with a group of people we've been working (training, workshops…) around soft-skills and attitudes for years in our company with average success. When I heard about scrum and especially when I started to use scrum I was astonished. Thanks to the process all the soft skills & attitudes we where talking about came to live! The design of the scrum process makes that people develop those values and this a lot faster then just working on those values. For me Scrum is a practical framework that I use to create those values. Key of course that at least one person should have those values and use scrum as a tool for developing them.

  • Michael Dubakov

    I think it is general advice for every type of knowledge and improvements. If you want to learn/improve something, you should do it in a structured way. Random learning is not very efficient, you need some defined circles and feedback. Scrum gives exactly that.

  • Lindsey Niedzielski

    Great post Michael. This is a great resource. We have a community for IM professionals ( and have bookmarked this post for our users. Look forward to reading your work in the future.

  • Baere

    Not sure if I made my point clear. The trainingprogram was very well structred and feedback driven (give and recieve feedback was concidered a core attitude), only we missed a – good – pracktical framework. So my point is that you need both: values and a practical framework. Only working on values takes ages and only working with a practical framework based on values goes very quickly but has no garanty at all that people will pick up the values. In other words pass the values through a framework.

  • Michael Dubakov

    I definitely agree

  • mājas lapu izstrāde

    Yes yes yes… you are very right about Tools and Processes. Agile is philosophy and coders have to start to understand this.

  • Wille

    Big kudos for no1 – most businesses will bend over backwards for revenue, even if they are the wrong solution, or wrong solution for the time being for their customers.

    Having the balls to turn away customers and saying you might not be right for them right now is great, ethical business practice that will enhance your reputation and trust with people.
    Short term loss? Possibly. Long term gain? Most definitely.

    Great to see an example of a business that isn't all about instant gratification at the expense of business ethics.

  • Michael Dubakov

    Thanks, Wille, to me it's a quite obvious choice. There are no good reasons to sell product and receive negative feedback later.

  • Rap Na Veia

    Anyways, agile is the most beautiful thing has ever happened do a programmer, it is worthy.

  • Pkg

    > communication, collaboration, feedback, trust and passion

    o, really…

    I thought that applies pretty much to all technical projects (especialy software, but also even space ship construction or whatever)

    Guys, it is time to face it – no methodology or process will save our industry, because the problem is called “skills”.

    I can assure you that well skilled developers, managers and so on can easly succesfuly finish software even using waterfall.

    After several years being a SD, I already see that most of people is just painfully unskilled to do their jobs…

    But of course, education is expensive…

  • Venkat

    Very detailed and apt description of the common mistakes Olga..thanks

  • Giscard

    There's truth to this. I see organizations looking for developers who must have past agile experience. This possibly leads to a common mistake that occurs on software development projects; hiring the wrong people. Show me a developer who has been highly successful on a number of projects and I will show you an agile developer.

  • walter

    nice observation  on technologies

  • Rob

    Olga – very good stuff – I'm working on a large Agile Transformation and this is all the stuff I discuss every day.

  • Janakiram

    Very useful article indeed ! IMO, even if one of the mistakes is committed by the Scrum team, very easily the team can slip into the ‘Agile-But’ mode. Coming out of ‘Agile-But’ needs extra effort and a stronger mindset.

  • William fumey

    I`m interested This

    I totally get where you are coming from.

    For me, the goal of the startup is to create something of value as quickly as possible and

    with minimal cost / waste. In pursuit of this, visualization gives a startup team clarity and

    immediate direction. Options are made apparent and acted upon with maximum buy-in.

    In a startup, the kanban can be the focal point to allow rapid ideation, prototyping and

    release. It can also be used to experiment, kill bad ideas, and evolve rapidly. 

Request a demo
Our product specialists will show you the beauty and power of Targetprocess 3 and help you to customize it for your process and business requirements
Request a demo