Success or failure of Agile Implementation – Isn’t it Time to Call a Spade a Spade? – Part 2

Pradeep Narendran
Vice President
JP Morgan Chase & Company

 

 

In my previous article, I stated that a lack of in-depth understanding of Agile concepts by top leadership is one of the key factors for Agile failure. This may sound rather bold with a tone of accusation! It certainly is not my intent to make accusations or even allegations about prudent and well-intentioned leaders.

However, in my observation, many well-meaning leaders are swayed by well-packaged marketing of the benefits of Agile principles. What this army of marketing professionals present to the leadership is only this part of the story, in terms of what Agile can offer their organizations, which is :

1. Ability to deliver a product incrementally, feature by feature
2. Ability to design and deliver features of a product faster
3. Ability to see ongoing demos of product features while the product is being built
4. Ability to change functionalities of a product’s feature even before final release
5. Flexibility to make course corrections based on live customer feedback and analytics
6. Improved efficiency that includes efficient versus laborious documentation

Agile definitely has all of the above-mentioned benefits, and saying that the above list is conjured up by marketing professionals to sell the idea of Agile is a far stretch! And any leader in their right mind should consider Agile as a tool to deliver product for the many good reasons listed above.

However, either what marketing does not emphasize, or what many leaders seem to ignore in the sway of hype, is that, in order to achieve all the stated benefits of Agile, there are certain fundamental elements that must be in place in the organization that intends to pursue the Agile path. I will list a few of many in this article. If they are not already in place, there must be a concerted effort to get them in place ferociously fast, no matter how imperfect it may be!

A Conducive Culture

At the head of the list of such fundamental elements that should be in place is a culture that is conducive to open discussions by impacted teams, even discussions that question top management, even on the feasibility of Agile implementation! A culture that builds trust, and eliminates fear! A culture of empowerment and ownership in its true spirit!

I have come across many organizations where no feasibility study is done, let alone an open democratic discussion with the impacted teams! And, in organizations where they begin with a notional discussion, the moment a few team members raise concerns (often valid), they are looked upon as disgruntled or ill-informed members, and ignored, or quickly shut down!

This is a good segue to remind ourselves, that in any organization, unlike teams whose primary/sole function is development, there are many supporting teams that the developers are dependent on. In their eagerness to ride the Agile wave, leaders tend to ignore the fact that these supporting teams have primary ongoing functions that need not be tied to delivery cycles. Yes, they may have some deliverables that are time bound, and may need to provide inputs as needed. Time-bound deliverables from these teams can be tracked by some sort of sequencing method, to ensure that Agile cycles (for example: sprints in Scrum) of the development teams are not disrupted. To force any such supporting team, for instance, to follow all prescribed Agile ceremonies will only lead to a drop in morale, lead to reduced efficiencies, and a possible loss of good resources. This is in turn affects the development teams that are dependent on them.

It is not always possible to get 100% consensus from all teams, however, there must be a sincere effort to get buy-in, and earn trust. There must be openness to consider the possibility that the entire organization does not have to be an Agile shop, and yet the benefits of Agile delivery can be achieved. There must be a deliberate attempt to make every team member feel heard. There must be a willingness to listen to genuine concerns, and the magnanimity to accept reality. Teams that follow this path will see Agile success; no matter how bumpy the ride may feel! Others be warned, not all smooth rides reach the desired destination!

Cross Functional teams

The reference to cross-functional teams in the definition of Agile development is another fundamental aspect that is twisted. Yes, teams are expected to be cross functional. What that means, is simply that, all skill sets to deliver a product, need to be present/ available to a team, at all times, without dependencies that hamper the delivery cadence. Either due to genuine misinterpretation, or convenient manipulation, leaders tend to use this definition to expect every member of a team to be proficient in multiple skill sets!

It is not unfair to merge the role of a Business Analyst into a Product Owner or vice versa, since the functions overlap, although capacity concerns should be addressed before doing so. It is also not unfair to expect self-organizing teams to empower team members to perform cross functional tasks for short periods as needed. For example, a Business Analyst may be requested to create/update a link on a page while a developer is unavailable, or even as a simple routine task. Similarly, a developer may need to be requested to get requirements clarified, document it sufficiently, and communicate effectively in certain cases. However, what many organizations tend to do over time is to expect all team members to be able to code, analyze, test, and even take on dual roles of Scrum Master and dev lead! This tendency is absurd and detrimental to Agile health. In the first place, for obvious reasons, there is no concept of a dev lead in Agile.

