Over the past decade, there has been a significant uptake in Agile enablement initiatives across many industries, ranging from finance and insurance to IT and telecom. There are many different rationales presented to justify this increasing trend towards the adoption of Agile tools and methodologies, but one of the most compelling argument is ‘effective management of knowledge workers’. The hypothesis here is that Agile mindset (and associated methodologies) are better equipped to manage knowledge workers who possess unique skills and knowledge, and thus need to be given increased autonomy and decision-making authority. The proponents argue that the success of initiatives (that are prone to frequent changes and require specialized yet creative skillset) is heavily dependent on knowledge workers. For example, the development of a new product with evolving specifications. This is unlike a routine initiative with predictable outcomes such as a project to install Windows on 100 desktop computers.
Fortunately, there is plenty of research to back up and justify the move towards Agile methodologies. As per the 2015 CHAOS Report published by the Standish Group, Agile projects were found to be more successful (for all sizes of projects), compared to Waterfall based on the study of 50,000 projects around the world. Refer to Table 1 for additional details.
Consideration 1: Nature Of Work
What is the nature of work, to be potentially handled using Agile? Why?
It is important to use the right tool for the job to get optimal results. While you could forcibly apply Agile to almost any project, it is designed to manage certain types of initiatives more effectively and efficiently. The initiatives that are best suited to Agile exhibit key characteristics, such as, frequent changes, unclear requirements, creative thinking, and evolving solution among others. Similarly, initiatives that are more predictable in nature, with little to no change and well-defined requirements could be best handled using more traditional approaches such as Waterfall.
It could be disastrous to implement Agile without evaluating the nature of work to be managed. For example, one organization decided to use Agile across every project; this led to a spike in delivery challenges on infrastructure projects as Agile introduced overhead on somewhat repetitive and stable initiatives. In this case, Agile hindered the flow of work by introducing an unnecessary approach change, and thus caused slowdown and churn.
It is also critical to understand the motivation for moving towards Agile; other organizations using Agile methodologies is not a good enough motivation for transforming your own organization. Neither is a mere review of impressive success statistics for Agile projects. Every organization is unique, with its own specific needs and challenges; you must understand how (and if) Agile transformation would help your organization improve its customer experience, quality, rate of delivery, and/or productivity.
Consideration 2: Organizational Risk Tolerance
What is the tolerance for risk in the organization? Will the organization be able to absorb changes (to work, and overall management approach) readily?
Some organizations (and industries) are inherently less tolerant to risk due to the nature of their work, and the laws and regulations that they need to abide by. There may be increased challenges within such organizations when it comes to Agile adoption. For example, public sector organizations may need to adhere to specific regulations requiring more comprehensive documentation, record keeping, and approval practices than are needed under a typical Agile deployment. These additional conditions could impact an organization’s responsiveness to changing environment and requirements, thus limiting the efficacy of Agile methodologies. However, this does not automatically disqualify Agile as a suitable delivery vehicle for your organization. This is simply a consideration that any change agent should account for, and plan accordingly for a successful deployment. This is a good time to determine what is absolutely required for your organization to comply with laws and regulations, and how you could tailor your Agile implementation without losing the desired benefits. In some cases, you may come back with the answer that Agile is just not right for the environment; in other cases, you will find a tailored implementation that simply WORKS for your organization.
Consideration 3: Attitude towards Failure
How tolerant is the organization towards failure? Does the organization have the patience and willingness to accept small failures to get to the big win?
As discussed in a previous blog post, 3 Common Challenges with Agile Transformations, many organizations take up Agile upon experiencing some sort of a delivery disaster, such as a failed project, with the assumption that the current delivery practice (typically waterfall) doesn’t work anymore. Unfortunately, by this time, organizations are typically in a rush to fix delivery issues immediately to avoid further loss, with little to no patience for failure. Unfortunately, this is not a great starting point for an Agile rollout. There are two key problems; 1) the organization is about to experiment with a methodology that it has never used before, and there will likely be several hiccups along the way (due to learning curve), and 2) the whole premise behind the Agile mindset is ‘fail fast, learn fast’ so there will be several small failures along the way that will help inform adaptive planning for improved product delivery and customer experience.
It is fair to say that Agile is not good for an organization that is uncomfortable with failure or lacks patience as the team gears up to deliver using an Agile methodology. For example, the velocity (i.e., rate of delivery) on Agile-Scrum project tends to vary significantly in the first few iterations; this usually causes anxiety (and sometimes preemptive strike against Agile) among management teams that have a low tolerance for failure.
Therefore, it is important to identify at the onset of an Agile transformation if the management is (or can be persuaded to become) tolerant to small failures with an eye on the big picture.
Consideration 4: Organizational Culture
Does the organizational culture align with the Agile mindset? If not, is there commitment, support and understanding to evolve the culture for a successful Agile deployment?
Agile mindset is heavily people-centric, and thus, provides lots of autonomy and consideration to specific preferences of the team members. Therefore, an Agile implementation can’t be simply completed by training team members on the new methodology and having them execute on it; there is a cultural change involved to inspire team members to collaborate, get involved, and take initiative. Most organizations undergoing Agile transformation will typically need to start with evolving the culture to nurture a collaborative and supportive work environment where team members can autonomously take initiative, and managers feel comfortable in delegating authority down to team members.
All of this starts at the very beginning as you begin to discuss the viability of implementing Agile in your organization. It is critical to involve team members in this process and deploy the new methodology only after building awareness of the problem, assessing appetite for change, and obtaining organizational buy-in (above and beyond executive mandate). Without doing so, you are essentially pushing a change on to people which they will likely resent from the beginning, regardless of whether it helps them or not.
This consideration helps you assess whether the organization is simply interested in training people on a new methodology, or truly adopting an Agile mindset to help guide delivery. The response to this is also a key predictor of success (or failure) for Agile implementation.
Final Thought
Last but not the least, do not simply discount your existing delivery practices to move towards something popular and shiny. If your current practices work, deliver results, and are scalable, you are right where you need to be …
