Available for both SaaS and On-Premise.

Targetprocess can integrate with your existing development tools to create a central hub for collaboration and management across your enterprise. Get rid of information islands and standardize your process across your entire organization.

see Full list of integrations
Show all posts
7 years ago

10 Most Common Mistakes in Agile Adoption. Part II

In Part I I've described 5 mistakes in agile adoption, this part has 5 more.

6. CST Knows Everything

Certified Scrum Trainer is not a God. Yes, he knows a lot and has a decent experience. There is a high chance that he may be a capable person to help with agile adoption, but only help. He may know nothing about your domain, about your unique situation and about root problems of your organization. If you rely solely on CST and delegate agile adoption to him, it will fail.

Everything should start from the culture and people. It means everything should start with you. You should share agile values and support CST with all the passion and force you have to make agile adoption a success.


7. Functional Departments Should Survive

You are starting a new agile project. Design manager delegated one designer to the team, but refused to re-allocate his desk. QA Manager delegated several testers, but refused to re-allocate them. Developers sit together, but all the other team members are separated by walls. Sounds familiar? Most likely there is no cross-functional team there, and agile adoption will suffer. 

There are absolutely no reasons to keep functional departments and functional teams. People should work together as a team whenever it’s possible. Definitely, when you have testers in US and developers in India, it is hardly possible. But it is just plain dumb to NOT have cross-functional team if everybody sits in the same building.

Cross-functional teams have so many positives, and no negatives. With cross-functional teams you improve communication, reduce functional competition, simplify problem solving, enable ad-hock process improvements and creativity. Again, there is NO reason to work with old traditional functional teams.

8. We Can Live Without Customer Feedback

Agile is mostly about fast feedback. Feedback from customers is the most important. If you build something with wrong methods, that’s bad. But if you build a wrong thing, that’s just terrible. Why? You will have to throw it away later. Regular (and fast!) feedback from customer is like a sailing direction in a bay with reefs. You constantly correct the course based on wind change and other factors. Customer is the most valuable team member and should be treated accordingly.

Extreme programming recommends to have customer on-site. While this is a great tip, it is rarely practical. Still, you have customer available remotely all the time to answer questions and communicate about a product. If you can’t have feedback in a reasonable amount of time, agile methods will not work. You may build a technically perfect product, but yield zero customer’s satisfaction in the end.

9. Self-organization is Easy

Scrum heavily advertises self-organization. Complexity theory has something to say about it as well. Self-organization is based on a set of (simple) rules, non-linearity and interactions between agents (in our case between people). As a Scrum Master you should just set some (widely known) rules, protect the team and expect the team to self-organize. Right? In reality it is not that simple and no, it will not work out. I’ve never seen self-organization working with just a set of rules.Self-organization in a software development team needs more, it needs leadership. I believe that self-organization can’t happen without leadership.

Pure self-organization assumes that a leader will emerge. That’s not happen frequently, in many cases team will stagnate and fluctuate around mediocrity without a leader. Leader sets a vision and pushes team to the right direction. Leader empowers confidence, passion and self-reflection. This leads to self-organization eventually. 

What happens when leader leaves the team? In most cases it falls back or degrades slowly. This is a clear sign that self-organization was not there. True self-organized team will keep its values and progress without a leader.

10. False Goal (e.g. Customers asked us to be agile)

If you have a customer who insists on agile process for his project, you should praise Heaven for this gift. Use this chance as a turning point for agile adoption.

Unfortunately, many companies just try to “emulate” agile adoption with a desire to get this contract. They send some people to CSM courses, purchase an agile project management tool and apply Scrum superficially. They do all that without deep goals and culture change. They do all that without passion. They do all that with a false goal. Almost inevitably there will be the following symptoms:

  • Sprints fail. Always.
  • No commitment. 
  • Scrum Master assigns people to user stories.
  • Testing phase in each sprint.
  • etc.

The result of “false goal” agile adoption is failure and a long-term disappointment with agile software development.

