The Rules of Scrum: I am willing to learn any skill needed to help my team

Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills.  Skills can be technical, business, personal, tools-based, etc.  A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve.  A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn.  In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively.  This attitude is a key requirement for the formation of high performance teams.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

2 thoughts on “The Rules of Scrum: I am willing to learn any skill needed to help my team”

  1. I agree, but there are situations where this is difficult to encourage. I worked at a company with mainly .NET developers working on their next generation product, but their core back end system was in FoxPro. The FoxPro guys were on board with learning .NET, but the .NET guys were understandably hesitant to dedicate significant time and effort to learn a technology that was no longer very viable in the market. It was hard to show demonstrable value in learning FoxPro outside of their current company. With the average engineer switching jobs every 4 years, it is hard to get them on board with the company’s long term goals at a possible detriment to their own near term goals.

    So how would everyone else encourage a team in that situation?

    1. Hi Tommy,

      I don’t know about others, but I would probably just worry about it if there was specifically a problem. For example if there was lots of FoxPro work and it was holding up the team. If this kind of problem existed, I would consider:

      1. use the retrospective to bring the problem to the team and see what they come up with
      2. get the Product Owner to constantly emphasize the importance of the work to making the lives of customers and/or users better
      3. make the skills gap visible with a technique such as a Skills Martix
      4. suggest general approaches to the problem without telling specific individuals what to do, for example, seeing if there are ways to use .NET to automate FoxPro development (code generation)

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.