The Agile Manifesto was formulated 17 years ago and still doesn’t lose its relevance. A management approach that was initially used for software development, is getting adopted in different fields and industries with ever-growing confidence.
The benefits of transforming the organisation into agile are tempting but aren’t so easy to achieve. Let’s take a look at what organisational agility has at stake and, more importantly, what might be standing on your way there.
Why go agile?
According to the survey conducted by CollabNet in 2018 companies adopt agile in order to enhance delivery predictability (46% of respondents), achieve better software quality (46%), improve business/IT alignment (49%), increase productivity (55%), enhance the ability to manage changing priorities (64%), accelerate software delivery (75%).
And these expectations are rather grounded. Numerous studies prove the positive influence of the agile organisational structure on how companies meet their goals, deadlines, and budgets.
The Project Management Institute’s research shows that organizations with high agility meet business goals 19% more likely than those with low agility. Moreover, the former finish projects on time 65% of the time, versus 40% for the latter.
Another research conducted by QSM Associates assessed the performance of agile development projects against plan-based or waterfall ones. It states that agile teams were on average 37% faster delivering their software to market and 16% more productive.
It’s worthwhile noting that these improvements were possible despite agile teams being large and geographically dispersed. Indeed, if managed correctly, agile teams can stay effective despite the distance (we wrote about it in one of our previous blog posts).
Looking at all this data, no wonder why so many companies turn to agility. However, achieving agility isn’t that easy. We see this as a constant challenge among our clients and want to share some of the most common bottlenecks that are holding businesses back from the desired success.
Common mistakes and how to avoid them
Doing agile right is not a cosmetic fix, but something that companies need to invest time and resources to. It takes dedication, patience and a commitment from all stakeholders involved in the project.
The following behaviours, as innocent and minor as they might look, harm agile processes and might keep you away from the desired results:
1. There is no single point of contact on the business side available for developers
Usually, when you delegate a certain task, you explain what needs to be done, and then expect it to be ready at the agreed date. Which is logical… for such services as a shoe repair, but not software development.
Software development, in its nature, is closer to prosthetic leg making than a shoe repair. To address all patient’s needs and concerns and create a prosthesis that works and fits, there should be constant communication between a patient and a prosthetist.
Likewise, regular and effective communication between developers and key project stakeholders is crucial for crafting a solution in line with business needs. Being available for developers’ questions on a daily basis (here is where the daily ritual comes from) is a necessary measure unless you want to block the team’s progress by making them wait for your reply.
We always recommend that, besides, there is a single point of contact for developers from the business side – one person who helps to get the necessary information from other stakeholders. This helps to coordinate the knowledge flow more effectively, as well as establish a unified business position instead of providing opinions that may vary.
2. No acceptance criteria set up in the beginning
The best way not to get a pig in a poke is to set up detailed expectations (acceptance criteria or the definition of done) in the beginning. This way everyone gets a common understanding about what needs to be done, its quality and completeness. Moreover, having clear expectations in mind let developers know when the task is completed, instead of drowning in a whirlpool of never-ending makeovers for vaguely described expectations.
In practice, it often happens that the business doesn’t have clear expectations and let developers decide on how a required feature should exactly work or look like. Keep in mind, that this delegation rarely works out as it was planned, and ends up with hundreds of questions and suggestions coming post-factum, which negatively influence the project’s performance.
3. Providing a set of tasks, not a user story
There is an essential difference between a user story and a task. The former makes a development team think about how to deliver the best possible solution for a provided scenario. Such a complex approach helps programmers spot issues and opportunities that would stay otherwise hidden if they are asked to code this or design that.
Moreover, user stories help programmers see the whole picture and potential impact of their work so that they start being more involved and enthusiastic about what they do.
Hope you find this advice useful and manage to achieve flawless cooperation with agile.
