Select Page

While there are many important aspects that help in successful adoption of Agile, I would like to write about one of them here and that is ‘a compelling reason for continuous improvement’. While some situations might force teams to take to Agile, I believe a reason always exists for continuous improvement in teams and it is a question of how well one can make it visible. In large organizations, it becomes more difficult in my experience.

By Agile adoption I mean mainly moving towards self-organization and regularly identifying and working on improvements. There are many factors that influence these aspects. Let us take some examples.

Rockers had about nine persons and were into development. They started on Scrum and underwent few training sessions, identified Scrum Master and Product Owner and decided on using a tool (JIRA). Team, Scrum Master and Product Owner were coached by me. They started earnestly and were doing all the required ceremonies well. After couple of sprints, some team members started to show some disinterest in some of the ceremonies and some were absenting etc. Then I started focusing on coaching  Product Owner and Scrum Master highlighting the values and principles of Agile and focused on collaboration in team by conducting some team exercises.  This did bring in some change in mindset and over a period of time they started to see some good results. Manager was happy as the team started to own things and was becoming self-organized. When I thought about what could be the factors behind such change to adopt Agile practices earnestly, many things came to my mind but one factor did strike me hard and that was clarity on goal. There was a good release goal set by Product Owner. It not only with respect to functionality but some specific goals were set with respect to adoption of engineering practices as well. This gave a compelling reason to the team to look at Agile practices seriously and they found it very beneficial.

Challengers was a large team and had over 18 persons and was also distributed across multiple sites. They were an operations providing round-the-clock support. They were not able to fully embrace Agile practices for benefit though they had been coached for a while before I came in. And they had many challenges which they were struggling to overcome. When I started to coach this team which was using Kanban, the Product Owner, Scrum Master and some team members used to approach me regularly requesting help with some issue or the other. So they already had a bunch of problems which they were facing and that gave them a compelling reason to approach me for further coaching. After few months of coaching, the team had become reasonably self-organized and were very focused on continuous improvement too.

GoGetters was also a large team of 19 persons providing 24-hr support. They were distributed across two sites as is normal with such support teams. They had started on Agile in a small way and had some initial coaching but somehow many things were not in place. When I started coaching them, I started again with some training sessions and then coaching them on effective use of ceremonies etc. While I tried my best to convince the team and Scrum Master on the value of these practices, I found no takers. I, as a coach, had several retrospectives with the team managers and was even tried changing my approach couple of times but even after few months of coaching I found that there was very minimal acceptance and adoption in the team. When I analyzed in detail, one of the things that struck me was that there was no compelling reason for the team to adopt Agile or in other terms there was no compelling reason for the team to focus on continuous improvement! Then I started thinking and identified a few factors which could have caused this kind of dysfunction in the team:

  1. There was no visible goal set for the team. In case of Rockers, a Release Plan was in place for the team had to plan and work towards. In case of Challengers there were many issues which the team was facing and they had to solve them to move ahead. While for GoGetters, there was just plain day-to-day work and nothing beyond. Why would such a team think of continuous improvement?
  2. Managers were too hands-on and that prevented the team from becoming self-organized. Because of this there was no need to make things visible as managers knew everything that was happening in the team by just oral reporting in a Daily Stand Up. So the team had no compelling reason to use either a task board or any other tool except for the tool which was already in place for raising and assigning tickets to team members. Even the traffic was not much and so all tickets raised would get closed in a day or two. Managers or sometimes customers themselves assign tickets directly to members and no one had any problem with it.
  3. No team goals were set for short/long term. Management was very focused on getting day-to-day work done and any issues solved on an ongoing daily basis and hence team did not bother to do anything beyond that.

It is not that there are no goals for teams in any organization. But what was actually missing was visibility to those goals. I realized that managers needed a lot of coaching help in making the goals visible to team with expected delivery dates and believing in team members to take ownership of tasks among many things.

In short, what I realized was that there should be a compelling reason for teams to adopt Agile or in other terms focus on continuous improvement. They should have a reason to question what they are doing, the way they are doing. Else most teams would not pro-actively do it. Giving a direction to the team to make things visible for the sake of making them visible or asking them to identify improvements when they do not have visibility to a long term goal would not convince a team to embrace Agile practices.

I am sure many of you would have come across such situations and would like to hear your experiences in this regard and also your views and comments on the points captured in this blog.