Developing people in agile teams


I am working with agile teams for a long while now. I had good as well as very bad experience with expensive trainings. And I have my own strong attitude towards agile processes. Even though I still wonder if I help the team to improve by having trainings on a regular basis.
How do you develop people in agile teams? While retrospectives are a way to implement continuous learning in teams, I wonder if this will be sufficient. Consider the team had an initial Scrum training, would you want to repeat the training on a regular basis? I also wonder, if there would be extra value from having different types of trainings for team members, e.g. a Kanban workshop? Are there dependency on roles or would you even suggest to have the full team getting trained at once?

How to establish Communities of Practice?


Here are some things that I do with teams I coach or have been a SM on. If you are talking about technical practices…

Encourage knowledge sharing through pairing and ESPECIALLY mob programming. It’s a good idea to start off a team that isn’t used to working this way with a facilitator. There are different kinds of techniques a facilitator can use to help the pair or mob. I can give more details if you like but the idea is to learn from one another while accomplishing goals.

Encourage this kind of work even when two people don’t have the same skill-set but have the desire to learn. The issue with this is, there has to be safety within the team to try new things and safety within the org to understand that output is not equal to outcome. Investing in this kind of working early will lead to much better outcomes later AND more output down the line.

If you are talking about Scrum and agile process training then this is where you can lean on a good scrum master or Agile coach to teach this stuff in REAL time as it’s happening. In each ceremony that can facilitate and teach as well as throughout the sprints.

Establishing a community of practices is also a good idea. At the company I am at I currently run the scrum master community of practice and I teach new topics each week or have others teach or sometimes just have lean coffees. We also take assessments and see where we are and how we can improve. The Po’s have their own and the devs do as well.


Thanks @troy! That’s exactly the kind of talk I am looking for.

Mob programming is definitely a good thing. I was putting emphasize on peer reviews in the past, but not that much on these forms of co-working. I need to find out how I can make this part of our toolbox.

Having teams accomplishing goals sounds to me like there could be elements of gamification in there. Is this something you can confirm?

From what you write about the “agile skills”, it sounds like I should focus on training Scrum Masters and Agile Coaches rather than teams. This makes a lot of sense to me, as they would be able to respond to the specifics of a team and foster diversity rather than making everything the same. Do I get this right?

The Communities of Practice seem to be a great instrument to facilitate knowledge exchange across teams. I guess it works the same for agile and technical skills. Anyhow I am still a bit hesitant, as I try to find the minimal set of rules to kick them off. But this seems to be something I should put into a separate thread, whereas the idea itself is perfectly complementing the rest of you reply.



Book clubs at work are a tremendously powerful tool when it comes to growing people. Pick a topic people are interested in improving (technical practices, leadership, etc), find a good book, and set up a reading schedule. And, of course, meet every couple weeks to discus the chapters that have been read.

Giving people permission to read and discus things at work will help show that the organization is serious about growing their people.

It’s been a favorite go-to for me for the last many years!


I’ve always encouraged teams to map out their skills to highlight any single points of failure or complete lack of knowledge in key areas (which outside help is needed). Using this the team can set training goals per sprint or every few sprints to share and increase knowledge / gain skills.

Recently this has culminated into ‘internal training sessions’ where we reserve some sprint time for a day or two’s dedicated training. Feedback from team members so far has been they find this far more valuable than attending external training courses.


I’ve been experimenting with coaching my teams to map out their skills like @paul.cutting mentions.

Very positive response…

General framework, which I’m continually adapting:


@andycleff, I love the toolbox described in your blog post. Self-learning teams are the ultimate goal.


@hdietrich Google Forms has made it incredibly easy to build the inventory tool and help the team create their future vision.

Here’s a sample:

And a snapshot of results using the Advanced Summary add on for Chrome:

The hard part now for me will be implementation. Creating the slack time necessary for the teams, in spite of the pressure of the business stakeholders to “deliver (more more moar) working software”…

Shall we hijack this thread a start talking about strategies to convince the suits of the value of “Sharpening the Axe” time?

Strategies to convince the suits to spend time for "Sharpening the Axe"

I’d love to hear about those “convince the suits” strategies. They would not go astray at all in my day job.


I have to second @troy’s recommendation. If there is a good mix of skills on the team and some senior level folks I start with pair & mob programming. I recommend Ping Pong Pair Programming over the Driver/Navigator model as I’ve found that to be much more effective and enjoyable for teams. Contrary to the early XP advice I still recommend code reviews even for code that is created in a pair as both developers have the “author mind” when writing the code. The teams I’ve worked with still got value out of having a reviewer acting as the “editor” who wasn’t involved in the details of the task.

One thing I’ve done to help level up teams when either the team is lacking in an area of expertise or you want to reach a wider audience is to plan internal workshops (a mix of instruction and hands on practice). I’ve created interactive sessions for coaching on TDD, identifying code smells, refactoring, etc. That has more organizational visibility so it’s sometimes harder to get permission (if that’s a problem), but it’s cheaper than bringing in outside training typically.


I have created a new topic for the discussion on how to convince management to have development teams spend time for self-improvement: