Agile Industry Events Are Still Relevant and Here’s Why

22 August 2014
By Ekaterina Shalapanova, Project Manager

This morning I was discussing with colleagues the reasons behind why industry experts choose to attend or not attend Agile community events and uncovered three main positions:

  1. “Yes, I need knowledge and need to learn from other peoples’ experiences.”
  2. “No, I’m too mature to listen to obvious things.”
  3. ”No, your Agile doesn’t work at all.”

I fall into the first group, and I hope that those of my peers who recently attended Agile2014 share this same sentiment. It’s a shame I couldn’t attend this year because it’s my personal opinion that the world is too big and complicated to discard anyone else’s experiences.

The most interesting part of the discussion though focused around the last position: “No, your Agile doesn’t work at all.” In reality, this usually means “my project used an Agile approach and failed.”

My company participates in running a lot of projects, both big and small, across different countries and in different areas and technologies. I think one of the benefits of going to events like Agile2014 is the ability to briefly gather this large knowledge base in one location to facilitate conversations among colleagues about lessons learned on hard projects and the absorption of their experiences.

The Central Questions: But why did it fail?

This question is frequently asked and I’d like to share my own experiences with those who believe it makes sense. Making and sharing the results of so many retrospectives and lessons learned in a brief blog post is a special challenge, but let’s give it a go.

So, let’s start from the beginning.

From time to time this question of failure is raised by our customers and colleagues. There are a lot of those who evangelize Agile and plenty of those who are completely disappointed with this approach.

Everyone hears a lot about the benefits of Agile. We buy the idea and start a new project with this promising approach and plan to start getting those benefits immediately. And in the middle of the project we surprisingly realize that it doesn’t work for us for a variety of reasons. On one hand, the users may not be happy with what they see so far and the team may fail the iterations. On the other hand, the metrics for each of the iterations may be perfect, however, none of the use cases can be walked through. Or better yet, estimations increase dramatically after every review or perhaps none of the KPIs are being met and you get a bad feeling every time you look at the project reports…

The list of what can go wrong in a software project is actually endless and is not the purpose of this text.
What we want to discuss is “WHY?” Why would such a brilliant idea as the Agile approach fail to help in some cases?
Each failed project fails in its own way; however, we can discern some patterns:

  • Your team does not implement Agile properly
  • Your company is not ready for Agile
  • Your business (or this particular task) is not “Agile-compliant”

Failure could also be due to a combination of these root causes. These cases are valid for both in-house and offshore development. What follows is a brief discussion of each.

Your team does not implement Agile properly

First of all, let’s clarify what “the team” means here. The team consists of not only developers, but also any Product oOwners and Business Users involved as requirement sources, the Scrum Master, and sometimes a Project Manager on the customer side (if we are talking about offshore).

Even if you have a handful of skilled developers with Agile experience, there still can be issues. ”Agile” means that there are no strict rules, but rather a special mindset and a set of best practices. Some of them need to be implemented every time we are talking about “Agile,” while others are “nice to haves” for the majority of cases.

In fact, when we say “agile” at DataArt, we rarely mean a particular process like Scrum, Lean, or XP. An experienced manager builds a new process every time using the best practices applicable in any particular case. So, some of the practices can be new for a part of the development team.

Another significant requirement is an agile mindset which is denoted by the Agile Manifesto. But what is not emphasized (but definitely meant) is a mutual respect among all team members (developers, users, and management) and their good will to make a good product and complete the project. The other core principles are listed on the same site at http://agilemanifesto.org/principles.html.

Finally, the third ingredient is a shared project goal and the criteria for project success. If not clearly articulated, these goals and criteria can be different for each of the team members. The simplest example is when the users want a fast and simple product, and the team believes that their goal is to use the most powerful and challenging technology on the market. Sometimes the contradictions are deeper – such as when different user groups have their own contradictory goals and ignore the interests of the others.

How do you fix this?

  • Ensure that each team member believes the project is reasonable and is interesting for them, and that everyone understands the goal of the endeavor (value for business, interesting from the developer’s perspective, etc.).
  • Ensure each of the team members understands the core values of the Agile Manifesto and the principles behind it.
  • Review the practices that the team uses and ensure that the implemented processes cover critical areas like proper acceptance criteria, early demos and user acceptance of the implemented work, and constant process improvement based on retrospectives and business users’ expectations from the development process.

