Challenges in Agile Projects

Do we have problems in Agile projects?

The other day in casual discussion with my friend, the discussion moved towards Agile and how it has changed the way we execute (not "plan") projects, and how the success rate has changed or not changed.

It intrigued me as now days no one talks about Waterfall anymore.

Then the discussion moved towards success rate with Agile vis-a-vis with Waterfall. We all know that Agile is not the panacea, just the way Waterfall was not. We still have challenges, failures, escalations, burnouts, unhappy customers...This compelled me to search the net for some statistics and content on Agile projects success / failure.

Since, I have also been associated with Agile since 2010 and have executed / managed (some people might object to this word) many projects of various sizes across various technologies, geographies and industries, I also have gathered my experiences and reasons for the challenges; however, that I will discuss in subsequent parts, where I conclude the current discussion with my experiences.

So, the first result in search was "...Agile development projects have a 268% higher failure rate than projects that don't use any methodology...". Then yet another study claimed that Agile projects are 28% more successful than traditional projects. I am sure if you search more you will come across even more claims, counter claims, and "sensational" statistics.

I say sensational, because 268% higher failure rate for following a methodology, vis-a-vis not following any methodology is a little hard to digest. As we don't know, if the sample size was big enough, if the sample was not biased and it was a true representation of population in terms of Industry, Geography, Size, Technology, Customer / Team experience and maturity, 268% being the median or something else etc. The point is, it is 268%, which sensationalized the study and hence more eyeballs. Had it been 26%, no one would have noticed. Just the way you have another claim, pegging Agile being more successful 28% of the time. Again, we don't have the measured parameters for even this study.

Another part which I find a little interesting is the "comparison". That is, if I claim 268% increased failure rate for Agile vs No methodology, then did I execute the same project across compared methodologies? Who defines same / similar projects? What was the criteria used? In absence of all these details, it is difficult to take the claim on its face value.

In fact, I also came across a detailed argument (against 268% claim) by John Ferrier in his article, "Agile Failure – What Drives “268% Higher Failure Rates?”, which is worth reading.

As I have mentioned Agile is not a Panacea, and Waterfall was not a villain either. It all depends on "applicability" and "maturity". Both are quite loaded terms, as they encompass a lot many factors.

Key Point

What I meant by that was the fact that the selection of methodology and customization / tweaking of that depends on these two factors. For example, if the scope is limited and requirements are well defined there is no harm in going with waterfall. If required, break down the development cycle into iterations and let each iteration be production ready. Who can say no to that? Similarly, if you are following Agile-Scrum, but you want to adopt some features / best practices of Kanban, Lean, Six-Sigma or any combination of those, what is the harm, if it improves the effectiveness of the team / project / program?

Core Idea

Remember, methodologies, frameworks, methods, tools, practices etc. are meant to facilitate our work, to enable us to do the work on hand effectively. Hence, are only the means to achieve something and are not the objective or outcome in themselves.?

Therefore, ask the question, what fits better to achieve the outcomes? What customizations that I need to make to align it to my work on hand? How can I further improve it? So, don't debate and make fuss about whether it being a part of the methodology or not, of which one is better. Rather, concentrate on the outcomes.

For example, many times I have combined ADKAR and Kotter's 8 principles for effective change management. Similarly, I have tweaked Agile-Scrum to suit my team's capabilities for effective outcomes. I have also applied Lean principles in Agile-Scrum planning and executions. You decide what works best in the interest of the project / program, such that achieved outcomes align well with the project / program objectives. It provides required visibility to all stakeholders / personas.

As for "Maturity", you asses the maturity of the team as well as the customer. The reason being the compatibility check must be wholistic. Team's technical skills, availability, experience in similar projects, knowledge of domain, skills in execution and customization of methodology, tools, techniques to suit work on hand, ability to assess and evaluate risks...etc., determine the maturity of the team and hence the customizations that you must make. For example, if an organization has just started a journey of Agile execution, then you can't expect them to operate at optimum level from day one, or for that matter in next six months. It would take time.

Similarly, if a customer has just heard of Agile, but is not aware of its responsibilities, can't devote time for the project / program, expects Fixed Fee with the open scope, does not understand that the success of the project / program is dependent on their participation, do not understand the periodic assessment...etc., and vendor is also not ready to broach the topic with the customer, as they fear "poor customer experience" or "escalation", then no matter what you do, it will result in failure, be it cost, outcome, customer experience, internal metrics or anything else.

Therefore, "Applicability" and "Maturity" matters in any execution methodology. We can't replace those or ignore those, just because we are executing in Agile. In fact, with Agile the responsibilities and complexities increase, as things are being progressively defined and completed, where subsequent requirements may create a significant change in what has already been accomplished. Which may result in delay of intermediate and/or final milestones.

Please note that projects don't fail because of "visibility" or "informed decisions" rather because of withholding information and poor decisions. For example, in one of the projects it started with client-side processing because of "offline" requirement; however, at a later stage it got converted into "online" mode. The team continued with "patched" architecture and completed work. Result? Broken application with numerous issues on functional and non-functional aspects, all in the name of "completing" a project without escalation. But it got escalated anyways.

Why do projects fail

1. There is no such thing as "The Cost", there is always "A Cost" – A?Finance person, Project Manager, Customer, Society all will have a different take on a cost of a project, yet all are correct in their calculations, as the objectives differ. Therefore, be it Agile, Waterfall or any other methodology of your choice, we can't deny that everyone wants clarity and transparency from their perspectives. So, even though in Agile one usually can't make projections beyond couple of sprints because of moving parts, but you can't deny the need for projections on Cost, Effort, Time and Quality perspective, as no project has unlimited resources.

