The challenges of the Agile team within the traditionally-managed and hierarchically structured organization are discussed extensively in research. Artefacts of the burgeoning, hierarchical organisation such as company policy (“we don’t do it that way here”), imposition of arbitrary and incompatible standards, command-control management and poor project manager integration all contribute to inhibiting Agile operationalisation (1, 2, 3).
Alongside this research, I have come across some of these challenges, along with a few others surrounding the personal nature of the team. As a new member of a team, and having been indoctrinated by a fine Scrum trainer, it would be easy for me to lose friends and disenfranchise people had I preached to my new team about how they were doing it wrong and how Scrum would fix all.
But this is not about rehashing problems. Instead, I’ve compiled some lessons which may help others.
In introducing these, I could conclude right now with … Take it slowly
Understand why the team do what they do
It would be ignorant and offensive to assume that archaic processes continued to be followed due to lack of awareness or skill. There is likely to be a valid reason for filling out release forms, why users don’t get engaged or solutions are dictated before the problem is understood. Taking some time to observe and understand through casual discussion is ideal for encouraging titbits of information to be revealed which could explain the history of internal practices and procedures. Perhaps the reason is long forgotten or no longer relevant. Judgement should be withheld, lest you be judged yourself.
Prepare your tools
Creating a new process is made much easier if there are tools surrounding the process that allow the team to fall into the pit of success. I’ve used JIRA in these situations, which has been a first step in formalising tasks from which a backlog may be created. As requirements come in, the task of distilling tasks into User Stories (using the spirit of the terminology if not the definition) and then sharing them out to the team without the dogma of story points, retrospectives or stand-ups has allowed a degree of task ownership and collaboration to emerge over the medium of the tool. JIRA has an API, so if the wider organisation insist on their legacy tool to be used, it can be integrated within a wider process.
Embrace, Extend …
Stopping short of the entire terminology reputedly used internally by Microsoft, I’ve found that it is the team that determines the success of Agile, not the method. Therefore, I’ve embraced the Agile dogma such as Scrum, and extended it – or rather – evolved it, according to the personal nature of the team. During forming, storming and norming, personalities within the team are explored within a professional context, allowing me to learn a lot about the individuals and their motivations. Attempting to mandate process according to Scrum-doctrine will only serve to extinguish Agile all the more quickly and perhaps professional relationships within the team.
Know the assumptions of your method
Methods such as Scrum make sweeping generalisations across industries and fail to state their assumptions. Outside of the software development company, multi-project developers who have to balance ongoing support requirements are widespread. Scrum, and the admittedly useful and revealing metrics that fall out of it, assume that 100% of the time of developers is spent on the code. It’s all about the Story Points, NUTs or even breeds of dog (“that will be 2 Labradors and a German Shephard”) but this does not take into account time spent outside of the project. At any given moment, the **** could hit the fan robbing the project of velocity which would be unaccounted for in the retrospective reports. Equally, how well does Scrum work within a portfolio? Models like SAFe claim to allow multiple projects managed using Scrum-like techniques, but this is not necessarily the same contended resources.
The key to the success that I’ve seen with this is to introduce Agile principles gently. No great switch was needed from which all projects would be Agile. Each project slowly became more Agile than the last and the surrounding individuals (managers, Business Analysts, etc.) are understood first and introduced second. The Business Analyst is perhaps your greatest chance of success of implementing Agile concepts within the hierarchical organisation so they need to be brought on-board at their own pace. I’ve learned to listen and understand first, based on which, one can start to make the case using what can be highly adaptive models that are made to fit the team, not vice-versa.
