Half-baked Agile

I have been involved in leading several agile transformations at this stage in my career. In every case many of those around me held firm to a core belief that they had already been working in an agile way, and that the cultural transformation was for the others, not for them. In particular three groups of people stand out:

  • Engineers who believed that their involvement in SCRUM-like ceremonies for planning was evidence that they were working in an agile way.
  • Product owners or project managers, who also felt that planning on a regular cadence was the key facet of agility in the context of product delivery.
  • Senior managers who believed agile ways of working were for their teams, not for them, and continued to operate using deadlines and traditional milestones as their key tools for creating accountability.

In all three cases, the majority of parties with these beliefs were actually not working in a truly agile manner, and therefore were not realising many of the benefits of an agile approach. In fact, the added planning overhead and lack of rigourous forecasting led to worst outcomes, greater inefficiency and lower quality.

In short: when poorly executed, agile methodologies will lead to significantly worse outcomes than traditional top-down project management.

Unless your whole organisation is humble enough to participate in a cultural journey of learning and adjusting their ways of working, you should stick to the gantt charts.

The invisible project plan

In many problematic cases a common factor is that product leaders have already formed a very clear picture of their end product. The human mind is naturally inclined towards creating paths towards clear destinations, and so these leaders quite naturally have a predefined roadmap in their mind, and often some personal view as to how long each step on that journey might take.

This mental picture, although perhaps never documented or communicated as such, is simply a traditional project plan – a gantt chart in the mind of the leader. A leader with such a picture in their mind, who then tries to drip-feed pieces of their own preconceived waterfall plan to their team, will ultimately undermine the health and productivity of the team. Any such plan will likely fail.

  • Traditional project management involves significant upfront planning to ensure that roadblocks and challenges are preempted. Without this process, an overly rigid plan will fall victim to emerging issues which the team are not equipped to address.
  • The agile process demands that the whole team are on a journey of discovery – all clear in the same overall vision and objective, but equal partners in finding the path to get there. This equity is key to the cultural foundation upon which successful agile teams are built. A predefined plan in the mind of one team member destroys this powerful catalyst.
  • The focus of a leader on a deadline which the team haven’t been involved in committing to will inevitably lead to stress within the team as a whole and in the individuals in the team.
  • Agile teams have the ambition to increase the capabilities of all team members, but under extreme pressure to deliver individuals will revert to their natural areas of expertise and seniority. Most often this will manifest itself as a “star player” driving too many tasks, compromising the learning of others, the quality of the final product and the long-term sustainability of the team.

Sweating the small stuff

Another challenge is that the individual specialists in a team will often make decisions based on their own value system rather than based on the context of the current product iteration. For engineers this may mean over-designing and gold-plating technical components which may be needed one day, but are not necessary here and now. For visual designers it may mean obsessing over a long-term visual strategy when the fundamental user experience is not yet established.

Nobody believes that all challenging problems can be kicked into the long grass forever, but bringing value to your customers earlier, and learning from the experience, will necessarily require compromises at each step. What is important is that there is a clear overall vision for each building block of the final product, and that each team member is committed to the sustainability of the solution in the long term.

Avoiding these common issues

So how to avoid these pitfalls? First and foremost, product leaders must be courageous enough to challenge their own preconceptions as to what the end product might look like. By relinquishing this control, and focusing on defining a clear vision and articulating desirable outcomes, they begin to unlock the creative potential in their whole team. This is a fundamental prerequisite for increasing innovation in a team or organisation.

Secondly, all members of the team must commit to engaging in the pursuit of learning. This requires that egos be left at the door, and that humble exploration of a problem space be the priority for the team. Toxic members of a team to presume to know and won’t engage in this learning journey must be coached towards this new style of teamwork.

Thirdly, all design work – technical architecture, UX, legal frameworks – must be conducted in an agile fashion. All practitioners of engineering, UX or otherwise must become skilled designers in their respective areas of expertise. This enables each individual in a team to make informed decisions about how to deliver only what is necessary to achieve the short term outcome which is in focus without compromising the overall vision.

The adoption of agile ways of working is a learning journey in itself, and aspiring agile product teams will identify with one or more of the challenges outlined above at some point on this journey. Only by staying humble and seeking to improve can the team and its constituent members guarantee that they will progress in the pursuit of the promised benefits of agile product development.

Photo by Alex Lion on Unsplash

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.