We can't say, ‘that is how Agile works’. As that logic usually doesn't work beyond realms of project development and QA teams.

The stakeholders need clarity. No one is holding the other at gunpoint to cast those projections or "informed visibility" in stone. It is just that they want to understand if they need to make any course corrections.

Isn't this the whole premise behind Agile, "fail fast"? As the late discovery of problems / issues or not so pleasant news will only complicate things and increase the cost of correction. So, why not share / reveal those early, such that we reduce those costs? Please remember the costs are not limited to monetary aspects, but those could extend to missed opportunity, missed timelines / critical events, prestige etc.?

There are ways to have “informed visibility”.

In a way I can restate the need for “informed visibility” as,

·?????? What is the current size of the work?

·?????? How many more sprints are required to complete the remaining work?

·?????? What effort and cost are required to complete the remaining work?

·?????? What is the probable scope that can be completed in the remaining sprints?

What if, I say there are ways to do that without making any extra data collection, additional time and effort investment by any of the team members, and yet have reasonable clarity on these questions? It is remarkably simple and the ML models and tool that I developed can provide the "informed visibility" at a reasonable accuracy (>93%). My two (2) patents are pending in this regard.

So, next time when you think of a team, make it inclusive, make the customer a part of it, and think from their perspective too.

1. Agile execution must be complemented with Agile planning – 'No planning' is not an answer. I understand the need for individual interactions, however, if you were to scale your operations to meet the project / program needs, then you don't have a choice but to set certain ground rules, guidelines and guardrails such that there is a consistency and predictability in what we do. Don't call those "Processes" or "Tools", if that is what triggers you. Otherwise, how do you plan to achieve it?

So, have the bare minimum, as it will help you and the team in maintaining the sanity. As planning does not mean "Heavy Documentation", similarly heavy documentation does not mean "Planning" either.

1. Don't be a slave of a methodology, tweak it, mesh it, if it provides better results – Remember client is not paying you to follow a methodology, rather it is for the outcomes. Therefore, carve out your project / program journey, as what worked for others, might not work for you, and vice-versa. For a simple reason, each customer, each project, and each team (hopefully) are different, and hence, the nuances.

If it works for you to have a separate QA team, have a lagging or less automation, have specialized workforce for front, middle and back tier...so be it. As you need to assess "What Works" in current context of a project / program, and not what another team did or what Agile manifesto says. So, focus on outcomes and then define the means, and don't try to define outcomes through means.

If you look at honestly, we spend too much time following the Agile-Scrum ceremonies, whether there is a need for it or not.

1. Automation, operationalization, security, performance, compliance can't be an afterthought – Call it DevOps, DevSecOps, DevTestOps, DataOps, AIOps or anything else, terminology doesn't matter, it is the action and outcome that matters. Most of the time these "functions" cool their heels in a Technical Backlog. Which will get prioritized, "When we have a breather". Sounds familiar? Though, internally we all know the consequences, but because of various pressures, priorities get ill defined.

That is why Clarity and Transparency from all stakeholder's perspective is paramount. What are the chances that customer will say "No" to prioritize the technical backlog items, if they are informed of the consequences / repercussions?

1. Follow the basics / fundamentals, everything shall fall in place – There is an old couplet from Rahim, "????? ???? ????? ?? ??? ? ?????? ????, ???? ??? ??? ??? ??? ??? ??????". In the current context let's focus on the second part. What it literally means is that "A sword can't be used in place of a needle". So, in a situation where a simple regression works and provide better results, don't run after SVM, Neural Networks and unnecessarily complicate things, just because someone feels that regression is not "Cool".

Similarly, there is no?point in following a methodology to the T, if it is proving to be counterproductive. It holds true for all other tasks and activities too.

1. Believe in simplicity – First articulate the problem, and then think of possible options / potential solutions. Instead of force fitting your solution to a problem, just because it sounds jazzy or is the craze. You know what I mean.

Believe it or not many projects get into trouble because of this mindset.

It may be out of fad; however, it is still the most effective and efficient way of accomplishing things, i.e., KISS. As an added benefit, with visibility.

1. Don't get entangled in terms and/or gimmicks, carve out your own path – Do not confine your retrospectives to concluded sprints, but seek opinions, feedback, suggestions and solutions on piling defects, and technical backlog, disturbing development trends, or anything that is hampering outcomes. How many times honestly, we do that? Aren't our retrospectives just another "Agile" ceremony? How many times have we tracked points to closure, effectively measured the benefits of those implementations...?

This is just one example, how many more could you find in your journey?

1. Does your client interact with the team regularly – It is imperative that client interacts with the actual project team on a regular basis, instead of confining those to select few in management. If it is not happening, somewhere someone is operating in dark.

1. Changes are welcome, but those are not free – Every change eats into available resources. Therefore, understand that the flexibility comes at a price. For example, suppose a painter gives an estimate of five (5) days to paint a three (3) bedrooms house. The material is provided by the house owner. Now, the painter starts with a Living Room; however, at the end of the day one, owner is not satisfied with the color, so the painter agrees to change it as per new specifications. Suppose it keep happening on all five days.

What has happened? We utilized all available resources in incorporating changes or in a way Glod Plating, but the work did not move an inch.

If it is happening in your project, it is your duty to make it visible to all stakeholders. As only then can the decision makers make an informed decision.

As it is your duty to make your concessions explicit in a negotiation, similarly, it is your duty to provide visibility to all impediments / risks to your collective stakeholders. As only then can informed decisions be made, and hence less of a heartburn and escalations.

?