At the end of January 2019, my colleague Přemysl Mika and I presented at the Agile 2019 conference. And since we promised to materialize the content of the presentation somewhere, I am writing this article. Thanks for all the comments made or sent in by the brave warriors who are trying to introduce meaningful agility while resisting the meaningless one.
“And that’s enough!”, I would like to shout as loudly as possible. All too often we have to fix dozens of clients’ botched attempts to implement Agile, Scrum, SAFe, Spotify and similar methodologies into their organizations. All too often we have to correct erroneous or misleading claims about Agile. Yet Agile itself is not to blame for the failure of transformations. Fortunately, there are already a number of educated, experienced and sensible people in the industry who understand the bigger picture and can guide you through the Agile conundrum.
So we’ve compiled seven of the biggest and most commonly repeated agile transformation myths, with each alone deserving the well-known “Erratic Boulder” anti-award because each one also dooms agile transformation to desperate floundering.
1. Agile solves all your system problems
“We can’t manage projects well.” “Our IT has grown too fast and it’s a mess.” “We’re short of architects, analysts...” “We have a hot testing environment.” “There are no clear business roles.” “There’s no corporate strategy.” “The corporate culture is terrible.” We have repeatedly heard a solution to all of this like thirty years ago at the doctor’s office - only instead of the prescribed penicillin, the “agile expert” wailed: “Take Agile!”
No, Scrum doesn’t really solve the aforementioned problems. Name the problems accurately and address them where they are. You will likely benefit more from implementing ITIL properly for your IT processes, PRINCE2 for project management, getting a good business architect and, last but not least, a coach to help HR change the corporate culture. Don’t hide behind Agile; instead, deal with incompetence where it really is. And among other effects, this will in turn have a positive impact on your ability to introduce Agile into your company.
2. Agile approach is only applicable in some environments
Agile is not Scrum. Agile is a philosophy, a set of values, a way of thinking and behaving. This includes a number of techniques, methods and concepts. If you really understand Agile, then you know that there is no environment, project or area of business where some of the agile approaches, behaviors or ideas cannot be used. Working with backlogs and sprints, for example, for facility management. Value drive and prioritization using MoSCoW for portfolio management. Building an autonomous, fully self-organized team in an otherwise traditional project. Shifting the culture of corporate departments away from blaming towards trusting. Using the T-Shaped skill set concept in recruitment. And last but not least, an emphasis on Servant Leadership pretty much anywhere (Caution! Not anytime!). Agility is applicable everywhere - you just need to know what it really is and how to use it effectively.
3. Agile is clearly defined
Agile approaches may have a history, but in terms of clear process definitions, they are still in their infant years. Concepts, methods, and names constantly emerge and disappear. For example, we too have moved from DSDM Atern, which we trained years ago, to PRINCE2 Agile. That’s perfectly fine. But please don’t let anyone offer/sell you “Agile” as a clearly defined and established methodology. The Agile Software Development Manifesto was created in 2001, yet it can easily be summed up in one slide. The Scrum Guide is from 2010 - and is just a few pages long. DSDM Atern was born in 1994, PRINCE2 Agile less than four years ago. And if you’re using the “Spotify” model, know that it is not actually described at all - it simply does not exist as a best practice. And LeSS, or maybe SAFe? Even those have only been around for a short time and, more importantly, we’ve been criss-crossing the country and nowhere is it properly established yet. And they don’t really go by the “book” - perhaps the furthest progress we have seen is in Tieto in Ostrava. Again, not bad. It’s just fair to say that we’ll have to look for best practice together. And keep educating ourselves and finding out what REALLY works where.
4. Agile is about a strong Scrum Master or Product Owner who leads their team firmly
As a former programmer, I have come to appreciate the basic tenets of agile, and Scrum as well. For example - developers are intelligent enough to organize, motivate and commit themselves in a reasonably small team to meet agreed deadlines. They can also liaise with the client and negotiate the details of the assignment directly. It has always frustrated me when companies, project managers or business people have gradually created an environment where those IT guys had to be tasked, pushed to deliver results, and by no means let anywhere near the client. This has always been bad (albeit widespread) thinking. But it was in the context of Scrum that it started to be discussed more clearly. Empowerment, self-organized teams, autonomous teams – finally! Yet then I experience even more disappointment whenever I see companies/IT departmetns in Agile/Scrum deployments hiring “senior” Product Owners or even senior Scrum Masters who think and talk the same way - how they have to task those developers in Jira, push them to deliver, and ultimately the Scrum Master acts as interface between the team and the project, if any. Unfortunately, many have taken the easier path that is actually a dead-end way. Please, let’s go back to the original ideal and invest in a senior team and truly autonomous units. That is the only way how to extract maximum value from the original Scrum idea.
5. Agile means not planning
A plan - project or otherwise - is not a fill-in-the-blank template; it is not just a piece of paper or a complicated Gantt chart. A plan is a DEFINED path toward a goal (even a changing one) created by the implementation team. It is certain that reality will vary, but as D. D. Eisenhower said, “No battle was ever won according to the plan, but no battle was ever won without one.” Let’s replace the word “plan” with “thinking” for a moment. I am always annoyed when I encounter the claim (thankfully receding nowadays) that we don’t need to plan (read: think) thanks to Agile. I’ll use, with permission, an analogy borrowed from Keith Richards (officially one of the biggest gurus in the UK Agile world) - the Hornet fighter is very, very agile. But that doesn’t mean it doesn’t have clear control mechanisms and a well thought out plan. Clearly, using Scrum in a more complex environment requires experience and non-trivial deliberation. Sophisticated backlog work, mixing should-have requirements along with must-have requirements from the first sprints, dividing the capacity (velocity) of the team for different purposes. Estimating backlog distribution across multiple sprints due to interdependencies among products. And I could go on. If the team can’t plan, (read: think through the work), don’t make excuses that you are doing it agile; instead, roll up your mental sleeves and learn to plan.
6. Agile transformation is all about reorganization
Similar to having a strong Scrum Master instead of a strong team, many companies have embarked on agile transformation the easier, but poorer way – we reorganize. And sometimes brutally and senselessly. But if we now set aside the crazy caricature of reorganizations like replacing project managers with other roles who will “...probably do something like a project manager, even though we’re not allowed to call them that here”, we still miss the point. The greatest value of agile approaches is in changing the culture. Unless one of the key players in the agile transformation is enlightened HR or if you avoid actually empowering your people or if your management is not prepared to change the way they make decisions and reward, unless trust becomes one of the core corporate values, unless the Procurement department changes its approach to suppliers, you will forget the major benefits of agility. The beauty and power of the agile approach is in the “behaviors”, not the concepts and methods. Yes, I acknowledge it’s a harder and longer road but, on the other hand, it is much more meaningful and sustainable in the long run than simply reorganizing into DevOps and/or Tribes and Squads.
7. Agile transformation should completely replace project, PMO and portfolio management
If anyone is still telling you that, with an Agile approach, an organization can do away with projects, project management and project office, then it’s a safe bet that they don’t know what Agile is for, and they have no clue about project management. It’s as disingenuous as, say, claiming that someone is delivering projects by Scrum. Scrum is not about project management – it’s about product management. A project, by definition, is a temporary organizational structure through which we deliver a comprehensive change. And, surprise surprise, every project (yes, even GDPR or a new hotel) can use agile approaches to varying degrees. So please, stop senselessly abolishing PMOs and renaming project managers to roles with more agile names (does Tribe Delivery Manager really sound more agile?) and, instead, train your program and project managers to be able to communicate in agile terms and make the most of all the benefits that Agile has to offer. Feel free to rename the PMO (P3O) to APMO - Agile Project Management Office and ensure that the organization can synergistically leverage the best of Portfolio (MoP), Program (MSP) and Project (PRINCE2 Agile) management. You can cleverly combine ITIL, XP, Scrum, PRINCE2 Agile, LEAN and many more. In fact, each of the above serves a different purpose, and they work beautifully together.
In order not to talk only about delusions, let me conclude with seven recommendations:
- Beware of false prophets – Agile evangelists who have never worked long enough in a complex enough environment and, therefore, cannot grasp the breadth of the topic and related issues.
- Involve your HR in the transformation – Changing the culture is more than changing the organization.
- Set up an Agile P3O – Task your PMO department to find a symbiosis between Agile and traditional change delivery.
- Empower your teams – Don’t hamper team growth with a strong Product Owner or Scrum Master to manage them, only to replace, say, a Project Manager.
- Define everyone’s roles and responsibilities – Clearly name roles and responsibilities across the traditional and the Agile worlds.
- Get trained – Don’t settle for repeating simple but untrue phrases. Find out what it’s really like. Ideally from someone who knows the topic and the related issues in their entirety.
- Be agile – Understand the beauty of Agile and think Agile not only in your work life but also in your personal life.
... because the pressure to deliver the most value, prioritization, proper delegation, creating an environment of trust, cooperation, incremental delivery and many others are ideas that are simply worthwhile!