Your company is not ready for Agile

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
(Agile manifesto)

If a company has already established processes that work, there are often no reasons to bother executives with changes in budgeting or legal approval approaches.

For example, a typical case may involve legal documents which follow a corporate template that was developed keeping a V-model approach in mind, which expects a strict scope description and strict acceptance criteria.

In this case it’s difficult to “respond to change over following a plan” without risking failure in “customer collaboration over contract negotiation.” This brings with it the risk of developing great software that cannot be paid for or accepted.

Another similar case involves rules for requirements specification to follow some templates which are not user-story compliant and/or require a lot of time from Product Owner/BA to create and prevent the team from following “working software over comprehensive documentation.”

The third thing that can make things bad is the requirement for sophisticated reporting which can be boring or irrelevant to an agile-oriented manager and, thus, cause them to fail to demonstrate the real progress of a project.

At the same time there are processes and rules the team should follow to provide software that can be further used by the client (obvious best practices include operations guides or security and stress tests). So, if a team believes the cause of an Agile project’s failure is due to the constraints imposed by corporate policies and processes, it should carefully divide into vital areas and address the things that can be changed.

How do you fix this?

  • Divide the processes around a project into three groups: ones that are useful and vital for the product (security testing, configuration guides, etc.); those that do not contradict the main principals and agile values, but which require additional effort (code style, special reporting format, and KPIs); and finally those that won’t allow an Agile project to succeed (detailed acceptance criteria in SOW).
  • Put tasks to fulfill the first group into your backlog; discuss the second ones with responsible persons and develop an approach to adopt them and incorporate them into your process (for example, find an approach to convert your agile metrics into KPIs).
  • The third ones are the most critical since you need to force a change in established procedures and provide good reasons to executives and advocates. However, your team and users will help you as they see the benefits of the Agile approach.

Your business (or the particular task) is not “Agile-compliant”

There are some tasks that cannot benefit from an agile approach and which Agile would in actuality weaken.

You cannot perform a spacecraft landing on Mars on a weekly basis for demo purposes. You cannot afford to wait for user feedback to fix a bug in a Boeing safety system. You do not need to demo an implementation of each GSM protocol message to an end user of your new mobile phone. And you do not have time to carefully plan two-week iterations if in-house users submit tickets and expect immediate responses to their needs.

These are examples of tasks that are not Agile-compliant. If you realize that your project is one of those, you need to take a step back and choose another approach. However, this does not mean that Agile is bad, this just means that sometimes Agile is not applicable.

Please also note that even if you are developing aircrafts or mobile phones, there can be tasks where Agile works perfectly. So, if a GSM-module and phone file manager can be developed in parallel, you may run each project with its own process adapted to the nature of the task. One can even parallel work on business-as-usual tickets and develop new features using the same development resources.

How do you fix this?

  • If your task is not Agile-compliant, just switch to a V-model, ITIL or other process that is applicable in your case.
  • The V-model works perfectly in some cases, so it doesn’t make sense to discard it just because you think it’s not applicable for a .com startup.
  • The ITIL approach is used in many companies and has proved its value for over 20 years.

    There are plenty of approaches that are based on industry standards and experience in particular areas.


Add Comment

Name Mail Website Comment

  • Victor

    11 December, 2014 12:40 pm
    Прочитал вашу статью на Хабре. Меня тоже беспокоит эта тема, но как разработчика. Попробуйте взглянуть на Agile под другим углом. Методология нужна в первую очередь не для PM'ов и заказчиков и проекта, а для разработчиков и команды! Почитайте книгу "Победи прокрастинацию" автор Петр Людвиг (Petr Ludwig "Konec Prokrastinace"), там ни слова про Agile, но под саму идею хорошо подведена философия.
  • Cliff Moyce

    10 September, 2014 03:34 pm
    Excellent article Kate. Your three main root causes cover all of the scenarios that I have encountered personally. My only addition would be to say that team members not only have to understand the core values of the manifesto, they also have to believe in them fully and want to work that way (as long as the context is suitable). Iterative approaches being used by people who would rather be using waterfall rarely works well.