90% of executives believe that organizational agility is critical to business success.
Agile working methods are more successful than traditional methods (71.5% and 62.8% respectively).
So why hasn’t working Agile yet become the norm? That’s not to say it hasn’t become a trend, and I’m sure you’ve begun seeing it - as I have - referred to in business settings across industries.
Most often it is down to not knowing where to begin, not having a team fully on-board or being unable to deliver proven success soon enough. Starting out on an Agile project with little confidence, only a general knowledge of the method and a ‘succeed first or scrap it’ mentality from the business can lead teams to run-ins with common pitfalls.
Let’s shed some light on what I believe are three of the most common and impactful pitfalls on a business's first run at Agile on a small scale (i.e. “Innovation Engine” separated from the “Performance Engine” (explore this topic), instead of immediate enterprise-scale Agile transformation).
We won’t only focus on the negative. I’ll share what we as a team discovered are the best ways to overcome or to prevent these obstacles altogether.
Minimizing the risk of failure before embarking on an Agile adventure is the key.
1) Lack of top-level support
This seems obvious I know, but it’s good to be aware that even the management who has given the go-ahead can be unsupportive of the Agile project. On one hand, they may not act on what they promised, for example, giving teams the real freedom to innovate and take time away from usual tasks within the company, or actually implementing project outcomes and taking it seriously. On the other hand, they may not defend the project to other management-level staff and decision makers.
Either way, this behavior can seriously impede the overall success of working Agile.
Striking a balance can be tough.
Too much input and encouragement from top-level management can make Agile projects feel imposed. On the other hand, teams can feel empowered by management support.
For the best chance of getting it right, our first step is to make sure clients we work with are genuinely interested and excited by the prospect and potential of Agile, and also fully understand the limitations and possibilities within their own company setting.
Are you receiving a complete support from the management?
We always go into a project knowing we have the full support of key decision makers and leaders. Whether the management shows a genuine interest, or just a general interest but seem overly cautious, we always start a kickoff with a content input pack to give a short but comprehensive overview of Agile, its principles, and its process.
When we have the support, we aim to get the team together who will be involved in the project - sans manager - to allow them to be open with their questions and apprehension before really getting started with the project.
Transition to the next level(s)- Is your team ready?
Getting employees on the team level excited about Agile is part two. Knowing they have the full support of management, but also trusted with the freedom to execute the project themselves and are able to see the effects of project outcomes on the wider company are all crucial components to maintaining an energetic, motivated, and happy Agile team.
We do also start out with a workshop including Agile simulations as the core activities where we aim to include managers or at least the responsible sponsor of the project. This initial workshop aims to bring everyone to the same level of understanding about how the project will work - the timings and how everyone can work with one another for the most successful outcome.
2) Team members with strong identities with traditional roles
I must make a distinction between those who strongly identify with their roles, and strong personalities. Strong personalities (in most cases) can be harnessed and encouraged to work effectively within the Agile team by an experienced facilitator. Those who strongly identify with their role - meaning their role within the company, not within the Agile team - can be more difficult to sway to an Agile way of thinking.
In the dynamic setup of an Agile project, team members need to be prepared to consistently step out of their comfort zones, to multi-task and to learn their co-workers’ jobs, or at least their point of view, and have the open-mindedness and approach to do so with empathy and without contempt.
Mindset > Skills
Often, just the action of taking responsibility for getting something done for a deadline set in the project, even if it isn’t an employee's usual job is enough to bring them into the mindset of working flexibly and collaboratively. Sometimes it takes a little more encouragement.
Something we found to be very important for an Agile team - especially on their first project - is to make sure they have a separate working environment. This keeps them focused on the Agile team-specific goal, and away from the traditional, waterfall environment within which their usual role is so fixed.
Keeping the Agile team small also helps with bringing a team closer. Smaller teams within the Agile team don’t have a chance to form as a result of people being drawn to those they usually work with. Hence we suggest one representative from each department is present.
By also truly understanding the Agile mindset as a result of studying the core values and principles, team members can see the value of having mutual respect for others. It can help them realize how much they could learn from their new teammates, and the potential a cooperative team can have when it comes to the project outcome.
An example of a team stepping away from their traditional roles to get results and reach their goals happened recently with a team I worked with. Some user research was needed, and usually, this consisted of reaching out to the research team who put together a questionnaire, potentially over days or a week. The interviews then need to be set up and the sales team gets involved to make decisions on incentives and resources. Another department then is needed to carry out the interviews.
In this Agile way of working, this one team is self-organized. They do it all, and any member of the team can carry out the tasks. The work is evenly shared for the absolute quickest output so the team can continue forward towards their joint goal.
Without a fully committed and cooperative team, this is just not possible.
3) Tools unfit for efficient information-sharing
Agile is about working quickly, working efficiently, and that getting things done is more important than having things perfect. Continuous face-to-face interaction aims to ensure this happens to avoid any misunderstanding, miscommunication and to ensure deadlines are met.
As much of Agile projects today are focused on something intangible, i.e. software, UX designs or CX journeys, the right tool to support this ongoing interaction and updating of tasks needs to accompany the team throughout the project.
Selecting the right tool from day one is crucial. It keeps people’s minds on the important things, and off the time-consuming admin.
Discard useless tools!
There’s no room in an Agile team for tools that impede progress by demanding too much attention from one or more team members, by confusing people or simply failing by losing data.
We keep a small, selective collection of tools we have found work best for this kind of project-based, live collaboration. Teams are then able to choose, perhaps depending on which they’re most familiar with to make the onboarding faster and easier (these include Slack and G-Suite, we have also heard Atlassian are extending their project management software to enterprises working Agile, but have yet to try it out).
Keeping an eye open for these red flags could save teams time and resources, not to mention the invaluable confidence in Agile working an initial successful project could instil in them.
Ultimately it’s about finding how each team works best with one another to really get the most out of an Agile project - these tips simply help them focus on this, and not on roadblocks.
Your email address will not be published. Required fields are marked *
Scrum Masters and Project Managers are not the sam... Read More