Service-based Teams and the Curse of Agile

Even after 23 years and so many success stories, the industry is still exploring the agile methodology and learning how to implement it correctly. On one hand you have the agile purists that treat the original four principles - and perhaps the following 12 principles - as a religious scripture that ought to be followed and held in the hearts of all team members all the time, and on the other hand you have the practitioners that just want a concrete recipe that their teams need to follow to the heart to improve their productivity. Between those and those lie a whole lot of people who try to discover what works best for them. And to those champions of trail-and-error I talk.

When I read about agile, especially the main four principles. I get that the essence of agile is great communication. Communication between developers and stakeholders in the form of constant and early feedback from the stakeholders about each new feature, communication between the leadership and the team in the form of open planning sessions and communication between the team members in the form of daily standup meetings and sharing progress. All the techniques of agile such as scrum, kanban and extreme programming follow the same values, but they differ in additional characteristics each of them have that prove useful to different kinds of teams.

Since software engineering is mainly about building products, the scrum technique is the most popular agile technique out there as it increases the efficiency of product-based teams. You have time-windowed development cycles to ensure fast delivery of new features, you have frequent meetings with the stakeholders for them to review new features before releasing them. A perfect little world isn't it ?

Our problem begins when the service-based teams, you know, those teams who don't build products instead they are providing a service, though that scrum would work well for them. This simply can't be true for the following reasons :

• Service teams don't need time-windowed development cycles : Service teams' work is continuous so it makes no sense to time-window it since no value will be gained from doing so. In product teams you are supposed to release a version of your product after each sprint. But what will you do in the end of every sprint in a service team ?

• Service teams don't need frequent stakeholders meetings : For product teams, frequent meetings with the stakeholders make sense because normally the development process is done away from these stakeholders. So frequent meetings with them are necessary to ensure the what the team is working on matches their expectations. But in the case of service teams the stakeholders are using the service as the team is working on it, making the frequent meetings useless as any feedback will be delivered by the stakeholders instantaneously.

• Scrum don't handle well dependencies across different teams : Product teams are normally self-contained. The rise of agile demanded clear and quick communication between different profiles working on the same product which resulted in the need to change the decades-old hierarchy of teams. This need was addressed with the rise of Devops which combine the development people and the operation people within the same team. So the agile response to dependencies across different teams is to join different teams into a big team, as you see it isn't the best solution to the problem. With scrum things are even worse. Since the velocity is a key metric in scrum and is calculated through the done story points by the end of the sprint, it is extremely important to commit only to what you are sure to be able to finish by the end of the sprint in the sprint planning meeting. But what happens when through mid-development you discover that the user story you are working on depends on an input from another team and that team will not finish their input by this sprint ?. Your scrum master should help you in clearing any obstacles, how ?. I don't know, no one tells you - or the scrum master in fact - how this will be done. So eventually your scrum master must do some numbers magic to remove the weight of the stuck user story form the committed story points but keep the weight of the work done by you in this sprint as you have consumed some man hours. Service teams work with other teams almost all the time so imagine this hell every sprint with at least one team member.

• Scrum don't have a placeholder for issues and support: Product teams are normally development teams, they work on pre-defined set of features the whole sprint with little or no surprises at all. Service teams on the other hand can have some weeks where 100% of the work done is to solve issues and support the stakeholders. Scrum's cornerstone is estimating how much effort is needed to finish a user story. The saying goes that even if these estimates are very inaccurate at first, they will become more and more accurate as the team work on the product more. You can't put estimates on issues though. One week you have absolutely no issues and the next nothing seems to work.

For all these reasons, I truly thinks that scrum is not the best thing for service teams. But what to use instead ? Enters Kanabn.

Kanban is perfect for service teams. You don't have sprints, weekly or bi-weekly meetings with stakeholders. Just a constant flow of tasks that need to be done. The task you are working on is stuck ?. Put it aside and grab the next one in the queue. An urgent support request came ?. No problem stop what you are doing right now and tackle it. You finally have the freedom to switch between tasks without the fear that your efforts will no be calculated within this sprint or that you will mess up the velocity of the team.

However, not everything in scrum is bad. We can continue to use story points estimates to size up user stories to help us better determine our WIP (Work In Progress) and our throughput (amount of work done in a fixed amount of time). Estimating user stories will need periodic team meetings. Also prioritizing the backlog needs periodic meetings with the stakeholders.

In the end, I see using kanban as an absolute win for any service team. Not only does it give them the flexibility to change what the team is working on at the moment, It helps them define the value stream and focus more on bringing more value to the stockholders.