In my circles, I see lots of confusions/discussions regarding what a SM should or should not do. I already wrote before about the need of a SM for a project. Sometimes I feel this role is trivialized, that is being used as excuses of not doing things.
“Most arguments seem to be about conclusions, when they’re really about premises”(1) . So the premises:
● Beside the role as a SM or PO, it might happen that the organization will consider the SM or PO also in a position of middle management (PM, TL). But the discourse regarding PM/TL is changed a little bit: The PM/TL has to take care the project is OK, whatever that would mean…
This might contradict the Scrum thinking/philosophy, but this is another story. The idea is that we have to deal with this reality and acknowledge it.
● The Scrum Guide describes SM relation with PO, team and the organization. The Scrum guide might seem simple, but actually I feel it as a rather exceptional condensation of a lot of information. Take for example just the word “facilitation”, I think days can be spent only on treating and understanding this word.
I have some, let’s say, rhetorical questions:
– Shouldn’t a, good, really good, not mediocre, SM understand PO work in order to help him? By this I mean, maybe, to acquire skills of PO. The better the SM understand the PO, the better SM he becomes because he’ll be able to be more helpful for PO (and subsequently for the team);
– Should the SM help the team by removing impediments and creating high value products only by ‘organization means’ and by encouraging them(being supportive)? Where is his personal touch? By ‘organizational means’ I mean that the organization should help the SM no matter the problem, of course via standard tools/ways of working to solve the problems. SM should be creative, be autonomous and adapt solutions to the specificity of each project.
How the SM will really coach the team in self organizing and cross functionality if it does not participate in the current work? Should encouraging with platitudes be enough? Bringing others to do it? Hmmm….Maybe encouraging without facts and actions will have a small impact.
What I want to say is that, maybe maybe, we need to consider that a SM should be also technical. By technical I mean a developer or a tester(I belong to the Rapid Software Testing testing school just to be clear what I mean by tester) or …, so she/he can take info not only from others(like horoscope) and numbers(we are mature people still)(4). I think I would phrase it more generally that they should be with the “skin in the game”.
Yes is possible to have the non-technical SM…but…but…this will be helpful, for SM, as rather than rely entirely on the input of the others, SM will be able to make his/her own assessment based on his/her experience and validate it and not take it for granted.
I saw that in delicate situations where a project must be saved a good multi-skilled SM is being put into play, when the others kind of SM are being let aside maybe because is safer…
I feel there is a tendency to put as SM people with no or little experience/knowledge but with good discourse…. – that’s why I am tough! I try to imagine a surgery team in a hospital organized by Scrum, then the SM for that surgery can be the physiotherapist? Just to be clear: Scrum is good, but in the proper boundary.
● Tuckman model(*) of team formation and development. The situational leadership model is changing depending on the stage the team currently is in. So it might be directing or coaching or supporting or delegating. So within the same Scrum team the tactics of SM might or should change.
● Last, but not least, I think is imperiously needed to be aware of the “multi-ontology sense making”(2). I like that this invites us to transcend the type of system we are in. Scrum, in Cynefin(3) parlance, is at the boundary between complex and complicated. But a dynamic of project/situation will not always stay in a certain type of system. What if suddenly from complicated the type of the situation will change between chaos and complex. What should a SM do? Stay and use the techniques/tactics for which Scrum is designed? Shouldn’t try to adapt and consider the appropriate techniques/tactics/measures of action for the corresponding type of system? Ok, it will no longer be SM by the book, so?
So, I hope to see more SM’s:
○ who are very well prepared;
○ that stop using platitudes;
○ that know about Nonaka work ( even if they my not agree with some of his work );
○ who know the work of Jim Coplien (dailys are his idea/inspiration from Scrum; and the technical book he wrote “Lean Architecture: for Agile Software Development” is great);
○ who stop trying to be pseudo-psychologists;
○ who understand that to be a coach/mentor requires preparation, lot of it;
○ who understand that agile does not equal Scrum;
○ who dare to ‘dirty’ her/his hands and to help the team by working effectively in the project, of course, making use of the skills they have when she/he thinks that the benefits of this action are bigger than the possible disruptions;
○ who will have no problem to let another one be SM and she/he be a simple member of the development team, at least temporary;
○ who will realize that she/he is Master not after a few days of training, but after years and years of work and preparation;
○ who understand the job of a developer and the job of a tester, and then realize that you cannot switch one with another with the excuse of self-organization;
I know there are other schools of thought and is ok. I accept their opinion, but this does not imply that I also agree with them. Context matters a lot.
(*)Update February 27, 2018:
I indicated Tuckman model because in the agile world is a very known model. My intention was to show that a team is not in a single state at all, but on the contrary.
I reviewed the original paper where Tuckman wrote about this. Actually this model is not proven. In the initial paper “Developmental Sequence in Small groups”(5) he reviewed the existing literature regarding “dealing with developmental sequence in small groups” and he suggested “fruitful areas for further research”. So is a “statement suggested by data presented and subject to further test”.
Ten years after the original paper was published another one was published, “Stages of Small-Group Development Revisited”(6), in order “to examine published research on small-group development done in the last ten years that would constitute an empirical test of Tuckman’s hypothesis”. In the conclusion is stated that “It is noteworthy that since 1965 there have been few studies that report empirical data concerning these stages of group development…There is a need to supply statistical evidence as to the usefulness and applicability of the various models suggested in the literature”
(1) Michael Bolton, “Testing, Checking, and Changing the Language”: http://www.developsense.com/blog/2009/09/testing-checking-and-changing-language/
(2) Dave Snowden, “Multi-ontology sense making; a new simplicity in decision making“ http://cognitive-edge.com/articles/multi-ontology-sense-making-a-new-simplicity-in-decision-making/
(3) Dave Snowden, Mary E. Boone, “A Leader’s Framework for Decision Making” https://hbr.org/2007/11/a-leaders-framework-for-decision-making
(4) James Bach, “No KPIs: Use Discussion”, see comments, http://www.satisfice.com/blog/archives/1440
(5) Bruce W. Tuckman, “Developmental Sequence in Small Groups”, http://dennislearningcenter.osu.edu/files/2014/08/GROUP-DEV-ARTICLE.pdf
(6) Bruce W. Tuckman Mary Ann Jensen, “Stages of Small-Group Development Revisted”, http://openvce.net/sites/default/files/Tuckman1965DevelopmentalSequence.pdf
