The Agile Trap
Over the past couple of years, Agile becomes a default buzzword exceeding the tech industry. Agile is present in every Enterprise IT regardless of whether it is referring to the original manifesto, philosophy related to iterative and collaborative development teamwork, or project management techniques such as SCRUM.
“Our tech teams are learning Agile. Our product teams are learning Lean and our design teams are learning Design Thinking. Which one is right?” — Jeff Gothelf
Most of the teams understand the Agile umbrella as a set of techniques, processes and rituals that allow teams to develop and ship digital products faster, reduce waste and enable the team to work effectively. In the current era, the enterprise world is already aware of UX Design and Product Management roles and domains, but a clear shared understanding of how its tools and techniques are related is missing.
Too often, Product Managers and UX Designers are only in advisory and complementary roles. It is not the Product Manager guiding the team through the problem-solving iterations and it is not the UX Designer prototyping these ideas into design artifacts validated with users. It is the engineering function leading the design process and rushing forward in “Agile” fashion, seeking input and advice from other functions when in doubt.
It’s a challenge to establish balanced and trusted triad roles relationship. In this post, I would like to cover a few traps that I was able to observe with development processes referred as “Agile”.
But, developing this will be too much effort.
This is the most famous sentence that every designer and product manager hear from their engineering partners. It can signalize the lack of mutual trust, where dismissive technological constraints are formulated because a mutual understanding of the goals is missing, or simply there is not enough motivation to dig deeper.
But even in a great teamwork setup, when engineers are replying with this catchphrase, it highlights the lack of understanding of the basic Agile and SCRUM concepts — relative sizing.
The implementation effort can only be estimated against another piece of work, and impact and benefits of the result can be only weighted against business goals and enhanced life of users. Effort vs. Impact estimation is never one-dimensional engineering decision. But it is difficult to get this right when the development is outsourced to a 3rd party. When the development team is not integral part of the design process, engineering proxies — Architects or Engineering managers — are the ones subjectively estimating the effort upfront and using this as a judgement of the technological feasibility. But it’s a trap, because detailed technical specifications are not defined upfront (bloody waterfall), so how can anyone even remotely guess the effort?
When it comes to pure engineering effort, the ideal solution is to do nothing. This is often the case when suggested product design specifications involve modifying default or out-of-the-box configuration of the platform or library. If the defaults “works” there is very little chance to succeed with these requirements, no matter how big impact they can have on the quality of user experience.
The psychology behind “it’s too much work” is an interesting for me to study and understand, as many great solutions die every day with this single argument. In an enterprise environment, our end of the month salaries does not depend on the fact whether we will work on a story for 3 weeks or 4 weeks, especially if we would deliver 50% greater value. When working in transforming organizations, we are even directly asked to not cut corners and aim for the greatest possible impact on lives of our users that already suffered for too long. However, this mission statement is not formulated in any of the commonly adopted Agile development rituals and success only comes from shipping and “job done” pile.
I believe that the solution is in building mutual trust between interdisciplinary teams and continuous refining the problem that we are all trying to solve. Breaking down the work to smaller pieces is also an important art to master. A big and scary customization task can be disassembled into 3 relative simple configuration tweaks, and in this new light, the whole requirement looks trivial compared to the impact it might have on the product consistency and quality of the user experience.
We do Test and Learn like Startups. We do MVP and then see what’s next.
With all the Startup success stories, enterprises might feel that they found the answer to their legacy systems, lack of innovation and poor velocity — and it’s called MVP.
The problem is the Product in MVP. What a startup need to test and learn quickly with product-as-prototype that real users can actually use is not how the code runs or the usability quality. There are far more effective prototyping techniques to validate this. Startups needs to validate their business model including adoption, pricing and competitive landscape or scaling and continuous delivery plan.
We can still deliver great new innovations within the enterprise world, but a new version of an existing enterprise product rarely disturbs the 20k company sales & marketing model and a new internal service adoption will be always 100% as soon as it is required to be used by a certain group of people or whole department. Especially when it comes with a mandatory training ;)
Product-as-Prototype Discovery: The main sign that a team is using Product-as-Prototype Discovery is that experiments don’t appear until after there is a prototype with working code. The other sign is a slow testing cadence.
MVP is becoming a common Agile trap when a long-term goal is missing. The Phase_1 is done, but it is unclear what is the Phase_2 or how many phases are left to solve for a scoped problem.
Teams might have bad “pre-Agile” experiences or biases from long-term planning that is now completely missing since it was proven not precise in the past. Long term goals or overall product vision were often vaguely defined as 1–2 sentence slogans or pure business metrics. But none of this can help the product team to effectively focus on specific features, prioritize the backlog or understand what they want to achieve. So now they rather focus on building a smallest possible product increment and hope that by throwing it into the wild, the rest would become more clear.
While I wholeheartedly believe that working code always beats any virtual reality prototype in its impact, these MVP efforts are completely missing the point of the prototyping process. The goal of the prototype is not to ship or define a locked set of requirements. The goal of the prototyping process is to learn, communicate, validate, change and evolve, but instead of textual and verbal abstract description, use a tangible and interactive user interface artifact simulating the experience that the user will have.
It will be always cheaper, faster and more effective to discover, iterate and learn from digital prototypes than from a real working production code hooked to real databases and authorization engines.
In an enterprise environment, MVP’s are never used to discover and learn. I am yet to experience a situation, were a group of stakeholders will confirm that “Yep, what we learned from this MVP is that this path is a dead end. Lets’ scratch this MVP, remove the code, choose a different platform and move with the Plan B instead”. These MVP’s are then productized or fixed into the final solutions. And this is my friends, how a clunky enterprise software is born.
Not all the companies were born Agile and especially in enterprise world, it is also important to understand the previous experience and process. Agile was mostly adopted to improve the velocity and improve the lack of innovation. Enterprise environment is full of legacy products that survive decades, but same is valid for the mindsets, tools and techniques, regardless the buzzwords or trends presented on the surface.
I am adopting two main techniques to overcome these challenges: building relationships and understanding different functions goals and motivations and introducing effective and sophisticated-enough prototyping process.