During recent years we have seen how the popularity of Agile has climbed to the point where it is almost a status indicator: either you are the cool, modern, efficient software development team, or, you are one of those Ice Age cavemen that have not been able to move on from the ancient practices. 

It is therefore understandable why many teams around the world are trying to become at least “somewhat Agile”.  However, the degrees of success they are obtaining while trying to transform their teams are vastly different.  In some cases the evolution feels so natural that it is as if team members already came with the Agile “chip” and they just turned the switch on. In other cases, the process can be a nightmare of resistance to change, stressful situations and mediocre results. 

After years of learning about the different experiences companies have had implementing Agile, here are some of the most common points of failure that are found along the way when they decide to embark in the fascinating expedition to the promised “Agileland”. 

Buy-in From Management and Above 

One might think that Agile implementation can be circumscribed only to the software development team, however, this statement could not be further from the truth. All functional areas in an organization need to interact effectively with each other in order to produce the expected results, and this is no exception.  For example, all stakeholders need to understand their input on the software that is being built is not given once and then forget about it for six months or a year until they are presented with the results. Instead, it is likely that their feedback will be required regularly by the Product Owner to make sure the alignment with business needs is maintained and the correct priority is given to the stories. 

Also, one of the “make it or break it” points that involves management is budgeting. Finance departments are used to getting straight answers when they ask their typical questions, such as, how long it will take and how much it’s going to cost. And even when this can be answered (at least to a certain extent) by using estimation methods, if we start rambling about Emergent Architectural Design and Story Points it is possible that the conversation will not get too far. Higher level negotiations need to take place in order to find middle ground where money planning can coexist peacefully with the flexibility Agile requires. 

Not a Recipe 

A common mistake in Agile implementation is to read a book about it and try to follow it step by step.  Every company is different, every team is different, and every project is different; so in this case, one size does not fit all. We need to keep the big picture in mind and be aware of our surroundings.  Organizations must be seen as living organisms, which constantly change and adapt. Therefore, the concrete application of Agile principles and values needs to observe a similar behavior. 

With this in mind, it is important to start with a good analysis of which practices make sense to implement based on the company’s current circumstances, culture, priorities, etc. and review their effectiveness at every retrospective meeting to see if they were actually useful or if we need to stop using them and try something different. 

Additionally, not all practices need to be in place from day one.  Even when we identify something that would be good to start doing, we must consider the team’s workload, the amount of changes that they are currently undergoing and, most importantly, their Agile maturity. It takes time for the team to get used to work in a different way, so it is advised to dispense changes in the correct doses. 

Discipline and Leadership 

Since the Agile Manifesto values more of the practical aspects of software development, some people get the impression that this is a rather chaotic or unruly approach. However, it actually takes a good amount of discipline to adopt the practices in a way that will render the expected results. 

One example is daily standups. It may take a while until the team members start participating correctly in these meetings. Identify which issues are real impediments (or not), get into the habit of talking to the group instead of trying to report their activities to the scrum master, come prepared to the meetings, and finish before the standard 15 minutes. 

At early stages, it is recommended to have a good Agile Coach for the team to rely on. Regardless if this is an internal resource or an external consultant, this person’s leadership is very important, not only to guide engineers on how to apply Agile principles, but to do it in a way that they embrace these new ways of working. Once certain maturity is achieved, the role of the Agile Coach will become less and less active and the team will be on their way to self-organization. 

Know Your Roles 

A good understanding and execution of the roles is a crucial differentiator between a productive team and one that struggles to demonstrate the benefits of the Agile world. From experience, usually the most successful teams are those where members understand their role and embrace it. Where everybody knows what they need to do and also what to expect from each other. And when this happens, communication simply flows better, meetings are more effective and the overall team morale rises. 

The Scrum Master role is essential for the day-to-day activities.  Facilitating the different events and removing impediments are two fundamental functions that will influence directly the results that a team will be able to achieve. However, one of the most critical roles is, without a doubt, the Product Owner. The person in this role needs to have at least three core characteristics: 

1.Be the unified voice of all the different stakeholders and be empowered to define and prioritize the product backlog. 

2.His/her knowledge of the platform should be at least enough to understand the impact of changes. 

3.He/she must be in frequent communication with the development team to answer any questions, clarify requirements and provide feedback. 

Some people try to “translate” from the old world and think that the product owner is the same as a business analyst whose job is basically to write functional requirements.  Nevertheless, breaking this paradigm and understanding the real emphasis of a product owner will be decisive for the success of any team. 

Soft Skills 

With a few exceptions, software engineers tend to focus more attention toward developing their technical skills and not so much their soft skills. It is possible that even some of them decided to go into this field because they thought they would be interacting more with computers than with people. 

Interestingly, today’s software development work environments are much more dynamic and require a great deal of personal interaction. Giving and receiving feedback, presenting demos, doing code reviews and mentoring less experienced team members are just a few of the many ways engineers have to interact within an Agile environment. 

It is not a bad idea for a company to provide different ways for their employees to improve their soft skills. This type of investment is probably difficult to quantify (and therefore justify), but when you start to see results like better communication, less misunderstandings, more efficient meetings and less re-work, you will know you were right on the money. 

Putting it Together 

As you can see, when you dive into the details, there are a lot of moving parts;  that’s why implementing Agile is a lot easier said than done. Teams all over the world have found challenges in the topics described above and have either experienced a transition a lot harder than anticipated, or even dropped the effort altogether and  decided to stay with their previous way of doing things. 

To increase the probabilities of success, it is important to consider the theory that can be found in many sources these days, but also the practical aspects of a change of this nature, considering the persons that will be involved, the organization’s culture and goals, and the particular value that each new practice will add to the desired end result. 

At the risk of sounding too cliché, we need to see the moving to Agile as a journey, not a destination.  You are never really “there”, there is always something that can be done differently, even when it is just to try it out and see what happens. So if you are in this process of migrating your methods to something “more Agile”, don’t expect to turn on a switch and have an Agile team by Monday. It takes a lot of effort, it requires changes in behaviors, and the results may not be evident from day one; but if you take this endeavor with the right expectation, understanding and attitude, you will see a very rewarding transformation that will benefit your team members, your organization, and you.