2016-09-11

Striking a Balance Between Learning and Building

Tom Breur
11 September 2016


“Learn as you build” is one of the important principles in Agile teams. In knowledge intensive professions like software development, you simply cannot afford to rest on your laurels, rely on your (existing) knowledge to carry you forward. Continuous education isn’t an option, it’s a must.

As part of proper “craftsmanship” I have always felt that you should not limit learning and education to classrooms and courses. In fact, I would say that the most powerful and effective learning almost always takes place on the job, rather than outside it.

Sitting down with a peer to share insights, quiz each other, and think through consequences of alternative design decisions may not (immediately) lead a working product, but I have always found it leads to better, more maintainable, superior products. Needless to say, that is the hallmark of “higher velocity”!

What is less obvious, is how to strike a balance. Cranking out code, testing it iteratively, finding out “hands-on” what works and what doesn’t, is learning on the job, too. Different strokes for different folks. Some are more swayed towards thinking about a solution, and designing it well. Let’s call this breed “natural architects” or “scientists.” Others are more inclined to hack something together (and I mean that in the best possible way), and test it on the job. It’s a bit of a dichotomy between scientists and pragmatists, and both have their place in an effective team. And it is quite possible that both roles can be played by all team members at different times.

To the best of my knowledge, there are no hard and fast rules to determine where to find middle ground. Recognizing this conundrum, and bringing it up for discussion in retrospectives seems the most collaborative way to “test” if all team members are on the same page. And if they’re not –which is fine by the way!– to discuss rules of engagement that can maintain some creative tension within the team, without anyone “going overboard”…

As I have written before, I am thoroughly convinced that diversity in teams “works”: it leads to higher productivity and superior effectiveness. The tricky art is to walk the fine line between “creative tension” and disruptive animosity among team members. Let’s talk about it!


1 comment:

  1. Very well said. That is exactly what makes teamwork so intetesting in itself. The team us kind of a project in itself and needs work before being able to deliver somethong as a product including continuously improvement.

    ReplyDelete