The fallacies of Agile

Originally Published April 23, 2018

 

Introduction to Agile and what it means!

 Agile means many things to many people. Commonly, Agile is referred to by many as the Holy Grail of software development. Something of the nature of a one size fits all approach. This approach is over-simplification at best, and while this may be fine for short-term, contracting type projects, where the front end interface is more important than back end capabilities, longer term projects which require significant investment in to architecture design and solution building can never find much benefit in the Agile approach.

Image Credit: Wikimedia

 

Most experienced developers and software firms find Agile more suited to work where the customer is external to an organization, where customer is willing to run the show and where the customer can and do change their mind all the time. The projects run are either consulting type or short term feature driven projects. As such, Agile works best when -:

• Focus is to satisfy customer through early and frequent delivery of software, whether actually valuable or not
• Developers and business-leaders are capable and willing to work together daily throughout the project
• Most effective communication channel to pass on information to and within development team is face to face conversations
• Development team welcomes change in customer’s mindset and changing requirements, even late in development cycle.
• Delivery of working software frequently is a key requirement, ranging from couple of weeks to couple of months
• Customer’s long term strategy is not known and short term strategy and goals take precedence

 

Image Credit: Interact Internet Blog

 

Where Agile is not recommended

When the group of like-minded software professionals first met in Utah in 2001, they met with one goal – to make the gap between software development and users short. The ultimate goal was not Agile, but was to quickly build-working software and put it in to the hands of the users fast. This fast delivery would produce two benefits – first, the users will have access to beneficial features quickly even while the ’big picture’ end product is still on the whiteboard, and Second, the team will be able to get valuable end user feedback on features that can help course-corrections to determine the software’s scope and direction.

The above approach bodes well meaning outcomes, regardless whether the outcomes are meaningful or not. This approach is not at all suited to software which has a very simple interface with tons of hidden, intricate features, design elements and functionalities as well as integration layers and internal complexity. Or the software front end itself may be simple, however the software isn’t useful until all its complex sub-components are written and its fairly complete which may take a long time. This type of software development takes significant design time upfront where no development is meaningful or even possible. As the projects have significant internal complexity, much of the work is not even visible to customers, save the few technically minded end-users, hence there is no way to write customer stories or use cases used to estimate development time. These type of projects typically take 6 – 24 months to deliver the first working version to the customer. Mind you, that’s the first working version, not the final product.

Most simply put, Agile development is not a well-written specification, followed by flawless execution, but rather, its about the continuous loop between business and its potential customers. Developers are just there to keep the loop closed.

From Tax-accounting software, to complex games, to telecom solutions, these type of software are just not suited to be given to end customers when partially finished. The concept of ‘Done’ and frequent releases or iterative development just does not cut it.

As one of the signatories to the Agile Manifesto, Dave Thomas, said, “There is no such thing as Agile.” It is an adjective, not a noun. The noun was created by other people who had something to market. The original intent was a feeling that people should be emphasized over processes, but out of that grew the ridiculous jargon of scrums, epics, stories, chickens and pigs, sprints, etc. It was a good idea, but only a rough idea. As Dave Thomas said, the consultants who had something to sell got a hold of it.

Image Credit: Internet

 

Just to be clear, there are good, almost great concepts in Agile methodologies, but they have to be customized and applied with wisdom. What we have now is a cult. A cult oversold by sometimes enthusiastic, over-the-top consultants. A cult adapted by many without thought, something akin to a magic pill.  And when anything is adapted as a cult, there could hardly be a good ending.

In many cases, experts point out that multiple startup companies, smaller organisations, even smaller teams in large corporations were already ‘Agile’ before the invention of the term ‘Agile’.

Books have been written on shortcomings of Agile, and this post is not about those. A simple web search would yield more articles about shortcomings of Agile than one could cover in reading spanning multiple days. The purpose of this post is to showcase some of the fallacies of Agile and why these persist despite some of the best intentions to get rid of those.

 

Image Credit: Internet

 

