Agile is not new to anyone nowadays. Starting from manufacturing and spreading its wings so widely in the software industry, agile methodologies have gained more than their fair share of publicity. Nowadays you can even see non-IT people sending scrum/agile related jokes on Social Media.
In the IT product and services industry, the scenario is a bit different on both the ends when it comes to Agile implementation. While it is easy to implement agile methodologies in product development companies, there is a challenge when it comes to IT Services.
It is not so complex if you have to convert a handful of projects/clients in to agile, but the actual confrontation with the 'devil' happens when you are trying to become a “100% agile services provider”.
Believe me, it’s tough. But the first question is why would an organization, which is established in the services industry for many decades and doing much better than just surviving; want to convert to 100% agile. I have my few reasons, there could be more.
The above advantages overcome a lot of existing challenges in the IT services industry. However, as I said earlier, agile brings a lot of challenges because of the nature of the outsourcing industry.
When we started towards the dream of being a 100% agile company, we had to face lot of hurdles. Dealing with each one of them, one-at-a-time was important. The key to achieving success was at the core of agile.
Plan-Do-Check-Act (PDCA), is the strategy which did not let us fail at the trials. To overcome other challenges, we had to put some additional efforts and tweak our processes a bit with each ‘check’ we ‘adapted'.
In our scrum process, we made following changes and it worked for us. We also followed few of these tweaks in other agile methodologies as well:
Starting from developers, testers to middle & upper management, everyone should be aligned with the vision of ‘100% agile shop’. All the supporting teams specifically marketing need to have the game plan to participate. We implemented an organization-wide training which helped in spreading the harmony. To go to extra mile, we even set up an expert team of passionate agilists as center of excellence. The agile CoE team made sure that the torch of agile is well fueled and is shining brightly all the time.
As the agile implementation is, in turn, going to affect the clients, it’s essential to get the buy-in from them as well. Most of the clients will like the idea. However, for the ones who are not so receptive, we created a case study highlighting the challenges in their projects and their solutions. We also devised separate ways to handle various clients: one which answers the concerns of the new clients and other which talks about improvement areas for the existing clients with respect to agile methodologies.
In general, all the agile frameworks suggest that the teams should be co-located. Some have even tried to solve it with concepts like the scrum of scrums. However, the concepts like these, address the issues of big teams which can be divided into multiple teams and then you collaborate within the small team as well as with the teams in different locations. So what about the case when a team in itself is pretty small say 5-7 members, and is still not co-located. Or the Product Owner (PO) is in a different geographic location altogether.
It’s a very common scenario in companies working on the outsourcing model. Running agile in such places is a bit challenging, but it can be overcome using the proper tools and with effective communication. We have reduced the risk by keeping the Skype forum open all day and doing 2 DSM’s: one in the morning (internally, without the client) and one in the evening (with the client). Choosing an effective project management tool is also essential. After assessing the needs of the organization, clients and well as the agile support provided, we have been using tools such as JIRA, Taiga, Asana and TFS based on project requirements.
Another very common problem is client availability. For that, we need to understand that it is very important to have a single Product Owner (PO) role defined from the client’s side. The others can be team members or stakeholders, but the product is owned by this one person. We have to convince the PO to attend minimal meetings: Daily stand-up meetings (DSM), sprint planning, sprint review and retrospective. It’s also very essential to make sure that all these meetings have a fixed agenda and that they are always time boxed. The scrum master plays a key role in this type of setting as he/she has to make sure that all the necessary items are covered in the limited time.
One more risk, which we have identified is that few members have to wait for more than 10-12 hours due to time zone difference, in order to confirm something from the PO. This is a big challenge, as it hits the productivity. We solved this problem by introducing another role as ‘shadow PO’. This shadow PO is able to handle 60-70% of the queries for PO as the shadow PO also understands the system and its business. The product is the shared responsibility of PO + shadow PO.
With the time zone difference, another issue which we face is the week start difference. While the one-time zone is still lazy due to its Sunday evening the other one is all charged up on a bright Monday morning. So if the sprint start is on Mondays, for a few people in the team it’s not yet started. Hence the team, which is all buckled up to start work on Monday may have to wait till the other team also gets in the office. We have also seen that a sprint ending on Friday also reduces the productivity as people are in the TGIF mood. This means the review and retrospective meetings becomes just a formality. After a lot of trials, we saw that sprints starting on a Wednesday make a lot of difference in terms of focus and time overlap.
A best practice of scrum is that the sprint planning for a 2-week sprint should be 2-4 hours long for any average team. Spending that kind of time on calls is difficult. I believe, after an hour the effectiveness of the meeting becomes inversely proportional to time spent on it. Also for the services’ clients, it is highly unlikely to plan this kind of time at a stretch.
To address this issue effectively, we introduced a pre-sprint planning meeting, where the PO can explain the potential ticket to the entire team, and latter team can understand and discuss tickets offline. This keeps the discussions during the sprint planning meeting to be short and to the point.
These are few of the customizations we made in order to fit agile frameworks in our environment. Some came naturally as a first choice before even starting and some which came in retrospection. As I said earlier, the key is to implement the 'agile methodology' in the ‘project of adopting agile’ and it should be a success.
The process is still evolving even after 2 years of kickstarting our "agile adoption project".