Scrum – Page 2

Do Scrum Masters/Agile Coaches need a technical background? – Part 2

In the first part I gave a short answer to this question. I have also wrote here and here about the nature of the Scrum Master.

Now I’ll try to give the long answer:

A person asking this question lives in a certain context. In that context, certain events pop up, events that trigger this kind of question. Different answers might appear, answers that are based on premises. Sometimes, those premises are not made explicit, because not everything which is implicit can be made explicit.

For me, this question activated multiple dimensions in my mind: Scrum, Scrum Master, XP, XP Coach, technical background meaning, agile coach meaning, team maturity, processes/management, complexity, utopia/ideal. So:

– Scrum Master, as it is defined in the Scrum guide(1), doesn’t have any activities regarding technical stuff that need to be made. The SM has to take care of how Scrum is applied, and make sure it is made according to the Scrum guide, so no technical background is being mentioned;

– Scrum wants to be a more general purpose framework for developing (complex) products. For example, regarding software products, Scrum does not address anything regarding technical aspects nor does it prohibit any such aspects – actually it borrowed a lot from XP;

– XP(Extreme Programming) came with the idea of a coach(2) first, even before the scrum master was defined(*). XP was designed especially for software development work. It contains specific technical activities connected in a special way. It’s not like one chooses a technical activity at the expense of another one;

– A coach in XP had to defend the process, but the process is quite different: the coach must help the team maintain the disciplines(pair programming, refactoring, metaphor, continuous integration…). This position would be a rotating one meaning that the coach needs to be someone who knows how to apply what he defends, not just by using words/encouragement/…;

– XP has the same non-technical “protocol” as Scrum;

– Maturity of the team: This is an important detail. Reality seems to give us lots of surprises, challenging ones. This means that an immature team can pose difficult challenges. If the team is mature enough then SM/Agile Coach is no longer needed or is only partially needed, so in the rest of the time, he/she can help other projects or do actual work in the same project;

– Agile Coach: This is, for me, a very abused title. I’m sure that there are damn good agile coaches out there, but most of the time, I only see fake/charlatans/unprepared/naive agile coaches. When I read Agile Coach, I thought of XP, because this role is explicitly mentioned there. Now I know that not everyone can be like the agile signatory guys, or like the grandfather of agile Jerry Weinberg, or like Allen Holub, or like Jim Coplien, … but they do raise the bar for a person calling himself/herself an agile coach. I cannot accept that an agile coach doesn’t know about the work of all the people who were there in Snowbird in 2001;

– Process, management: It seems that in management, after so many years of agile, there is a tendency to put process first and people second, when it should be the other way around( of course ontology matters, but what I see is that there is always a single and identical ontology approach). In Scrum, the role of a SM can be filled in by anyone, I say this having in mind that this role is not so restrictive/specific/targeted like for an XP Coach. I am so tired to see/hear this scenario: “As long as a person is able to speak about processes/platitudes/nonsense, but in a very well masked way, that person is good enough to be a SM. The discourse is not aligned with the aptitudes.” → unfortunately, because of this, SM became, at least in my circles, ridiculed. I am very well aware that the problem is not Scrum but how it is applied. Maybe all this is deliberate, I mean why “sacrifice” a good developer, when some unskilled, but good with processes person can be put as SM/Agile Coach.

Moreover, SM are actually in management position, seen as PM – if this is ok or not is a different story, but it is happening;

– Complexity: XP and Scrum offer different conceptual boundaries. This means that also actions will differ.

– Technical: For me, initially, technical referred to the programming stuff beneath a software project. But, maybe, the “technical” word is actually about:

what SM/Agile Coach can do to help actively(within a specific task or story) the team in their work;
how to get the information directly via his/her skills;
special work without which things would not be ok, but which is very close and very important to programming, like testing(Rapid Software Testing).

This means “technical” might be translated as being aware of the technicalities of each discipline in delivering the needed work.

– Utopia/Ideal: There are too many discussions about the ideal situation, ignoring the crude reality/present. Maybe the focus/managing should be on the present, the situated present(3), and this might influence what a SM/Agile Coach should actually do, instead of doing just what is prescribed in some guides. If this means being proactive, go beyond what he/she knows, have initiative, try to understand the details of the work of his/her team, do some work on the project then why not…

Conclusion: What I have tried is to show the multiple dimensionality of this problem. It’s not easy: we have history, methodologies, management, processes, reality/multi-ontology, utopias, expectations.

We have to see beyond a certain guide, or methodology, or situation. A SM/Agile Coach has a special role/meaning/importance in and for a team. The “Master” title means mastery, leading, experienced, great, cognoscente; a “coach” means teaching, training….We need to face the reality and see what works and what doesn’t and respond accordingly. How can a SM/Agile Coach respond to the multi-ontologies if he/she is not prepared? Yes, I am raising the bar because I saw too many clown SMs or Agile Coaches that follow a certain recipe and respond with platitudes and say “that’s it, my job is done”.

