Limiting WIP for Crowd Control

Couple of weeks back, I had a chance to attend the Mahamaham festival on 22nd Feb. 2016 in Kumbakonam town in Tamilnadu state, India.

It is one of the great Indian bathing festivals which happens typically once in 12 years. As against the other ones like Kumbh Mela or Godavari Pushkaram, which happen on a river this one happens in a huge tank.

This tank has multiple approaches and unlike with a bathing festival in a river, a tank offers limited space for devotees to take a dip. There is the auspicious day and within that day - the suitable time. Around the "holy hour" there is a huge rush and a huge possibility of a stampede. In 1992 event had a history of stampede related deaths. Typically half a million to one million devotees converge on the given day.

Now, to what stood out in terms of crowd management that day:

- There was one entry and one exit - a practice widely followed in most events. Entry through the eastern side and exit through the western side.

- There were 14 gates in the streets leading to the entry. These gates spatially well positioned, with the intent of curtailing peak crowding in the vicinity of the tank. During the peak bathing day, crowds were held in these different gates and released in batches. So at any point in time, the number people taking dip within the tank was well regulated.

The public authorities were clearly thinking in terms of how many people could take a dip at any point in time and entry into the tank area was based on that - clearly WIP limit in action.

I am actually reminded of the practice in a Tokyo Park about the token system to keep a tab on the number of visitors narrated by David Anderson in his Kanban "Blue Book".

Good showcasing of Lean Principles in Public domain.

Photo Credit: The Hindu / Web Edition / Feb. 22, 2016

Is Scrum Master a full-time role?

This is a typical question which arises not just when agile teams are formulated but even as teams mature.

While debating whether it is a full-time role, I am certainly not suggesting or for that matter, even considering a situation where Scrum Master is shared between teams. That is a certain No.

The question is should a Scrum Master should do his role full-time or should take other tasks within the Sprint commensurate to his/her skill areas.

One can certainly argue that core tasks within the role - like conducting the agile ceremonies, removing impediments, facilitation & enabling, conflict resolution, promoting cross-functional and self-organizing behaviors and so on in that direction - demand a full-time role. Like how this scrum alliance article argues.

In my experience working in & coaching scrum teams, I have observed that in the initial days of agile and scrumming, there is a lot of work - setting up the agile ceremonies, sorting out bottlenecks, stakeholder coordination, improving team collaboration and helping the teams to get cleared of any "starting troubles".

As things start settling down, typically teams start displaying more cross-functional and self-organizing behavior.  Sprint moves on its own, with the Scrum Master as a care-taker, intervening when needed.

In this situation, I suppose the Scrum Master should be free to take up delivery related tasks. May be for a limited fraction of his time. Thus a contributing Scrum Master remains in touch with his core skill, enabling him to pitch in for the team when needed and understands - on the ground, how user stories get done. Through this, Scrum Master in a very subtle way displays that he is also another team member taking up team's tasks, when there is an opportunity to do so.

I am against this idea of having a person dedicated for a leadership / management function - especially when adopting a methodology which emphasizes on delegation, team work and collaboration. That too when the team size is around 7-8 people.

Mike Cohn, in this article, though did not explicitly rule this option out, said that Scrum Master should be readily available for supporting the team. Should a Scrum Master just be waiting for situations where he needs to intervene? I would rather prefer he/she takes up some tasks in the meanwhile.  

Cross-functionalism in agile teams - to what extent?

I was reading a Linkedin post by Steve Bockman about Siloing versus Specialization a couple of days back and it triggered this blog.

We have a team built from people of various specializations, typically we may not be able to deliver as a team and Cross-functionalism is seen as a desirable attribute within agile teams. Stretching the arguments for cross-functionalism do we imply that specialization is undesirable within a team?

Specialization in the Industrial age meant that the person focuses on one area of the Production process and because of the skill and felicity built over practice, the productivity is enhanced. So to enhance the overall output we need to have specialists and the specialists were grouped into horizontal groups and so on. As  we could imagine in a production set-up the work items were homogeneous and work was repetitive in nature.
This same word takes a different meaning when we apply it in the Product development space. Specialists provide technical or domain excellence needed to develop products. They are not there because they can do things merely faster but because of the skills and expertise they bring to the product development set-up. So to succeed in the product development game we need specialists who can help implement cutting edge features which provide competitive advantage.
But specialists being specialists often confine themselves to their own areas and have a narrow view. It is tackling this that I see cross-functionalism coming in. They still retain their specialization but build up skills in related areas, 

• to collaborate 
• to reduce handovers 
• to able to see the big picture 
• to understand the different dimensions so that suitable trade-offs can be made and so on. 

So in the end we want to have a team with complementing specialist skills so that as a team it has all the relevant skills suitably distributed that it has all the ingredients to develop a world class product. So somewhere there is an "adequate" or "sufficient enough" clause coming in for cross-functionalism.  

Cross-functionalism cannot become an objective by itself. It has its value when it is placed over a team which has sufficient specialization with complementing skills. If we were to interpret it as "anyone on the team can perform any needed function" then ultimately we will turn a team of 'complementing specialists' into 'generalizing specialists' that they will lose their domain or technical edge and move the product towards mediocrity. 

This is the point emphasized by the T shaped skills as well - they specialize in one area but have basic skills in other areas as well.