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.

Where does Agile fit in

One of the first questions, I get asked by people new to Agile is "where does Agile fit in". My quick answer is wherever there is a complexity in domain or technology front - which requires an "inspect and adapt". In other words, where the means uncertainty and/or ends uncertainty is high.

Say you are developing an e-commerce application - there is this urge to use the latest mobile and/or analytics technologies. Then there is a the market dynamics which dictate what we do and when we do. This means that we cannot go the waterfall way and say here I have the finalized requirements, develop and get it running in x months. This way, we lose out on leveraging the technological advancements and can be out of sync with the market.

This would be a classic case for adopting agile, you have a fair idea of what to do and how to do, but you do not want to cast it in stone. Agile provides the flexibility to introduce new technologies and fine tune & prioritize the requirements in line with market needs. So at any point we are committing ourselves to 2-4 weeks of work (i.e the iteration length) and rest is open to change. 

In project contexts where things are fairly straightforward - like say developing a timesheet in a known technology, then it can certainly be done in the agile way, but the real benefits which will accrue in a complex set-up might not be realised.

Later on, in my Agile journey, I found out that this was best explained by the Stacey's graph or Stecey's matrix. This was developed by Ralph Stacey of the University of Hertfordshire.

Picture Credit: Edgeware Aides

The software industry has also be been moving from simple towards complex applications. As we see, more and more software is being used domain specific and hardware intensive contexts in Medical equipment, automobiles, Mobility, Utilities, Energy, Retail and so on. Software has moved from MIS oriented systems of 1990's to satisfying niche requirements coming from various sectors - also called as Vertical Specific Software.  

Lean thinking powers German Football team ahead

News is going around that, German Soccer Team used SAP's Match Insights technology extensively in the run-up to the World Cup and for that matter each of these games covered here.

The software, it seems, crunched through massive data sets coming from the Video cameras, covering the player movements, passes, holding time and what not.

In the context of Lean, what attracted my attention was this bit of information posted in the article.

"For the German national team, one of their key targets ahead of the World Cup was to improve their passing speed. With the help of SAP's Match Insights technology, the team was able to reduce average possession time from 3.4 seconds in 2010 down to 1.1 second in 2014."

This focus, helped them immensely in their win against Brazil, even though the possession of Brazlians was higher than that of Germans.

Certainly quick turn-around in passing (and I guess effective handover) helped Germans immensely.