So, Does a Scrum Master/Agile Coache need a technical background?

I would say yes, among other things. Can I accept the fact that there can be exceptions ? Yes, but I hope that the SM/Agile Coach can really make up the lack of technical background with other skills.

(*)Update February 25, 2018: I made a mistake above in the sentence “XP(Extreme Programming) came with the idea of a coach(2) first, even before the scrum master was defined. ” . → Thank you Jim Coplien for your feedback:

“Well, no. Scrum had the ScrumMaster role in 1994. Mary Rettig was the first ScrumMaster and it was at Easel Corporation.

XP didn’t even exist until quite a few *years* later.“

(1) Scrum Guide, http://www.scrumguides.org/scrum-guide.html

(2) Robert C. Martin, “The Agile Team”, https://cleancoders.com/episode/clean-code-episode-50/show

(3) Dave Snowden, “Managing the situated present”, http://cognitive-edge.com/blog/managing-the-situited-present/

Do Scrum Master/Agile Coach need a technical background? – Part 1

Short answer: I try to see/imagine how things work in other industries/jobs that imply building something. For example: army, surgery, accounting. I suppose for each of them, there are some processes/methods that are put in place. But there are also very important technical aspects. Of course, what technical means in the army is different from what technical means for surgery – but I think the technical part matters. So would it make sense for a person, with an important and distinctive role in the team, to have no technical knowledge? Probably not…Answers to similar questions already exist in other jobs/domains, that are much older.

A longer answer will be published in a future post.

What a Scrum Master should or should not do

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

A fallacy when estimating in Sprint Planning

Usually, in sprint planning comes a moment when developers and testers have to give an estimation. After the tasks seem to be clear, the testers and developers give their corresponding story points. What seems strange to me was the fact that these estimations are calculated and a single number is created.

For me, this approach seems like comparing apples with pears and then generating a number.

I imagine a lot of agilists will say that this is working. I would say: maybe. What gave them the impression it works? Well, I saw that human nature is capable to cope with formal non-sense, so that, then, informally, make it work, one way or another. Why? Well, because, sometimes, a lot of energy is lost in convincing some people of some strange truths. Truths that are not in trend but for the moment might seem easier to cope with. Why? Well, because of laziness, fear, workload, or just because it’s safer….

For me, developers and testers worlds are very different. Yes, these worlds can intersect somehow, but they are still very different like two oceans uniting/meeting each other.

For a developer, when he/she knows what to solve and how to solve it, the task is easy, and the code is written. That code should behave in a deterministic manner. The developer might write unit tests and/or integration tests – from a tester perspective these are automated checks not tests(1). And when I say developer I am thinking of an XP developer, of a developer who should aim at what Uncle Bob says(2).

For a tester things are different. Although things might appear to be clear for the same story, we might deal with non-determinism. When I say tester I am thinking of a tester who is part( consciously or unconsciously) of Context Driven Testing(3) school, for example a Rapid Software tester(4). Testing actually poses a need for a very different skillset because the problems the tester encounters have a different nature, compared to the ones a developer faces. So even if a developer has modified just one line of code, a tester can spend days and days if she/he decides to make a deeper testing, and not just a shallow one. Why? Because the code is, usually, surrounded by a larger code context that might affect the stability of the product. But if is just one line of code, why would it take a lot of time? A small cause can have big effects. For example, does the developer know with great precision all the details, internal technical details of the code? A simple data type problem can cause one of the strangest and ugliest effects and it all starts from just one line of code.

Therefore, I think we should be careful what we do, and we shouldn’t be reluctant to raising questions, even if we might be wrong. I consider this approach of combining numbers that mean different things, a fallacy. For me, this is an oracle(5) to spot the problem and, why not, I have a name for it: Two oceans integration.

(1) James Bach, “Testing and Checking Refined“: http://www.satisfice.com/blog/archives/856

(2) Robert C. Martin, “The Programmer’s Oath”: http://blog.cleancoder.com/uncle-bob/2015/11/18/TheProgrammersOath.html

(3) Context Driven Testing: http://context-driven-testing.com

(4) Michael Bolton, “What Is A Tester?”: http://www.developsense.com/blog/2015/06/what-is-a-tester/

(5) Michael Bolton, “Oracles from the Inside Out, Part 1: Introduction”: http://www.developsense.com/blog/2015/09/oracles-from-the-inside-out/

“Should we just give up on the Scrum Guide? Nobody’s read it”

Allen Holub published an interesting post:

“Should we just give up on the Scrum Guide? Nobody’s read it.

