Why’s Agile so misconstrued

Agile methodology implementation, especially in the IT industry, heralded a complete new direction for software development discipline and was a totally fresh whiff of air from the laborious, rigid and monotony of waterfall methodology. It brought a sense of new direction, purpose and promised an salvation from the drudgery of waterfall mode of delivery for the IT developers, management and the industry as a whole. That the industry was moving to digitisation at a breakneck speed, and therefore, Agile could not have arrived at a better scene than ever.

The merits of Agile and the value it has helped to deliver is well documented. From behemoths like Google and Microsoft, to companies like Spotify and Panera bread, the results have been outstanding. The pace with which some of these organisations changed their IT paradigm with help of Agile methodology and its associated frameworks, is truly jaw dropping and awe inspiring.

However, this begs the question, that while it might have helped organisations transcend their IT Business landscapes and acquire new business persona, but at a human level, has it brought any merit or ease of work? That is with reference to the developers, managers or, if I may say, the entire IT related human resources, how actually is it received and perceived.

Do people and human capital, truly envision Agile as a saviour and messiah in transforming their work culture and help them better their work life and their deliverables. Or is it still considered as another of those laborious methodologies that start with great promises and vistas and slowly transforms themselves in the ghetto where one has no choice but to toil and burn themselves out.

With that in mind, I embarked in understanding the pulse and feel of Agile with IT workforce from various industrial verticals.

And, it pains to me to say, that the perception or the outlook is quite pessimistic and forlorn. Some of the most common refrains that we hear are:

• Agile is all about continuous meetings and calls.
• Agile doesn’t provides any break and the teams are constantly challenged at hectic pace.
• Scrum masters are considered to be only setting up calls and meetings and have no other purpose or role; They are rarely seen as the solution provider or facilitators.
• There is never ending, incessant pressure to reduce TTB and TTV.
• There is no change in leadership styles. The focus is still remains as “I tell and you do” vs true Agile culture of servant leadership and delegation.
• Agile is just a renaming of the roles of waterfall model, aka, old wine in a new shiny bottle.
• Retrospections have become battle grounds and for pinning blames vs true learning.
• Agile teams tends to be Jack of all trades and masters of none; that is as the testing roles are eliminated and the developers are now forced to be testers to test the product
• Time boxing concept is just a concept.
• There is no true estimation techniques adopted. Delivery dates are fixed on the whims and fancies of either business stakeholders or the tech teams.

The above mentioned perceptions and problems are widely classified and these might apply or not apply to different industries & sector. However, one thing is indeed confirmed that at least a couple of topics ails one company or another, at one stage or other.

The true purpose of any idea and process, and as per work and humane ethics, is, while it adds to some material benefits, it should also ease the life of the workforce. Unless, that happens, the said application or the process or methodology can be considered to be have barely met its mission.

Overcoming the AGILE challenges:

The start point, as always, should be “cultural shift”. This is akin to a tectonic change for any organisation and unless that is managed properly, with empathy and with a deep sense of purpose, the outcome will always be mediocre at best.

The leaders, in all aspects, should be trained and should be required to practice the ethos of Agile at all fronts. While most of the onus will be on the tech delivery teams, it should equally be supported by different departments of any given organisation. Unless this is achieved, the adoption of Agile will be viewed as tedious and haphazard.

Leaders should be encouraged and incentivised to boldly adopt Servant leadership culture. And this is should be demonstrated top down than vice versa. Approachability to senior leadership should be simplified. Org goals and strategies should be transparent.These steps will help reinforce the image and culture of Agile.

Now comes the most disliked topic, that is, meetings. Meetings and team gatherings are essential and critical for work progress. However, an overdose of the same, will make the org lethargic and people will become disillusioned pretty quickly. Instead, ensure that work adheres to bare minimum of team gatherings.

Standup call happens to carry the biggest onus and are the most misused Agile step. While the purpose, as stated in its name, a stand up call is indeed supposed to be a truly stand up call, wherein everything is addressed quickly and diligently. However, in reality, the stand up calls stretch out to hours together. One direct intervention that can shorten stand up duration is the team size. The smaller the team, the less time they need to cover their topics. Agile advises a team size of 5 to 7 resources, however, in reality, the team size extends to 11 and beyond. This is a core area, which, when handedly properly can yield better and faster results like none other.

Then comes the vexing point of TTB and TTV. The business and the IT leadership teams tend to use this point to the hilt and thereby causing huge burnouts to the teams. Resources feel that they are constantly pushed and goaded with no lee way of time. Both TTB and TTV, are a natural progression of Agile methods and benefits are accrued in similar fashion. Treating this as a core productive metric is totally unproductive. Strong emphasis solely on achieving the results defeats the Agile purpose. The development teams should be allowed to grow organically and given the freedom to learn and develop. As the teams start their journey, the critical metrics of TTB and TTV will indeed start shortening and come to the desired range. Self restraint is the key and virtue to any organisation.

Development team, Product owner and Scrum master should be allowed freely to judge and arrive at work estimation. The scientific methods of estimation should be followed as is and dev teams should have a complete fair and balanced assessment. No matter how tempting it could be, it is very essential that business or for that matter even IT leadership, should and must refrain from setting up deadlines for dev teams. Correct work estimation allows good distribution of work load and no one resource will feel overburdened and over taxed with tough complex work.

While most of the organisations have accepted Agile as their choice and started their transformation journey from waterfall to Agile, and rebranding their existing staff and team to Agile world, its very pertinent that the existing teams are coached and the work culture is influenced with the positivities of the Agile. One should impress that its not a simple nomenclature or role name change but the adhering culture to it is also changed to Agile. This is very crucial in establishing the teams on a strong agile foundation. If the teams are not convinced on this aspect, all efforts will lay in vain and resources will continue to work with waterfall culture in the new agile environment.

Scrum ceremonies such as retrospective sessions are another one of the step of Agile that is very poorly understood and implemented. While in essence, any retrospection call should be focussed on what went well or what did not, however, this has become more of an exception than a norm. Retrospective sessions are reduced to blame game, witch hunt and with good amount of mud slinging and finger pointing. This is an aspect that Scrum masters and IT leadership team should lend serious focus and take immediate remedial measures to address and correct the situation. Otherwise, even after multiple iterations and cycles, the value expected out of the scrum ceremonies will hardly be delivered.

All in all, while Agile does hold a plethora of solutions and value additions for organisations and workforce, unless, the cultural change is heralded at all levels and junctures, the true benefits and potential will be out of reach. While all the issues can’t be tackled at one go, there should be an sincere effort to tackle the problems at the root level and refrain from making superficial changes.

Only then, an organisation can truly call itself “Agile” and reap the true advantages and values in its business and IT functions.