Secondly, if that person replaces a designated Scrum Master, there is every possibility that functionality/features get displaced at the very least, defeating the Agile model of incremental and iterative development! Permanently doubling up on roles will also lead to compromise on quality. Imagine a product that is developed and tested by the same person. There is every chance that the person who developed it overlooks non-compliance in or more aspects of the product. It is only human to do so! Expecting a Quality Analyst to code as well as a developer is akin to expecting your General Physician to perform heart surgery on you, as proficiently as your Cardiologist! And yet this is implied, if not explicitly expected by leadership in some organizations. This misinterpretation/lack of understanding/ willful interpretation by management, of the definition of Agile, as it pertains to cross functional teams leads to fear, and unwanted behavior, that can lead to Agile failure.

Structure

I had called out an anomaly of the role of “Dev lead” in an earlier paragraph. In the Agile world, all team members in a delivery team, are expected to size stories1 independently, and in an unbiased manner. Similarly, the team is expected to make a collective decision on what stories to deliver in a sprint. The teams are expected to be self-organizing! The moment organizations bring in concepts from the water fall world, such as “Dev lead,” a notional control is imposed. The team is no longer self-organizing, expects to be directed, and loses its ability to size stories and voice what stories will be delivered in a sprint in a non -biased manner. There are organizations wherein the Scrum Master reports to the Dev lead! Really!! And in others where the Business Analyst reports to Dev lead!! For obvious reasons, this is a big no-no even in a water fall shop, let alone in an Agile shop! For those whom it is not so obvious, let me try to explain with an analogy.

Let me start with explaining the roles. In short, a Business Analyst is a representative of the business, documents their requirements, gets the business to sign off on the requirements, communicates the same to all stakeholders, including the developers, and testers. During, and after the development cycle, the Business Analyst helps determine if a reported defect is valid, or if it is a gap in requirement, or a change request. In the Agile world, depending on the size and complexity of an organization, this role is either retained as an extension of the Product Owner Role, is a variation of the same, or just renamed as Product Owner. Now, imagine you are the Business Analyst, and you are reporting to the person leading developers. This is akin to you being the representative of a house owner, who reports to the manager of the general contracting firm you hired to get your house owner’s property painted!

It is also very important that the delivery teams have dedicated resources from other supporting teams that impact their delivery. For example, if a feature of the product entails the user to input a one-time password, a dedicated resource from the authentication team or security team should be available to the delivery team at all times as needed. While this resource need not necessarily attend daily stand ups regularly, this resource must be available upon request, fully understand the requirements, be cognizant of the delivery cadence, have an assigned task on the story being delivered, and work in step with the delivery team to meet timelines. This can be achieved by structural alignment, and strict adherence to sequencing schedules. If the delivery teams and supporting teams consistently have varying timelines, Agile health is compromised.

If we plan on going Agile, let’s embark on a true Agile journey, starting with an honest feasibility study. Let us allow open discussions, and genuinely hear all viewpoints. Let us accept that there is no need to go with a “One Size Fits All” approach! Let us restructure with a purpose, and let us begin at the top 😊

Stories¹– A story is a granular documentation of functional requirement(s) of a feature that is expected to be delivered in a delivery cadence. It includes Scenarios, Acceptance criteria, Wireframes, and other relevant information that is needed for every team member that is impacted, including those from supporting teams.

Please note: The above are my personal views and not the views of my employer. The terminologies used in the article (for example; “Sprint”) are mainly from Scrum, but may be substituted with other Agile terms.

As an entrepreneur, Pradeep pioneered indigenous manufacturing of intricate machinery and turnkey plants in the confectionery and chemical industry. He also spearheaded the automation of inventory management for Dubai’s leading plastic manufacturer. In his U.S. career, he developed feasibility studies as an M&A team member in the energy sector, and organized and guided Agile teams across various federal government agencies. As an Agile thought leader and public speaker, he enjoys sharing his views and experiences culled from a broad spectrum of industries.