To me, the Scrum Guide is the definitive definition of Scrum. However, I’ve found (by asking many people, sometimes very large groups at conferences) that most Scrum practitioners have not only never read the Guide, they’ve never even *heard* of it. Put another way, Scrum as practiced has little or nothing to do with the Guide. So, given that, is the Guide even relevant? I’m just as guilty as most in quoting chapter and verse when somebody says something ridiculous about Scrum, but more often than not, the thing they’re touting (story points and velocity, for example, or “sprint commitments”) is considered central to Scrum by the vast majority of practitioners, even if it’s either not in or is in direct opposition to something the Guide says. Given that, do you think that it’s worth referring back to the Guide, or should we just define Scrum as what people actually do and get off our high horses?”(1)

I deeply agree with Allen Holub. I am, as personal experience, also amazed by this. Each time when there is a discussion regarding a certain topic related to Scrum I advise them to open the Scrum Guide and have it as reference.

But even after it is being read, by some, did they really understood it? For example in the Scrum Guide there are lots of interesting and deep topics, for example:

– “complex adaptive problems” -> this points to an entire discipline regarding complex systems;

– “Facilitating” -> A two days workshop can be made only to understand what facilitation is.
Arie van Bennekum, co author of Agile Manifesto, does this. Interesting and deep thoughts also Dave Snowden has about this subject.

And these are just two examples from the Scrum Guide.

But is even more, I speak about history of Scrum like writings of Nonaka.

I begun to have reluctance of the so called Agile Coaches who actually know only Scrum but when you dig deeper actually they do not know about Scrum neither.

But a bigger problem is that a lot of people in industry think Scrum=Agile and is not like this at all. Scrum has it’s place like the other agile methodologies.

So, ‘Should we just give up on the Scrum Guide?’ I hope not. We should encourage people read the Scrum Guide and then to think upon it. Is useful, it provides a common ground when speaking about Scrum. Also, I consider the guide a very condensed/compressed information waiting to be unrolled.

(1) Allen Holub, “Should we just give up on the Scrum Guide? Nobody’s read it.”: https://www.linkedin.com/groups/37631/37631-6340348761025454083

(2) Scrum Guide: http://scrumguides.org/scrum-guide.html

Agile Project Manager?

In 2001, in Snowbird, when Agile was defined there were also representatives from FDD(1), DSDM(2) you can see it in agile manifesto history (3).

Try to search for Project Manager in the FDD and DSDM references….

So, if I am following a good logical deduction actually “Agile Project Manager” should make sense. I think Agile Project Manager does not make sense because we are still not able to transcend certain things.

Now we’re still speaking in terms of Scrum Masters and Agile Coaches and …. unable to accept things which existed from the beginning and still exists, if I can say so.

I wonder how many of so called agile folks know/read/understood or even applied FDD, Crystal, DSDM, XP….

Side note: When I speak or hear discussions about Scrum, especially when Scrum Master(s), Scrum Coaches, PO’s, management people are present, these 3 words pop into my head: “complex adaptive problems”(4). These three words combined in this way is a condensed information of an entire discipline. Are they aware of this? If yes, should this be seen in their actions?

(1) FDD: http://www.nebulon.com/articles/fdd/latestprocesses.html

(2) DSDM: https://www.agilebusiness.org/content/roles-and-responsibilities

(3) Agile Manifesto, history: http://agilemanifesto.org/history

(4) Scrum Guide: http://www.scrumguides.org/scrum-guide.html

We need a Scrum Master

Shu: So, we need a Scrum Master(SM) on project Z

Ri: Are you sure you need a SM?

Shu: The other one left….So we need someone to take care of the team and make sure the project will be ok…so yes.

Ri: Hmmm

Shu: What?

Ri: Isn’t that too restrictive, just a SM?

Shu: What do you mean? It’s a Scrum team, so we need a SM since the other one left.

Ri: Yes, but you also need a person to make sure that things will be ok, a person you can contact when things go wrong

Shu: Yes, a SM

Ri: Don’t you feel a divergence?

Shu: Divergence?

Ri: When you say “SM” and to “make sure the project is ok”, you practically define how the project should always be managed. Aren’t you limiting what she/he should do, although you want much more?

Shu: Its Scrum. Its clear/standard stuff. Everyone knows what to do and what to expect.

Ri: And what will happen when ontology changes? What will be her/his epistemological response? Can you be more clear in your need?(1)

Shu: Ha? Why did you use those words?

Ri: Because of neuroscience. By using those words I tried to activate different neural patterns so maybe you will see things differently. Look, its simple: ontology – a type of system; ontologies – different types of systems. Epistemology – how we know stuff. (1)

Shu: So I need someone to take care of the project but who is able to play also the SM role when applicable or whatever. To be aware of the different ontologies, to transcend them.

Ri: Are you sure? I’m kidding. Its better. At least you tried to understand what you need, and you also started to challenge what you know and what you need to know about a SM.

(1) 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/

(2) Alistair Cockburn, “Shu Ha Ri”: http://alistair.cockburn.us/Shu+Ha+Ri