The empiricism underpinning all agile methods means that people live in a constant inspect & adapt loop. It is primarily about the product being worked on – but it also applies to teams themselves. The idea is that with agile not only the product evolves and gets better, but also the teams – and thus people teams are made of. This is one of the claims as to why agile is inherently better than waterfall – it not only produces better products, but also better teams. Some agile methods recognize improvement in teams’ ability as an important part of the process and prescribe tools to foster it – for example a retrospective producing actionable improvements every sprint is a required part of Scrum.

This is all very nice & good, but the problem is that improvement is a slow, monotonous process. It is rarely achieved by doing something spectacular. It usually means adjusting work methods, coding styles, design habits and daily routines. Often those are small adjustments or they are achieved by a series of small steps through time. It means taking the actionable improvements seriously and honestly striving to implement them every day, every iteration (sprint to use the Scrum term).

Why is this a problem? Because there is little joy in this as the change happening every day or every week is so small it is imperceptible for those involved.

How can we solve it? By making the improvement visible – and by keeping the work itself fun and engaging.

One great tool is retrospectives – they should not be solely about hunting down problems, but also recognizing, even celebrating improvements that the team achieved. There is a strong tendency to be negative during retrospectives, to concentrate on what didn’t go well as opposed to recognizing what was right. A more balanced retrospective gives team a chance to realize how much they have improved since the last time.

Another idea for making improvement visible is encouraging both internal and external sharing of knowledge and work through talks and conferences. If you talk to peers about a craft you share you will frequently find that what is already part of daily work for you is a discovery for others. This is the moment when you realize how much you have improved. Organizing a monthly, internal “tech talk” or encouraging people to submit talks to conferences is a way to foster this.

In any case I think it is the Scrum Masters (or Agile Whatevers) role & responsibility to make improvement visible, at least from time to time. It also part of the responsibility of managers overseeing the overall development organization. And it all starts with recognizing that improvement is boring…

Update:
This problem is not exceptional to software development. It is exactly the same in other crafts/skills – path to mastery leads through small improvements.

In fact, it should be easier for software developers, because in their case the improving quite frequently means learning something new – and this rewarding in itself. Others have it harder, because in other activities improvement comes through repeating same things over and over again. Musicians play & play same tunes for hours to get better. Soccer players repeat same standard moves as part of their training.

What is common, however, is that a) it takes discipline and willpower to improve and b) from time to time the improvement made is made visible (a musician plays a concert, a soccer players plays a match).