Continuous learning is like blood in the veins of an engineering organization. If learning stops, it directly impacts innovation. Eventually products as well as employees lose their competitive advantage.

That's why it's not surprising to see that half of today’s most in-demand skills weren’t even on the list three years ago.

Continuous-learning also helps in removing waste as well in Lean terms. From a Lean Software Development perspective, handoffs among team members cause delay which is considered as one of the seven wastes in Lean terms.

This delay happens when one team member (e.g. John) hands over a task to another (e.g. Sarah). 

Whenever there is a handoff, the relevant person Sarah in this case may not begin the work immediately as she may be working on an already in progress task. 

In turn John leaves that task in the Analyze-DONE column of the above Kanban board. That builds inventory of the work between Analyse-DOING and Dev-DOING steps and causes delay. Also during handoff, knowledge gets filtered out.

As per Poppendiecks, companies lose about 50% of knowledge in every handover. This means that after 5 handovers the leftover knowledge is only 3% of the total amount that initially started to flow.

In order to reduce handoffs, team members with specialized skills need to expand their skill boundary and need to learn secondary skills which help them reduce handoffs and dependencies.

Toyota in similar ways reduced the number handoffs among the workers by asking 1 person to handle multiple machines instead of earlier 1 person handling 1 machine.

They used U shaped work cells in which workers move with the work in process through the entire work cell or maybe a few workers do through the entire work cell.

The work-cell reduces the number of handoffs, which reduces the amount of inventory you are building between the steps and results in improved flow.

We arranged machines in parallel lines or in L shape and tried having one worker operate 3-4 machines along the processing route…Our craftsmen didn’t like the new arrangement requiring them to function as multi-skilled operators.

— Taiichi Ohno (Toyota Way)

Teams built with T-shaped individuals tend to adapt to the challenges ahead easier.

The idea is – in a team, for each core competency, there should be one expert and one alternate. The alternate needs only to be competent as a developer, not an expert.

John’s key competency is Spring but he is competent in AngularJS as well. He is hardly an expert in AngularJS. He has to have a book in hand if he’s going to do anything adventurous. But he is a learning person. Such adaptability is at the heart of agile development.

John knows nothing about ReactJS or about 100 other of the new technologies out there. But if you were to put him on a project using ReactJS, he could become competent in a couple of weeks and proficient in a couple of months. A learning person would accommodate the need.

That’s a big mindset shift compared to the existing “I am a Python developer or a front-end or a backend developer”, siloed mindset. 

How People Become T-Shaped in a Scrum Team?

Step 1 - Create a Cross Functional Team

First and foremost, for a team it’s important to be truly cross-functional. That way, the team covers its bases and is able to work on and create end-to-end functionality.

Step 2 - Introduce Cross Training

The second step is to do enough cross-training to get to the expert / standby position. This is a risk mitigation strategy. If you lose a team member, either permanently or temporarily, it doesn’t stop the team dead in its tracks.

Also, if a team is supposed to work together for 6 months or for a year, it certainly makes sense to learn the rest as secondary skills. This works just because we are still talking about software development. It will not work for a software developer and a construction engineer.

In order to learn secondary skills, people have been using online hands-on courses like PluralSight or Udemy to get the jump start on the new technologies. The quality of many such courses is also pretty good.

With this base and a good reference book or resources in hand, people learn further through pair programming with fellow developers. In my experience, pair programming works really well to learn new stuff. 

Step 3 - Deepen Individual's Knowledge

As a third step, it is important to deepen individuals’ knowledge in what they do know. These folks can make snap judgements, and snap judgements are extremely valuable because they avoid wasting time — and they’re usually right.

How to build a learning culture?

We should hire on the basis of a person’s ability to learn new stuff. The main contributing factors are aptitude for learning and attitude. Secondary factors include experience (decades dealing with systems) and breadth of exposure to different projects. This contributes to people’s ability to integrate and generalize.

Conclusion

I sincerely feel that we should move beyond the Waterfall mindset of categorizing roles and forming teams with mini silos wherever possible. It’s enough to have a role called team-member who may have multiple skills under her belt.