Being a (independent) consultant gives you the flexibility to observe and work with many different companies and observe what makes them tick from the inside. Observations lead to patterns recognition and therefore, anti-patterns recognition. As I often state, a large amount of my expertise lies on being able to identify patterns and make suggestions accordingly (I like to think of it a little bit as predicting the future!)
Also, as an Agile coach, I have the opportunity to work with all the levels of an organization, depending on the task. However, more often than not, I have to reach out to almost everyone from team, Product Owners and Scrum Masters, to managers, directors, heads of etc, to have a holistic view of the respective situation.
Below I share some of the anti-patterns I have observed in large organizations while trying to adopt Agile. I will not concentrate on providing solutions since I think that solutions should not only be heavily tailored to each case, but also they deserve a roper book of their own.
1. Too fast
Sometimes there is eagerness to “become Agile” to the point that not only the activity is time boxed (“we have 6 months to become Agile”), but also people get frustrated because they don’t see the results they expected as soon as they expected. This of course leads to badly-implemented-anything, people not knowing what is going on around them (“didn’t you hear? This is how we estimate now!”), and general confusion.
2. Too slow
This is a frequent trait of large (listed) organizations. More often than not, the share price is what drives and motivates large organizations. Nevertheless, if the company is cash rich, it’s a completely different story, since these companies don’t need to urgently change anything; they’re already generating a lot of money. Therefore the tiniest change not only poses a risk, but also is hard to justify. This in turn drives any change dead slow or impossible.
3. Agile with an Iron Fist
“It’s been a C-level decision to become Agile” is the beginning of the story sometimes, and I think having support from the very top is a great thing. In fact, if you don’t have support from the top you’re not going to achieve much with guerrilla Agile as your influence would stop to the first person who does not believe in change. Only narrow tactical improvements – those which affect individual teams rather than the whole organization – are likely, without the clear and unambiguous support of senior management. Sometimes though, you will find some people (usually middle managers) who are eager-to-agilify everything, and who may not have experienced any form of Agile before. These people usually have watched a YouTube video on Scrum or been to some half-day Agile training, and are willing to enforce changes upon their teams, either the teams like it or not.
4. We want to do Scrum / Kanban / Agile, starting tomorrow
Ancient Greek philosopher Heraclitus said “Life is Flux” (“ta panta rhei” in Greek, meaning everything or all things change). Change is the only constant in life. Therefore eagerness to change is good. However all things take time, and a good starting point is to start asking questions such as “where are we now?”, “what do we need?”, “why do we need to change?”, instead of nose diving into implementing some trendy sounding framework.
5. Renaming maketh Agile
This is a classic one: whoever used to be a project manager is now either a Product Owner or a Scrum Master. You will find that people sometimes say “we don’t need a Scrum Master”. When you begin to adopt Agile ways of working and you’re doing Scrum, you need a Scrum Master, otherwise you’re doing something else. Most organizations don’t know what they do when they “implement Scrum”, therefore thinking that they don’t need a Scrum Master. Other roles renaming includes business analyst to Product Owner, line manager to Scrum Master, line manager to Agile coach and others. Sometimes new roles are invented, like technical Product Owner or end-to-end-QA.
6. X% Agile / X% Scrum
Although I do believe an Agile transformation should be treated as a project on its own and have its place in the PMO, and subsequently have risks and impediments identified and resolved, I don’t think it can be tracked simply similar to some software product. I’ve heard numerous times “we are X% Agile” and “we do 70% Scrum” (whatever that means), and I just let it slide. I would much rather hear “we adhere to some of the Agile principles and practices and we are keen to explore more” rather than quote a percentage of transformation.
7. Suddenly let go
There is a phrase from fantasy writer Brent Weeks that says: “Delusional people tend to believe in what they’re doing.” If you believe that one fine day you can suddenly “roll out Agile” and completely let go control of your teams who, by the way, have been doing waterfall or similar for a long time, then you’re clearly delusional – for a number of reasons. This is an anti-pattern that starts off with good intentions i.e. empower the people who are expert and deliver work, only to lead to frustrations, disengagement, delays and bad overall management.
8. 100% outsourced
The office in <location 1> consists of only a few people, and we have outsourced all our departments to <location 2>. I think this is a case on its own and would have bigger problems than trying to implement Agile.
9. Upfront everything
One of the pillars of Agile is to embrace uncertainty while responding to change. It’s hard to do and it doesn’t apply to everyone (see point on “Too slow”). Therefore, while a good high level plan and long term strategy are welcome, detailed planning with concrete deliverables can be orthogonal to the adoption of agility.
10. We don’t talk with them!
Split locations for large organizations is not new, however there are different levels of multiple locations: being at a different country, is trivially more challenging than being on a different floor in the building. Therefore, the closer the people are sat together, the faster the communication and the smaller the feedback loops. This is a good exercise for line managers to facilitate and therefore contribute to the company’s culture.
11. No visualization – Complete blindness
Time and time again, companies have tried various transformation initiatives, only to end up fragmented and partly owned by individuals and middle managers who are unable or underpowered to do anything with them. A usual anti-pattern is that a meeting is started, issues discussed, agreement is reached but no solutions or plan exist, and most importantly no evidence of the meeting exist (I am not referring to meeting minutes, but to an action plan). Visualization boards (or Kanban boards for more advanced organizations) are an excellent starting point to address this.
12. Squadify everything
Sometimes, out of over-excitement, organizations go from completely siloed people and actions, to create teams for everything, therefore finding themselves to the other far end of the spectrum: where once there was an individual dragged to too many places to offer his services, is now a member of 5 different teams, trying to contribute 20% to each team. What’s worse, is that we name those teams squads, therefore losing the notion of a squad. Which leads me to the next anti-pattern, member of multiple teams.
13. Member of multiple teams
This gives rise to a number of problems, with the most important one being the inability to concentrate and to commit to one team’s tasks. From developers to middle managers to directors, it is trivial that when someone is dragged to too many places, then everything is important which in turn is another way of saying nothing is important. This anti-pattern leads to frustration because “we can never get his/her time”, “he has other priorities” etc.
