Roadblocks in your Agile journey

Dream. Dare. Do – that is Suyati’s work principle in a nutshell.

Oct
06
2015
  • Author:
  • Praveen Prakash

roadblocks-agilejourney-suyati
In my last blog, I focused on aspects related to incorporating Agile across the organizations and how to begin the transition journey. This blog talks about the four standout roadblocks I have experienced whilst dealing with Agile teams.
Roadblock #1 – The Agile coach/leader
I know this sounds like an oxymoron – questioning the very person who is supposed to lead the team forward into the Agile world! The biggest pitfall for all teams ready to take their first steps in the Agile world is to make the journey with an Agile coach who does not know what he is supposed to do, or does not realize what he needs to do.
Common mistakes that Agile coaches make are spending too much time and energy on conducting ceremonies because it is prescribed, assuming that one size fits all teams, and believing that they are more knowledgeable than the team, hence they are right. This is a recipe for disaster.
A smart Agile coach will, first, try to understand the team – what is the composition, what are the challenges they face, and more importantly listen to what they have to say. While he focuses on the ceremonies and the process, he is more inclined towards emphasizing on the value proposition of the ceremonies and the process as a whole. More importantly, he ensures that the team (and organization) can eventually sustain their practices in line with the Agile principles. This is a great trait I have observed with two gentlemen who have greatly influenced me in this journey – Syed Amir Kamal and Tony Cruse. As the adage goes, “a good beginning is half the progress made”; most of the other roadblocks are off shoots of having an incompetent Agile coach/leader.
Roadblock #2 – Fear of failure
Accepting change is a difficult task for us humans, especially when we have been used to doing things in a certain way for significantly long durations. Even if we do decide to embrace change, there is a huge time bomb ticking away in our heads, questioning what would be the end result – what if we fail? This is the second big roadblock that teams face, and is extremely difficult to handle, since it deals with human emotions. Agile teams are trained to take up responsibility; gone are the days when you had Project Managers assigning tasks and timelines, and teams delivering on those basis. Now, we have teams that self-organize, build sprint backlogs, and work side-by-side to deliver working software. But even before we reach the self-organize bit, teams start thinking – who becomes the fall guy in case of a sprint failure? Who will be responsible for the success or failure of this team? We do not have a Project Manager to fall back on; so what next? These are questions that arise due to fear of failure.
One successful way of handling this fear is having a leader who can establish two things – trust and transparency. Gain the trust of the team – let them know that as someone who is driving this journey, you have their trust. And to gain this trust, it is extremely important to make transparency part of the team culture. An example of this is something I experienced in one of my past assignments wherein I missed capturing certain requirements from the Product Owner, which had an impact on the deliverables. It would have been easy to lay the blame squarely on my shoulders, but rather I had my manager supporting me all the way and ensuring the requirements I missed are addressed in future iterations. The fact that I have my manager’s trust is a huge reassurance and the more important thing was he let me know that everybody fails, but it is a bigger crime to not learn from those failures, and to keep repeating the same mistakes. He set the ground rules for continuous improvement and transparency in that instance.
If fear of failure is not addressed upfront, teams will look for the first possible instance to shun responsibility and get into the classic “not my job” mode.
Roadblock #3 – Ceremonies
As we work our way through the first two roadblocks, and finally get some traction with the team, along comes the next roadblock – ceremonies. This is a roadblock that is particularly frustrating for teams that are into SCRUM, which prescribes a set of ceremonies such as sprint planning, product backlog grooming, daily standup, sprint reviews and sprint retrospectives. Initially, I do notice many teams religiously participating (not necessarily contributing) in these ceremonies and after a point it becomes monotonous and team members start losing interest.
This is one roadblock, which can be avoided with a good Agile coach/leader. The important aspect to consider is the value proposition each ceremony brings to the table rather than conducting the ceremony just because it is prescribed. Many a times, teams conduct ceremonies just for the sake of it. A good Agile coach will highlight the value a retrospective brings to the table – it is not conducted to find fault lines within the team or to point fingers at individuals; rather it is an exercise that helps identify areas of improvement, repeat the good things, leverage best practices etc.
Another good way of handling ceremonies is to introduce them to the team in a phased manner. Start with couple of activities such as sprint planning and then build towards a sprint retrospectives in subsequent iterations. This allows teams to grasp the need of various activities, how to judiciously allocate time for each and remove any overwhelming feeling when faced with all of the ceremonies right at the beginning. Another good way is to avoid a ceremony (but this should have a strong and influential reason) – which was what one of my teams did. We skipped the daily stand up simply because the team was co-located and had extremely high levels of interaction and collaboration which meant all team members were almost always aware of the good, the bad and the ugly during the sprint. Of course, in certain situations we did have an ad-hoc standup meeting to fine tune our ignorance levels.
Roadblock #4 – Lack of patience
This roadblock is essentially an external roadblock – not something the teams themselves bring upon. When teams begin the Agile journey, even if you have top management buy in to start with, it is not surprising to shun the idea within few weeks of beginning the transition. The common refrain is – “it is not working, too much time is spent on non-productive activities, and results are taking too long to reflect”. It is important to realize that many a times; things become worse before they get better.
Again, a good Agile coach/leader is essential to constantly remind everyone that changes will not happen overnight. He has to ensure that the learning and unlearning phases are well managed to show incremental improvement. My last team had a collective experience of about 100 years (spread across 12 members) and we took about 8 months to fully embrace the potential of SCRUM and then started reaping the benefits of it. The great thing in this period was to set goals that highlighted incremental improvements – both in terms of quality workable software and achievements for the team in terms of best practices and learnings. This allowed us to show the management that there was something positive happening which could then be applied to other teams. The second thing our strong Agile coach did was to ensure that all other departments – Sales, Marketing, HR and top Executives – were constantly educated on what we were up to, how it would impact them, and what they need to do to align with the overall process and objectives.
As promised, this covers the four roadblocks that I have constantly encountered across various teams I have been a part of. There are plenty of other roadblocks that can be situation specific such as handling multi-located teams, handling multiple teams working on the same product/project etc., which all have unique learning experiences. I welcome my fellow Agile practitioners to share their perspectives and experiences, and even challenge my thoughts as they continue on this journey.

About the Author:


Praveen Praveen Prakash

Praveen is a Technical Product Manager, who is passionate about Agile, especially SCRUM and Kanban. He loves coaching teams on Agile principles with the sole intention of proving the management wrong. Praveen has over 7 years of industry experience with a focus on learning something new every day.

Leave a Comment

Your email address will not be published. Required fields are marked *