In some businesses “being agile” is a huge expectation that Stakeholders have of a company. Thus, almost every company nowadays claims to be “Agile”. Even though traditional waterfall management is still a reasonable method for complicated (not complex) environments, people do not tolerate it anymore. Consequently, many organizations introduce agile methodology in their projects. Some of them are really serious about it and trigger a substantial change process. Others introduce an Agile Trojan Horse which contains nothing but Taylorism and Waterfall Methodology. As a result, they will create a big disappointment when the agile facade crumbles.
But how do you identify the agile Trojan Horse and distinguish between a serious Agile Transformation and a shallow change of Terminology? Watch out for these Warning signs:
1. Your Agile Trojan Horse fixed your Project Scope
Having a fixed scope on your project is a huge red flag for being agile. Because agile project management is all about progressing your product towards your moving target as you learn more about what your target really is. Your iterations end with an inspect & adapt ritual to process your findings into a changed product backlog.
But if your scope is too rigid and fixed, you will not be able to change the scope. Therefore you just learn that your project is on the wrong track and you’ll watch it fail. You probably still will have rituals at the end of your iterations, but they will feel more like a regular “jour fixe” as known in traditional project management. The team will simply report on a one-pager with a red, yellow and green sign. Afterward, the steering committee will make decisions. Remember, the agile manifesto values “Responding to change over following a plan”
2. Your Agile Trojan Horse is asking you to implement “our way of agile”
“We want to be agile. But we learned that agile is just a framework and needs to be adapted. So can you please find a way to implement our way of agile?” This is probably an all too common assignment for Agile Coaches. And this one is actually pretty tricky. Because agile methodology really is a framework to be adapted for your environment. But you can adapt it in two ways:
- You adapt it at the end of your transition to getting most out of agility in your environment
- You adapt it at the beginning of your transition to continue your former working model without actually changing anything but the terminology
Number 1: Adapt at the end of your transition
Number 1 really is a change process that needs some investment but leads to all the benefits you are expecting from agility. But usually, it also follows the sequence of “Shu Ha Ri”. That means, that you start with strictly following the rules and frameworks that are provided (Shu). Once you mastered this step, you start breaking the rules and adapting according to your environment (Ha). By the time you mastered this step as well, you completely break free from the frameworks and develop your own agile style (Ri).
Number 2: Adapt at the beginning of your transition
Number 2 expects you to start with “Ha” or even “Ri”. This procedure is doomed to fail. It is like trying to learn to ride the bicycle hands-free before learning to ride the bike with your hands on the handlebar first. You surely will leave your comfort zone and that is a good thing. But this challenge will exceed your competence. So instead of being in the learning zone of becoming agile, you’ll end up in the panic zone where the challenge overwhelms you. Consequently, you will not only become frustrated but also fall back into patterns that worked for you before. So you will become satisfied with doing what you did before, but you learned some new vocabulary to rebrand your working model. As a result, you successfully created an Agile Trojan Horse.
3. “Experts” create Non-Negotiable Product Backlog Items
In traditional management, we tend to have expert roles for every domain. They seem to have the best knowledge available. There are for example IT architects for technical designs, product managers, marketing analysts, and many more. Those experts are then trusted to define top-down requirements based on their knowledge, which are translated into product backlog items by the product owner. Afterward, the development team is expected to implement whatever was defined as if they were code monkeys. Unfortunately, this procedure is still an all too common Anti-Pattern in companies that introduce agile methods. But this process misses a critical principle from the agile manifesto:
“The best architectures, requirements, and designs
agilemanifesto.org
emerge from self-organizing teams.”
In agile management, we believe that the best design emerges from self-organizing teams. We believe that people who are doing the work actually have the best knowledge about their work. Consequently, your development team is the best source for creating architectures, requirements, and designs. And while it might be useful to have separate experts discuss Product Backlog Items, it is critical that those items are negotiable. Only if you enrich top-down ideas with bottom-up knowledge a great product can emerge in complex environments. If you miss involving your development team, you’ll dismiss valuable feedback, prevent your team from fully committing to your product and eventually frustrate your team members by devaluing their skill.
4. Your Agile Trojan Horse does not expect you to deliver a Product Increment after each Iteration
Delivering a Product Increment is very different than finishing a batch of tasks. While a set of completed tasks is just proof of work being executed, a product increment is far more than that. It provides value for a customer and serves a purpose. It is a vertical slice of the targeted solution and you can inspect it. In addition to that, it forces you to integrate every part and gives you the opportunity to either continue working on this path or pivot to another. As a result, it minimizes your risk to waste your investment.
Whereas processing mere tasks just give you the feeling of progress which might not be accurate. In the first place, you are measuring the workload of your taskforce by tracking the progress of tasks. It serves no purpose other than keeping your team busy, which is not your highest priority. Because remember, according to the agile principle “Working software is the primary measure of progress”. Forget about that and you are on your way of creating an Agile Trojan Horse.
5. Your customers are all internal Stakeholders within your Agile Trojan Horse
Let’s face it: Talking directly to your end customer is scary. As a matter of fact, you really need some courage to present your customers an idea which is not finalized. Likewise, it really feels embarrassing to confront your customers with an early-stage version of your product.
“If you are not embarrassed by the first version of your product, you’ve launched too late.“
Reid Hoffman, founder of LinkedIn
But this is exactly what agile project management requires. You might want to read my very first blog post to get inspired: “start being agile before you are ready!” It might feel safe and comfortable to introduce internal Stakeholders as a Proxy for “the voice of the customer”. But also, you will sacrifice all the juicy, valuable insights from those people who will actually pay you real money for your product. There is no way around that slightly frightening feeling. But also, isn’t it exciting and strangely satisfying to directly get in touch with your clients? By solely relying on internal stakeholders, you’ll be much more vulnerable to misunderstandings, politics, and psychological biases. Also ask yourself: How will you discover innovation in the unknown, if the unknown is outside your organization?
Key Takeaways
- By fixing your scope, you miss the whole point of being agile
- Do not adapt agile frameworks unless you mastered them first
- Involve your development team in creating Product Backlog Items
- Product Increments are your primary measure of progress – not tasks
- Be brave and show some courage by talking directly to end customers
- Don’t bother introducing agile if you are not serious about it
