Agile - Myth vs. the Practical
Over the last 6 years I have successfully implemented several enterprise wide critical projects using the Agile Scrum methodology. In some cases such use has been to transform a project gone wrong and bring it back on track ( delivery time, scope, and budget), in many cases the use has been to lead, manage, and deliver the project from start to finish the project life-cycle. I have yet to see a failed project when Agile has been applied with the correct context and right degree. I have however observed several catastrophic application of misaligned and in-accurate application of 'Agile'.
There are several crucial lessons I have learnt that surround application of Agile project management. Some such lessons are based on my own personal experience and some are based on keen observations of others' use of Agile. After many years of tweaking my skills in Agile methodology and several successful project deliveries using this method, I feel I have my arms around most of this method's mythical as well as practical core attributes when it comes to implementing in a projects' life-cycle. In this post I try to share such nuggets which I believe to be effective, understand well, and practice daily.
- Not the Golden Key solution rather a Turnkey Method
Agile in itself is not the solution to any project. Using agile project management is not going to guarantee success, in fact agile is but one of many factors that determine if a project is a success or failure. Agile is a framework that provides clarity into quantity of scope to be completed, quality of talent doing the work, and the conditions that act as success or hurdles to the project. Adopting agile is not enough, it is the accuracy and proper degree of application that results in it's value to the project life-cycle. To apply Agile effectively, the project team needs to be first trained and then most crucially, be mentored to understand what aspect are applicable to the the project at hand and how to apply them. Not every aspect of agile method is applicable all the time to all projects.
- Not a Silver Bullet rather a Truth Mirror
Agile does not fix problems, but rather reveal these problems in such painful clarity that the project team and stakeholders are compelled to actually address them. When the complexities of a 1-year project are compressed down to a 1-month increment, there is no longer anywhere to hide. For example, if there is a talent problem, iteration deadlines will be missed consistently until the skills gap is addressed. If there exists a negative team culture, the work across silos will cause more pain until the team dynamics is resolved directly. If the team generates defective code or functions, there will be embarrassing customer demos until quality control practices are adopted.
- Not a Full Package Deal Rather Organizationally Contextual Rollout
Agile adoption can't be successful as a organizational rollout. This method, to the unfamiliar can be a fundamental change, as such any rollout without practical proof of contextual success can be disastrous. An increment adoption of Agile practices that make sense and that team members understand and have bought into, is definitely a better approach. For example, teams who don't buy into it, can very easily blame the process by manipulating the detail or simply incorrectly applying it. If several key projects are demonstrated to be successful in the organizational culture, then the untrained and nay sayers will sit up and take notice. Such success also provide proof of Agile's effectiveness in the organization.
- Not an Unruly Wild West Rather a Highway with Guardrails
Agile PM is not for free. Many project managers assume that agile means no planning and no documentation. Imagine their shock when they find that a standard agile framework employs no less that 4 levels of planning (daily, iteration, release, project) and a full suite of artifacts called backlogs (product, iteration, impediment, risk). Complex projects need a certain amount of coordination to be successful, and an Agile approach is one that merely seeks the right balance of the right amount of process to manage those projects.
- Not for Breading a Culture of Burnouts & Urgency Rather for a Continuous Adjusting Delivery Rate
Many agile implementers believe that agile requires an open check-book and an open calendar to delivery. On the contrary, agile is about continuously adjusting within the set boundaries of cost and time. From sprint to spring Agile allows for adjusting development load up or down based upon actual delivered software. This does not offer a free ticket to miss set deadlines but provides clarity early and in each sprint that some problems exist that is slowing down the teams delivery capacity. If the problems are merely identified and not addressed, then the risk is due to in-action not the agile method. It is imperative to teams that they strive towards reaching a plateau of velocity of work completed. Agile allows the team to track to understanding and realizing this plateau. Once realized, if such plateau is projected to be not sufficient, then the team can challenge itself to think out of the box to still deliver in time within cost. In technology development there is always room to work smarter. Needless to say the sooner in the project life-cycle such plateau is achieved the better. It is usually recommended to achieve an understanding of a constant velocity rate within 3 to 4 sprints of the project.
- Not for the Untrained but for the Easily Trained Pragmatic Kind
Anxiety will grip project managers when they learn the chosen agile frameworks does not explicitly highlight the project manager role in the traditional manners. Annoyance will come from isolated ivory tower engineers who must now attend meetings with those 'pesky' business sponsors. Protests will arise from requirements analysts who must now prepare feature specifications (user stories) every month, rather than only once per year. Change is hard. The organization must understand the dynamics of the changes about to be introduced.
In conclusion, the people factor plays the most critical role to agile's success in any environment. This people factor can manifest in areas of talent, motivation to delivering quality, and readiness to address issues head-on.
It is incumbent to the organization to understand the weaknesses of individuals and to implement a culture to fully exploit their strengths. We should be realistic about what each team member can accomplish, but not become complacent, either. We must hold the bar high, encouraging each member to reduce their weaknesses and capitalize upon their strengths.
Agile method and its tools allow project managers to tell the truth with empirical data. As it turns out, people are often not able to handle the truth, and will instead shoot the messenger. The organization and it various stakeholders must be prepared to handle the truth when it is revealed, and work diligently with the project manager and project team to address the issues in partnership and collaboration.
