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!
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