Everyone knows that Agile is about harnessing chaos and structuring it by way of breaking down the workload into sizeable pieces so that it can be controlled better.
Yet almost two decades after this software development approach was first formulated, it’s clear that at the most basic level, Agile is not just about structuring the process. Above all, it’s about individual and collective responsibility for the outcome. This way, Agile introduces a radical shift in management mentality that is caused by the new reality of what is expected from efficient and user-appealing software products.
Not everyone recognizes this need for a cultural change, though. This post looks at how challenging it is for organizations to embrace the Agile ethos and outlines the essential elements of a new mindset required to bring about the coveted benefits of Agile.
Last year, the Gartner Hype Cycle for Project and Portfolio Management showed that Agile is balancing at the peak of inflated expectations, which is followed by the trough of disillusionment where it will start failing to deliver. This makes the business community expect that the model will only be showing its downsides soon.
More context is provided in the PMI’s annual project management survey The Pulse of the Profession 2017. When asked about the reasons to go Agile at their organizations, more than a half (51%) of the surveyed PMs and senior executives named the leadership mandate. This can be the evidence that agility is frequently imposed in a top-down fashion, while the Agile philosophy is most effective when it stems bottom-up.
To understand why Agile adopters’ expectations don’t stand reality checks, let’s recall the prerequisites behind the Agile model in the first place.
Considering all of the above, Agile gets frequently misunderstood by its budding adopters. As a result, managers start expecting miracles that just don’t happen by themselves. To see why this approach is simply ineffective, it’s worth going back and looking at some of the original Agile principles.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
This is a reversed order of how teams are usually assigned to projects. A team is the front and center of the Agile universe. Therefore, projects need to be chosen to fit into these small ecosystems of knowledge workers who’ve been rubbing shoulders for some time and have learned all the tricks of cooperation with each other.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
When going through Agile transformation, those behind it need to let go of some traditional managerial control. This means allowing Agile teams to come at the best possible solutions through their own efforts, giving them a chance to figure everything out by themselves. In custom software development, it is the customer who gives a general direction to the work and provides requirements, but it is still the team who defines how to meet those requirements effectively.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
The last Agile principle is just about that—looking at the work done, reassess what was good and what was lame, and address the flops in the succeeding iterations. In the Agile-based project cycle, this principle finds its way into the retrospection stage that shouldn’t be ignored.
The Agile approach is disruptive, otherwise it wouldn’t meet so many contradictory opinions in the software development community. Agile calls for a cultural change that requires embracing a new approach to project management that differs from the classic one in so many ways.
Agile methodologies such as Scrum represent an important shift in thinking where the responsibility for the project moves from the manager to the team.
In the classic direct management model, a manager is the one responsible for the project. When issues arise, the manager is to blame and they often react by blaming the team, using their power in a classic carrot-and-stick fashion. This method doesn’t guarantee that the team will make any changes for the better or even understand what the issue was in the first place. The team’s motivation can simply fall down.
Using Agile helps the team to feel responsible for the results of each iteration as well as the end product in general. The manager is no longer the scapegoat in case something goes wrong, but they aren’t crowned as kings either when a project is successful. This parity between the manager and the team means it’s possible to identify those who are truly ready to take on responsibility and those who are looking for a free ride.
Agile doesn’t recognize the fixation both on date and scope, as aptly put by Agile coaches from Velocity Partners. In Agile-based products, you either fix the date and do with the floating scope, or fix the scope with only an approximate deadline that is likely to shift. Companies that have difficulties putting up with these scenarios are likely to fail at Agile adoption.
The alternative suggested by Agile professionals is to fixate on the solution itself and prioritize its workability as the major criteria for measuring your project completeness.
Agile thrives on intra-team communication, preferably the one happening face-to-face or via video conferencing. Effective Agile frameworks support a combination of communication modes, both formal and informal, and tools to enable them. Co-location in the same space also gets critical for igniting ad hoc discussions not tied down to meeting slots only. Such an ongoing exchange of ideas and opinions is helpful for teams’ self-organization.
Inevitably, Agile calls for restructuring—breaking down of workforce into smaller teams with more decentralization allowed. One important requirement is that such teams should be cross-functional and include multi-disciplinary professionals—especially at the cross-section of development and testing. Companies that understand this need for a change to their structure and governance have higher chances of reaping the benefits of Agile.
ING Netherlands is one of such organizations. This Dutch banking group has seen a success with its Agile transformation started in 2015. One of the key transformational aspects for them was to reorganize their teams into 350 “squads” made of nine people that are sufficient from both the management and business perspectives. Speaking of visible payoffs, they were able to cut their time to market, make employees more engaged, and increase their productivity.
For ING, the impetus for that Agile transformation was in the changing customer behavior. Operating in the financial services market, they felt the pressure from more flexible fintech startups ready to incorporate consumers’ fluctuating needs in their products much faster. Introducing agility to their internal processes was the answer, and it proved to work well, not in the least because they were able to rethink their entire organizational culture and not to limit their transformation to superficial changes.
When done right, Agile transformation is set to bring tremendous benefits, including:
To avoid the pitfalls of Agile adoption, it’s good to remember a simple maxim: ultimately, Agile is not about documenting the process or breaking it down into scalable parts. It’s about changing the organizational mentality and making people motivated to get real results, which brings the best out of everyone in the end.