I encourage you to share another mistakes in agile adoption!

  • Mikalai Alimenkou

    Great article! Must read by everyone who is going to start Agile transition. I would add one more mistake: “Agile is great! Lets do Agile!”. When you have some people inspired by Agile (returned from public Agile conference, some kind of training or just new people in the organization), but without understanding current processes and having no experience with Agile transition. They may work like virus, breaking all existing processes and techniques without good replacement. It is important to remember that Agile is not a “silver bullet” and any methodology should be applied depending on particular context. Sometimes these people are “Scrumoholics”. I wrote a post some time ago about them and how they affect organization: http://xpinjection.com/2010/09/24/shu-ha-ri-for-scrumoholics.

    Once again, thank you for this article! It is really very useful.

  • Sduncan

    On point 6, CSTs are trainers which does not mean that they are coaches, so I am not sure why CSTs are somewhat singled out here. Why not CSCs as well, for example?

    I see point 8 a good bit. Some call it “stealth” Agile since IT/dev orgs decide to pursue Agile ideas without engaging business folks/customers because of how hard that really is. So the go ahead an the rest of the organization acts like Agile is not going on or isn&#39t there/visible, hence the “stealth” reference. Bad news…

    On point 9, what I see is not the assumption that it is easy, but that it is something to “postpone” because it is hard and will take time. So teams are given deadlines, fixed scope, and told, basically, to work Agile within those constraints. So you end up with iterative waterfall and a lack of interest in real Agile planning and estimating because the teams feel “we&#39ve got to do it all anyway” by the deadline.

  • Michael Dubakov

    All good additions. CST was used as an analogy with (advanced) CSM from Part I. It is applicable to all agile coaches for sure.

  • TimO

    I disagree with point / anti-pattern 7; there is a place for functional departments in the context of agile work management – you are confusing your dimensions here (IMO). There will always need to be a line management structure through which your resources are managed, not just from a HR/administrative perspective, but also from a functional leadership perspective (i.e. best practices, standards, policy, behaviors, etc.) The key is to ensure that the vertical dimension (the line management structure) and the horizontal dimension (the work management structure) are clearly separated in terms or roles and responsibilities – and individuals may perform roles and have responsibilities along both of those dimensions, which are orthogonal to oneanother. A functional organisation provides the most flexibility in terms of supporting a work management structure (such as Scrum, etc) which horizontally cuts across those functions and organises cross functional teams (in a Scrum) to perform the work that&#39s needed. If you conflate work and line management (e.g. build a department which contains staff from many different functions [i.e. job families, such as product managers, software engineers, QAs, etc] and then manage that department&#39s work using an agile technique such as Scrum) then you end up with a very inflexible and brittle structure. Maintaining and cleanly separating these two dimensions is critical, especially in an enterprise (large organisation) context, where you may have large functional teams, across which multiple scrums may be running (and pulling resources from those functional line management structures). In a smaller (say start-up) context, of course you do not need to think about this sort of separation (since you usually have a “multi-functional department” which essentially is the business itself), but in a large/complex/enterprise organisation, you do.

    So there is a place for functional teams, as part of a larger functional organisation, in the context of agile work management. The important thing to remember is to keep the dimensions separate (functional management is vertical, agile work management is horizontal) and to ensure that you do not conflate one with another (e.g. embed a function / functional department within a scrum / work management structure).

  • Baere

    Nice articles, both of them!
    6) Absolutely!
    7) For sure, from a point of view of projects having real cross functional team is ideal. The purpose of IT is to serve customers so if IT needs functional teams or not depends on the environment you are working in and on the goal of IT within the company. For me the point of cross functional teams is that every team member is willing to work for one another rather then not to have a specialisation. It’s like with football when you are the goalkeeper (a specialisation) and you have to opportunity to make a goal you will do so without hesitation. For me that’s the spirit of teamwork, specialisation or not.
    8) Also here, it depends on the situation. Just as an example, if the uncertainty/complexity is not at business side but on IT side there is no reason for business to be very close.
    9) I fully agree with the title (it’s not easy) and just want to nuance things. For me you have two domains on which you can be leader: technical level and cultural level. What is definitely needed is leadership on cultural level or in other words how to become self organizing. On technical level leadership is not a necessity for me. Regarding leaders is see two kinds: “leaders” and “leaders of leaders”. The leader will focus on the job at hand and when he leaves the team, the team has a problem and, as you say, will fall back. The “leader of leaders” on the other hand focuses also on people becoming a leader. A “Leader of leaders” will pull people up to leadership and so create leaders. When “leaders of leaders” leave, the team can grow further. It’s the leader of leader that creates real self organisation.
    10) So truth and I guess it’s all a question of maturity. Sending someone on a two day training and hoping that he will return as a perfect scrum master is just naïve. The same is truth for sending someone on a two-day training on prince 2 and hoping he will return as ideal project manager. Nothing works from the first time. Especially changing a culture towards a trust based culture like scrum takes a long time as creating trust just takes time. In other words, if you want to become agile as a company be prepared to make a serious investment. As a consequence you’d better have the good reason for it.

  • Michael Dubakov

    You blowed my mind 🙂 We speek different languages.

    I personally don&#39t think current organizational structures are perfect neither efficient. I believe future belongs to smaller cross-functional units that will network into a large organization (if required) or work almost fully autonomically (if required).

    Also I think it is beneficial to inject Scrum (or any other agile process) into all levels of the company, shrink that levels to 3 (no more) and break functional departments. But. Scrum is not enough. It says nothing about organizational structures, as well as other agile processes. We are at the edge of significant business change. Very interesting things are happening in various disciplines.

  • Baere

    Now I see, I thought you talked about the introduction of scrum/agile in a company today but you speak about changing the structure of companies on a more global scale. That&#39s another story, I belief that within 5-7 year there will be a lot more netwerk based small independent structures that are cross functional internally and very specialized towards the market. In what timeframe do yo see this happening?

  • Michael Dubakov

    I am not such optimistic. Such changes are huge and take time. Maybe 10-20 years time frame is a good prediction so far to have many companies (near mainstream?) shifted into new structures.

  • XebiaLabs

    Michael, great list. We’d like to add #11 to your list of common mistakes in agile adoption: not using automation for deployments. Agile creates lots of benefits for a company, especially with the shorter iterations and more frequent deliverables, resulting in faster time-to-market. However, without agile, operations teams often can’t keep up and consequently develop a backlog of deliverables to deploy. By automating this process, not only can IT departments stay on top of the faster iterations agile allows, but can also cut down on human errors resulting from manual processes. Would you agree with this addition to your list?

  • TimO

    Certainly current organisational structures are far from perfect and need to evolve (from their old “command and control” style, from back in the days) to one where they can, in the context of agile work management, enable and facilitate that style of work, which does typically cut across organisational units, whether functional or otherwise.

    But organisational units will still exist (and have to exist), and in many (large) companies, will necessarily have to be more than 3 deep (since 3 deep will only scale so far). But these organisation units need to evolve (in terms of what their role is, specifically that of the manger of such units, whether functional or otherwise), as our work management evolves, and clearly agile work management is becoming the dominant pattern.

    Here is a reference to a great article which was recently forwarded to me and I&#39ll share with you (all) here… “Manager 2.0: The Role of the Manager in Scrum”


    This is a great read and is very aligned with my own thinking.

    If you read this, you will find that my comments aren&#39t actually that mind blowing after all 😉 It really is just a case of clearly separating these dimensions (line- and work- management) and ensuring that they one supports the other (rather than interferes with the other).

  • Baere

    Regarding the timing I guess everything depends on the circumstances as they dictate what happens. People will not become agile (or whatever we call it) for the fun of it but only out of necessity. As you said: we are at the edge of significant business change and pressure to become more effective is increasing fast. Agile is a possible solution so the faster and harder the pressure will be the faster we’ll have more agility. I see pressure from two directions: the market (the world is flat) and the people. People want to be treated like professionals instead of subordinates. Ones we reached the tipping point everything can go fast.

  • Michael Dubakov

    Nice thoughts about pressure. I like it! (and agree)

  • Michael Dubakov

    I agree and want to expand automation even further. If you want to have short feedback cycles, it is inevitably leads to automation. Unit tests, functional tests, performance tests, deployment — all that should be automated to have fast feedback. Otherwise it will be near to impossible to release, lets say, weekly.

  • Pawel Brodzinski

    Another great article. While I totally agree with the most of the post there&#39s one point where I strongly disagree: “There are absolutely no reasons to keep functional departments and functional teams.”

    Well, should we put one fifth of sys admin in each cross-functional team? And what about one fourth of tech writer (in case we&#39re big enough that we have people working as tech writers)?

    I agree that core functions should be, if possible, in one team so designer and testers should move their butts and join the rest of the team (or the rest of the team should join them). I believe that in general cross-functional teams work more efficiently than functional ones. But then, sometimes I see very good reasons to keep functional teams. Jurgen Appelo addressed that neatly on his session on AgileEE.

    Personally I tend to build cross-functional teams but I don&#39t keep it as orthodox rule.

  • Michael Dubakov

    I think I failed to express my thought here. Sure there may be some exceptions, like tech. writing etc. I mainly was focused on development and testing, on people that should be 100% dedicated to a project.

  • nelson brito

    In fact some times scrum masters not only assign people to tasks, but they do some kind of micromanagement on the evolution of the tasks, and in Scrum of Scrums instead of discuss and avoid impacts with other scrum teams, scrum masters are “giving status” on the teams tasks.

  • Bruce Onder

    It&#39s a good ideal to strive for, but we&#39ll always fall short. 🙂

  • Alex

    Liked your post, especially #8 & #9. Self-organising is really hard for a lot of people, so without a bit of supervision from the project manager or scrum master… it sometimes goes bad. The daily scrum meetings really help keep people in line on the major items, but you can still loose a lot of precious development time on smaller things

    As for customer feedback… we use a widget to track customer feedback and integrate it to our backlog – quite useful.

    Product Manager at Planbox

Try for free

Account url: *.tpondemand.com
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy