The Team, the Product and All the Rest

There is a fun­da­men­tal mis­un­der­stand­ing around agile. This mis­un­der­stand­ing begins with the title of the Man­i­festo for Agile Soft­ware Devel­op­ment. For too long, many con­sid­ered soft­ware devel­op­ment to be the trans­la­tion of spec­i­fi­ca­tions into code by inter­change­able pro­gram­mers com­plete­ly dis­con­nect­ed from their cus­tomers and their prod­ucts (and often rein­forced by con­tracts). And this is exact­ly what many still under­stand by soft­ware devel­op­ment nowa­days. Only in short­er cycles. Sim­ply agile. But the authors of the man­i­festo, all pas­sion­ate soft­ware devel­op­ers, were con­cerned with some­thing else. They tried to put soft­ware devel­op­ment back at the core of val­ue cre­ation and to elim­i­nate all the waste around this core, all the heavy-weight process­es and their man­i­fes­ta­tion in orga­ni­za­tion­al struc­tures. Their aim was to build soft­ware as a long-lived team real­ly own­ing the prod­uct. And there must be no mid­dle­men between team and cus­tomers with cor­re­spond­ing arti­facts and han­dovers. Instead, busi­ness peo­ple and devel­op­ers must work togeth­er on a dai­ly basis to explore the mar­ket, the prod­uct and the solu­tion space together.

The mis­un­der­stand­ing of this orig­i­nal inten­tion of the Man­i­festo for Agile Soft­ware Devel­op­ment is reflect­ed in many scrum adap­ta­tions in the role of the prod­uct own­er. Where he or she should ide­al­ly see them­selves as prod­uct man­agers or as the CEO of the prod­uct, he or she often only col­lects require­ments and spec­i­fies them for the devel­op­ment team so that the devel­op­ers can con­cen­trate on devel­op­ment. You can call it agile, but it is not in line with the authors of the manifesto.

Because mem­bers of the project team stay in close touch with out­side sources of infor­ma­tion, they can respond quick­ly to chang­ing mar­ket con­di­tions. Team mem­bers engage in a con­tin­u­al process of tri­al and error to nar­row down the num­ber of alter­na­tives that they must con­sid­er. They also acquire broad knowl­edge and diverse skills, which help them cre­ate a ver­sa­tile team capa­ble of solv­ing an array of prob­lems fast.
Hiro­ta­ka Takeuchi und Iku­jiro Non­a­ka in The New New Prod­uct Devel­op­ment Game

This 1986 arti­cle by Takeuchi and Non­a­ka is con­sid­ered to be the ori­gin of Scrum. As the quote shows, even then, 15 years before the Man­i­festo for Agile Soft­ware Devel­op­ment, their research showed that a con­stant and inten­sive con­nec­tion between the team and the out­side world was need­ed in order to joint­ly gain new insights in a con­tin­u­ous process of tri­al and error. This joint explo­ration of the prob­lem domain is one facet of what Tackeuchi and Non­a­ka called “mul­ti­learn­ing”. The oth­er facet of this is a learn­ing cul­ture in which every­one is con­stant­ly striv­ing to share knowl­edge, broad­en their skills and become experts in sev­er­al dif­fer­ent dis­ci­plines. This is exact­ly what makes inter­dis­ci­pli­nary teams fast and effective.

A bad sys­tem will beat a good per­son every time.
W. Edwards Deming

In addi­tion to a prod­uct own­er as CEO of the prod­uct and prod­uct devel­op­ers with skills in var­i­ous dis­ci­plines, how­ev­er, a third group is need­ed. It takes peo­ple who are able to ana­lyze the dynam­ics of com­plex orga­ni­za­tions and opti­mize them holis­ti­cal­ly from a sys­temic point of view, and who also have the pow­er to do so. This sys­tems think­ing there­fore should be the top pri­or­i­ty of senior man­age­ment. But this skill also should be manda­to­ry for every Scrum-Mas­ter, who is — and this is the sec­ond big mis­un­der­stand­ing in many Scrum adap­ta­tions — not only facil­i­ta­tor and sec­re­tary of the Scrum events, but pri­mar­i­ly ana­lyzes and improves the pro­duc­tiv­i­ty of the team as part of the sur­round­ing orga­ni­za­tion from a sys­temic point of view.

Share This Post

By Marcus Raitner

Hi, I'm Marcus. I'm convinced that elephants can dance. Therefore, I accompany organizations on their way towards a more agile way of working. Since 2010 I regularly write about leadership, digitization, new work, agility, and much more in this blog. More about me.

2 Comments

You do a real­ly good job Mr Reit­ner. Under­stand­ful tex­ting, great con­tent. Thank you 4 teach­ing me and others…

Your blog gives peo­ple who are inter­est­ed in con­stant­ly learn­ing and grow­ing very usfull things. Top­ics like dig­i­tal­i­sa­tion and col­lab­o­ra­tion have to be teached in the ear­ly schoolyears …

Vik­tor Ott

Leave a Reply