The fallacies of Agile

Over the past 18 or so years, agile methods and branding have significantly transformed the software development landscape, moving steadily from margin to mainstream software development realm. Most agile practitioners attribute the growing influence of agile methods to their effectiveness, but enthusiasts’ beliefs about agile methods and practices often fall short of reality.

Image Credit: Dilbert

 

The fallacies of Agile are many and at least as varied as the number of organizations that have tried to adapt Agile in their own specific manner often without due regard to people or processes.

• One size fits all -: Agile doesn’t work for high-end research oriented development work. Period. There is no way for an organization to use Agile methods to fit innovative, high-end product development with complex back end systems’ integration work.
• Face to face communication works best -: This is such a load of unmentionable. Perhaps, face to face communication worked best in 2001 when neither Skype nor Github was there. It becomes worse with dispersed teams or team members working from home, which is new reality of todays work domains. In today’s environment, people not only find face to face communication intrusive and time consuming, but quite unnecessary. IMs, Skype, quick phone call and good old fashioned emails are preferred method of communication for people even within the same building.
• Agile has universal standards -: If anything, Lack of standards makes Agile confusing. The Agile principles are high-end principles, and most organizations tend to adapt those with their own style of working.
• Iterative development produces great working software -: Agile glorifies pointless, short sighted 2 week sprints. The focus is on smaller pieces of incremental work, with the idea that every piece of work can be broken down in to sub-components. The kind of software development where work cannot start till the time significant up-front investment is made in design and architecture doesn’t augur well with iterative, short development sprints. c
• Testing is second to writing great code -: Lack of reality checks and test of all components put together doesn’t find any relevance in Agile as the story testing ought to be enough. In most complex software developments till date, this theory is easily debunked as integrated components are known to behave in a different way than individual components.
• Self-driven teams -: Agile and Scrum estimates that all teams can be self-driven with minimal supervision and interruptions. Hence, the need of a project manager managing the more human aspects of individuals is not needed at all. In practical life, developers are people and have their fair share of problems and behavior adjustment is often critical to ensure team’s success.
• All developers are equal -: Agile makes career planning and career development useless. There is no concept of senior and junior engineers. It doesn’t distinguish between developers with 10 years of experience compared to someone with 1-year experience. All developers are treated the same, and each developer’s value lies in reducing the backlog. For developers with more than 5 years of experience, writing the same code as a beginner is increasingly difficult to digest. Agile and scrum doesn’t do justice to career aspirations as everyone is equal as a scrum team member
• Every day must produce similar results -: Scrum doesn’t bother about human idiosyncrasies or behavior or the fact that different days can produce different results. It says that each day must be equal. This expectation of mechanized standardized code output is another way of commoditization.
• Organizations need to make little changes to adapt and internalize Agile principles -: Most organizations have a wrong understanding/implementation of Agile. The big difference between Agile adaption and successful Agile adaption is the suitability to culture and the willingness to change.
• MVP approach works best -: Minimum Viable Product can produce fantastic results in small groups in incredibly short period of time, with clear cut mandate. In larger groups however this can become the perfect recipe for disaster.

 

Conclusion

 

Agile is great, but the demands of the next-gen software and application development require something greater.

 

The software development community has caught on to the Agile Manifesto and its 12 principles as the defining standards of software development movement. Today, more and more teams are motivated to self-identify as using an Agile methodology, irrespective of its suitability to the goals. While many of those teams motivated to be identified as Agile teams are likely using a hybrid model that includes elements of several agile techniques as well as conventional waterfall method, that they identify so completely with the agile movement is a testament to both the strength of the statement and the power of the movement. Strong as it may be, Agile has got numerous, serious flaws which cannot be bridged by its popularity alone. Just as Agile methodologies came in to being and gained popularity to fill in the space and demand for quick paced software project management left unfulfilled by Waterfall methods, the shortcomings of Agile methodologies will lead to something new, something far more interesting perhaps. The winds have already started to change directions, some may feel.