Scrum trainings with James Coplien

I made a promise to myself, each time I have a great training with a wonderful teacher, to write about it.  But there is a catch. I must wait for at least one year to see how it impacted my life, both the training and the teacher.

Last year I participated in Athens at two Scrum training classes, Scrum Master and Product Owner one. This year, in spring, I had an online class about Scrum Patterns.

Premises and Context

There were some things that preceded the classes which, I believe, are worth mentioning. Context matters, a lot. So:

– I knew about James Coplien’s work. And by work I mean: programming, software architecture, Scrum, patterns, management, organizations;

– Before the first class it appeared feasible that I might be a Scrum Master at a certain company. And I said to myself that if I will have this honor, then I should go and learn from someone I respected;

– I said ‘architecture’. This was a very important detail. I would have liked to speak with him for 30 minutes about DCI(Data Context Interaction). You cannot imagine  the torment I had and have about this topic which is so important for IT;

– I like programming. I also like testing, as envisioned by Jerry Weinberg (1);

– What I witnessed with managers, scrum masters, companies, clients, teams is that Scrum was not understood. What amazed me was that it was not understood especially by those who considered themselves as Scrum advocates, who were doing coaching/presentations/setting up Scrum, etc. I wish to say something has changed in all these years but I do not have this impression;

Details about the courses

I will try to write about this experience via 3 dimensions. I do this because there are different type of persons which might search or be interested in different kind of information:

structure: the flow of the classes in those days;

key words: as I have done it before, I was curious how I can describe these trainings via some keywords used;

pearls of wisdom: these are insights from the training, words used by James Coplien. You will see that each of the text is within quotes and preceded and followed by “….”. This is because the text has a context(story, experience, people, time, history, feelings, exercise, place). It took James Coplien a good period of time to decipher these. So there is a risk, for the reader, not to decipher the real meaning/lesson/message. I put them there in the hope that it will convince the reader to go at his trainings and find out more;

Structure

Here is the course outline for the Scrum Master course:What is Scrum?

– Scrum history

– Scrum theory, Concepts, Practices

– Sprint Planning

– Production and Sprints

– Velocity game

– Overcoming impediments

– Management distribution and scaling

– Engineering tools and Practices

Here is the course outline for the Product Owner course:Intro to Scrum

– Your job

– The Vision

– Build an organization

– How the product backlog works

– Running the business with a Product Backlog

– Kaizen mind

At first glance it seems just classic Scrum stuff. But no, imagine that all the details/courses were explained/done in a red pill way(2): ”… I can teach you this course in one of 2 ways. One is that you can go back and we’ll call you a Scrum Master, even though you are a project manager. No change to the organization, do the Daily Scrum and say you do Scrum. That’s called the blue pill Scrum …” 

Each time a student had a doubt or posed a question, James stopped and clarified. I would have liked to say that there were only fluffy bunnies but no, only cold showers. I have seen ‘senior’ SM or PO who remained speechless, as if everything they knew no longer applied.

Keywords

There were lots of topics discussed in the courses and I did not know how to describe it in a short and coherent way. But also I hope that these words will trigger a further search in context of Scrum and James Coplien. So:

Japan; Toyota Production System; deep japanese culture; zen buddhism; courage; we can’t predict; (prediction) in software; nature; human kind; harmonizing; value; outcome; self organization; type A,B,C Scrum; respect; consensus; timebox; kaizen; hansei; mura; muda; muri; Scrum scaling; emergent requirements; mercenary developers; enabling specification; trust; continual, not continuous, improvement; chief engineer in Toyota; kaikaku; ISO 9001; proxy product owner; quality Sprint; testing (advising the students to read ‘Lessons Learned in Software Testing’ book ); complex adaptive systems; waste; kanban; productivity

Pearls of wisdom

As I said it is important to mention that these phrases do not have context around them. This is intentional. It is an invitation to dig more, to go to the course. So:

-”… Scrum is not about replacing the Project manager with Scrum Master and the Product Manager with a Product Owner and doing daily Scrum. Is turning the company upside down …”

-”…A lot of Scrum trainers do not understand Scrum…”

-”… Taught right, Scrum is a lot like aikido, it’s a way of life. So is not just about how you do things at work, but how you relate with other people; it’s a world view from how the world works and how we work together…”

-”…Does a complex adaptive system have a root cause?…”

-”…Productivity is the number one cause of waste…”

-”…There is no user story in Scrum…”

– Student: “My team is distributed in 2 continents”

  James Coplien: “…Teams are collocated…”

– “…You can’t promise you will deliver anything in a Sprint…”

-”…we never say commit to a schedule or commit to the content of the Sprint backlog but you are committed to your team…”

-”…You don’t have a chance of prediction in a complex phenomenon…”

-”…No Jira in Scrum…”

-”…Scrum is about controlled failure. Is not going to put you in a happy buble.Is going to make problems visible. Scrum is going to cause you so much pain. There is no magic here, just hard work…”

-”…Outsourced Product Owner is total bullshit…”

-”…Don’t you ever have a quality Sprint, every Sprint is a quality Sprint…”

-”…It’s about people. People working together…”

-”…This myth that it takes a lot of people to build a big product is a myth. Why do we scale? Because we can…”

-”…The Scrum Master is the single wrenchable neck for the team’s delivery…”

-”… The goal is not to do Scrum; at Ri you drop Scrum …”

-”…Please tell me you are not doing SAFe…”

-”…The point is that Product Owners do not work in Sprints. They have a continuous process of market research, exploration,…”

How it helped me

Before all these classes I felt things were wrong on how Scrum was introduced, taught, spoke, presented, imposed, described. But now I know…

I was amazed by the deep things learned about Scrum for the first time, so in 6 months I was in Athena to take the Product Owner class. Also this year I had the Scrum Patterns class. 

When I decided to take the first class I wanted/desired so much also to speak, for some moments, with him about DCI. Of course when possible. And we spoke(in breaks, at dinners) … about DCI, but also about Jerry Weinberg, life, Retsina wine, recruiting, unit checking, scaling, dedication, Alistair Cockburn, OOP, architecture, honesty, Heidegger,…

Next on my list: DCI class(I hope he will make it, I am waiting for it for years), and again Scrum Patterns class.


(1) Jerry Weinberg, https://leanpub.com/u/jerryweinberg 

(2) Blue Pill or Red Pill – The Matrix (2/9) Movie CLIP (1999) HD, https://www.youtube.com/watch?v=zE7PKRjrid4&feature=youtu.be&t=81

About courage

Some days ago Johanna Rothman published a very interesting blog post named What Does Courage Mean to You?

Note: I like a lot her tireless way of writing. 

I decided to reproduce also here the comments I put there, adapted a little bit, and most importantly her insights – I really believe she touched a sensible cord and I hope not only for me. 

At the end of her blog post she says “… Easy to say. Not easy at all to do.

That’s the question: What does courage mean to you?” 

Indeed, not easy at all. When I read her post, 4 things popped up in my head which deeply moved me in the course of time. I will dare to say them. I say dare because this is a deep thing, at least for me, not a fluffy bunny motivational nonsense:

● Giovanni Falcone (sicilian judge killed by Cosa nostra and deviated parts of Italian state): He was asked in a interview(1) if he said the following ‘You said, it seems you said, that: The coward dies several times per day, the brave(‘coraggioso’) just once(‘una volta sola’). This means you do not have fear? ‘ and Giovanni Falcone says’ Well.. important is not to establish if someone has fear or not. Is to know how to live with its own fear and not being let conditioned by it. The courage is this, otherwise it is no longer courage but unconsciousness/recklessness’. 

● Paolo Borsellino (sicilian judge killed by Cosa nostra and deviated parts of Italian state; husband with 3 kids): On the Thursday before his death he received the notification that the bomb had arrived in Palermo for him. Other 3-4 persons in Italy at that moment had a similar big threat at their lives but they left, he stayed. You know what he did? He called urgently his priest for the confession. He wanted to be prepared for the big departure…

● Nicolae Steinhardt (orthodox monk; his ‘Journal of felicity’ book is one of the most precious gifts Romania has; arrested by romanian communists of that time): The authorities tried to convince him to betray his friends. After the first day of the interrogation he returned at home, they wanted to give him time to reconsider. His father (which, in the past, received the Romanian royal order ‘Military Virtue’ and studied with Albert Einstein) asked him why he returned. The father was tough with him(my translation): ‘What else did you come home to, you bastard/you prick(‘nenorocitule’)? You gave them the impression that you were hesitant, that the possibility of betraying your friends could fit. In business, when you say let me think, it means that you have accepted. For nothing in the world do not dare to be the witness to the prosecution’. After some days he had to return at the ‘Securitate’ . Before living the home his father said to him:’And make sure you don’t make fun of me. Don’t be a cowardly Jew and don’t shit in your pants.’ (note, his father was a jew)(2)

● My grandmother: She had 10 years. She was in the orchard with her grandfather, who raised her. We were just occupied by sovietics. A sovietic soldier entered within the orchard. Her grandfather asked him to leave. The soldier wanted to shoot him. My grandmother stood in front of her grandfather. Their luck was that a woman, passing by, speaking Russian calmed down the soldier explaining that her grandfather was the only relative still alive for my grandmother.

So, what does courage mean to me? Well…for me less words. I hope to behave as it should be when needed. Sometimes I have fear that I will not…

I liked a lot Joanna’s reply she said it so nice: “I often see courage in small actions every day… I also realized that we are courageous on a continuum. When we can, we take our fear in our hands and hold it close so it doesn’t blind us. Then, we take that small step to courage. And, when we can’t take our fear? It takes us.” 

After her reply I tried to think at the examples we have in  IT world which I know:

James Coplien says that he, personally, will give a ‘certification’ to a Scrum Master only when that Scrum Master would have lost the job by doing his/her job… And now when writing this, I think this act of his is an invitation to transcend the apparent and even transparent level of Scrum, he raised the bar(is above dailys, meetings , velocity..). Maybe I am wrong with this interpretation, but wow.

● But this applies also when defending an idea day by day. And when I say this I think to James Bach and Michael Bolton and the testing, the one envisioned by Weinberg. Sometimes I feel they are alone in all this IT world which distorted/twisted the idea of testing, but they do not stop. And how easy would be for them to fake and, maybe, do lots of money…

Johanna touched a very very sensible subject which is/was/will be relevant, at least I hope.


(1) Falcone:’Importante non è stabilire se uno ha paura, ma imparare a non farsene condizionare, Giovanni Falcone , https://youtu.be/-Ly9XS4iLj8

(2) Și acum despre frică. Valiza lui N. Steinhardt, Gabriel Liiceanu, https://www.contributors.ro/%C8%99i-acum-despre-frica-valiza-lui-n-steinhardt/

Scrum Master as a complex dynamical attractor

Context

Some years ago I noticed a strange thing when a new Scrum Master was assigned to a team. That team was already formed and just needed a new Scrum Master.  I observed that team before with another Scrum Master. I also observed the new Scrum Master with his former teams. My first reaction was: “How sad. This team will be transformed in selfish team, capable of doing bad things like sabotage. I saw the good part of these people, now I will see the bad part in them “. And indeed, it was like this.

Problem

I was starting to observe certain patterns of influence of people upon groups of other people, with interesting consequences.

At that time I was wondering how I can explain this in a way that it made sense, was coherent, professional and had some bases.

Why this

This was about a Scrum Master,  but I think it applies for Product Owners, managers, ….

This story is particularly important in context of Scrum. I say this because there is an important detail in the Scrum Guide, which is: “…Scrum (n): A framework within which people can address complex adaptive problems…” (1) (emphasis is mine). Here is about complexity theory, it’s deep stuff.

About the word “theory”

We, the IT, have at our disposition an entire body of knowledge from multiple disciplines which can help us a lot. Unfortunately this is, at least in my circles, rather ignored. And we base our ideas, work, actions on some “beliefs” or blindly.

This word “theory” is about science. Some sciences can be very useful in IT: cognitive science, anthropology, complex adaptive systems theory, etc.

We can use practices informed by theory (praxis)(2) in very practical ways in our day to day work. The fact that we know the theory can help us make sound statements/actions about novel and uncertain situations. We can do this because it is about validated knowledge from sciences(2);

In March, this year, I was at the Scrum training held by James Coplien. Everything he said there was not based on beliefs or impressions. He has done his homework regarding the scientific research. He knew how to back up everything of what he said by theory. I hope more Scrum people will follow his example.

This post is about complex adaptive systems theory. At that time, when I was observing the situation described in the Context section, I was looking at it through the lens of complexity theory, more precisely about attractors.

Atractors

Trajectories  that concentrate  on regular/normal patterns define the idea of system’s attractors. What is found in the basin of attraction will have its behaviours constrained/directed/channeled by the attractor, this means increasing the chance of going in one direction rather than in another. The behaviour of the system is constrained by the dynamics of the attractor. (3)

Can the attractors be persons? Of course, parental presence in a children’s party represent an attractor. Just imagine a children’s party with no parent(4). The presence of the parents there will influence what is acceptable and unacceptable behaviours.

Conclusion

● How a Scrum Master is chosen should not be based on frivolous reasons.  I say this because in complex systems, we deal with social phenomena, when developing projects/products, there will always be unintended consequences. Also in complex systems a small cause does not imply a small effect, not at all.

● Strange attractors are and will be present. The fact that the Scrum Master is a good or bad attractor or not attractor at all, will matter;

● I am so tired of seeing Scrum Masters who are chosen just because:

–  is enough that they know how to do reporting;

– the manager choosing the Scrum Master is enticed by the false appearance of words and behaviours of a certain person wanting to be Scrum Master;

– the person is a tester and is cheaper, in outsourcing, to make testers Scrum Masters and not developers;

– that person is very good in platitudes and reproducing the same things which can be put in just 4 A4 pages;

Scrum is not easy to do, is hard and that’s why I saw so many failures with it. I imagine this is because, maybe, lack of knowledge, fear, political games …of course is not a single root cause….

There is a lot more to say, of course. For example, other anomalies can be spotted in the situation described in the Context or in the points listed in how I saw Scrum Masters being chosen. But the intention of this post was to make the connection between 2 things: Scrum Masters and attractors.


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

(2) Dave Snowden,  “Of practical wisdom”,  http://cognitive-edge.com/blog/of-practical-wisdom

(3) Alicia Juarrero, “Dynamic in Action”,   https://www.amazon.com/Dynamics-Action-Intentional-Behavior-Complex/dp/0262600471

(4) Dave Snowden, “The landscape of management: Creating the context  for understanding social complexity”, https://www.researchgate.net/publication/228449006_The_landscape_of_management_Creating_the_context_for_understanding_social_complexity

Scrum Master – a view based on my experience as a developer

I am a little disappointed when I look around, and I see that many decisions that involve me, are taken by persons who will not handle the consequences directly, and all of these without asking me for an opinion. Is like I have to drive a car, but another person would position the seat the steering wheel,  and the rear view mirrors, without asking me if I reach to the pedals, if I am able to orientate myself in space by looking in the mirrors, etc.. and on top of that, that person would not even be in that car with me, when I will be on the road. I am not talking about the decisions related to what types of electrical wires to be used when the car was designed, or the size of the electrical fuses… but some small details that depend on the context.

A scrum master is a facilitator for an agile development team. There are multiple areas where there are facilitators, even though they are not called Scrum Masters. For example, in the automotive industry, one of the examples might be FMEA Coordinator.  

From my point of view, the technical expertise of the Scrum Master is a plus… it can be compensated by viewing the things applied to the context of the team but being technical or willing to understand the technical part would certainly help. My opinion can be influenced by the fact that I am a technical person. But here is why I consider this:

●  Having a Scrum Master with Technical Skills doesn’t mean that she/he should be involved in technical decisions, but it might be more comfortable knowing the fact that if needed, she/he can give an advice, or change her role if needed. On one hand it is an advantage to receive a verbal advice, but sometimes, a more involvement by the person who wants to help might do the difference – if that person knows and understands the context, perhaps with his/her experience might directly help in solving the encountered issue / difficulty. The way I see it is like traveling a lot on mountains, during the cold seasons, and having an emergency blanket.

This does not mean that you should use it every time. You can even decide that you won’t buy one, because you don’t see the benefit. But in a lifetime, there might be 1-2 situations where you could have used it (for you or for somebody else) and then having it on you might represent the difference between life and death. Of course, like having a Scrum Master with technical would not 100% solve all of your problems, same with the emergency blanket: It does matter to take it with you – it is not sufficient to buy it and leave it home when you are traveling, or to carry only the emergency blanked.

●  I practice ski touring. This allows a person, during the winter season, to follow paths on mountains, for example, uphill and downhill as well. In the safety equipment it is recommended to have with you, among other items, an avalanche transceiver. This is a small device that emits a beep sound on a certain frequency, and the signal becomes stronger as the person who is looking for you is getting closer. It is used, as the name implies, in finding avalanche victims. You carry it with you on emitting signal while you travel, and if you notice an avalanche, you might switch it on search mode, and try to find the victims as fast as you can.

I’ve told you about this, because I see a parallel in Scrum framework as well.

It is very good for a Scrum Master to know and understand her role very well, and all the needed steps described, but sometimes I think that these should be applied according to the context. For example, a transceiver would not be very useful if you are alone in the mountains and you are caught by an avalanche. So, if you are in a similar situation, you should pay attention to avoid as much as possible a disaster. What I mean is that you might be 100% covered by the book and definitions, if the context is not favorable for you, then you should adapt and not only rely on what you’ve read / experienced / known before. In a team context, applying for example Scrum Guide ad-literam, might bring frustrations and stress among the team members.

A scrum master with technical skills can cooperate easier with the product owner and expressing him/herself from the point of view of a scrum master, but also considering the technical part and intervene in order to prevent some things that can go wrong in that project.

The main purpose of a development team is to build a software product that meets its users’ expectations, in the minimum amount of time, and with very few or none defects – of course, this is the ideal solution. The main purpose is not to write automatic checks… or to decide to use story points when estimating stories / epics / tasks that are centralized in a tool; – these decisions should be taken considering the team’s opinions, and adjust them according to the needs, without abusing them, and of course to be applied on the context.

It is nice to have a sprint planning / retrospective / daily meeting (and useful sometimes), but not necessarily when you have a team of 1 person for example. Or even a team formed by 2-3 persons that can communicate and coordinate so that there is no need to have some of those meetings.

I have worked with Scrum Masters that were technical and Scrum Masters that were not technical and had positive and negative experiences with both. But, in my opinion, the issues were because some were operating by the letter of the law instead of operating in the spirit of the law:

● In most situations where the development team is too deeply involved in finding a solution for something that does not work, just talking with someone else would help a lot in unblocking the situation.

If we talk with a person who is not 100% involved in the development of the product, we might find alternative solutions, that as a team we somehow missed, guided by not looking at the problem from a critical point of view.

By not being involved 100% I mean that has some knowledge over the project, but it does not specifically work to develop / test it as a daily basis. That person could be for example, the Scrum Master. If she/he has some technical background, already knows the product, and some of the issues that we already encountered as the time passed by. 

● There are some parts of the management of a project that might be easier to be aligned, accomplished, and applied when the Scrum Master is a technical person, because she/he knows some things from both domains. She/he does not need to be an expert but can help a lot if she/he has some ideas.

A technical scrum master can cooperate easier with the product owner and expressing him/herself from the point of view of a scrum master, but also considering the technical part.

● A big minus is that by at least not trying to understand the process, to discuss it with the team members, and instead doing things by the book, can lead to uncooperative environment, and doing some things for the sake of being done. We are not robots, so we can think freely, depending on our previous experiences, of course. There is a saying: « beware of single source people who do not have an open mind. «   Ok, you may know exactly the words that describe a process, if you are not able to adjust it according to a context, then It might be better not to apply it at all or to ask for support.  

Perhaps this might be one of the scrum master’s role – to defer / avoid using things that do not make sense for the entire team. Maybe I’m wrong… but by not doing this, it might bring some frustrations among the team members, sometime this can reflect in management and in the overall result as well.

A flexibility can be part of the solution and apply things not blindly but depending on the context. In order of this to happen, a lot of experience is needed along with an open mind and courage to stand out of the crowd and work for the company / product / client / colleague’s benefit.

Discussion on caring about teams and people

At the apparent level it seems it’s a vague discussion, but it is about Shu’s internal fight, on how to choose between people. People that are so important to Shu. And actually, even with all scenarios, Shu will lose on some level.

Ri: What is happening?

Shu: <<a sight>> I am not good in having a team.

Ri: In having a team?

Shu: Yes. You know..as Scrum master or ….whatever…. You choose the title…

Ri: Why?

Shu: It hurts a lot when the members of the team are no longer near me.

Ri: Hmmm. Why do you say that?

Shu: I can’t handle it when I loose a team, or members of a team. It hurts like hell. If I would know they are ok, then it would be ok – it’s hurting only because of my ,let’s call it, “selfishness” :(.

Ri: For those who are ok, you can’t and you shouldn’t  do anything… just to accept it…,but it’s ok to miss them.

Shu: Yes

Ri: And for the other ones, what are you going to do about them?

Shu: You know…if I wouldn’t have known that you care about me, I would have told you to f..k off with that question.

Ri: Hmm. I suppose you’ve heard it asked in pervert ways too many times.

Shu: Yes. Along with a lot of other questions/remarks…

Ri: So….?

Shu: I feel I should fight for them. But I will most probably lose.

Ri: Will it hurt?

Shu: Yes, it will hurt like hell. You cannot imagine, because there are other people, dear to me, who need me and I care about them a lot too.



Ri: Do you think you can do something which is correct also for the others and for the team, but not for you?

Shu: Yes, but I think, it will hurt me really bad and I will lose.

Ri: Hmmm. Then, I think, you know what you have to do. But you’ll suffer.

Shu: Hmmm. Yes.

Ri: Good then :)), at least you’ll have something to share, when you will be older. But you forgot something…

Shu: What?

Ri: What if you would have chosen the other people, who need you, and the result wouldn’t have been ok either? And by ok I mean that it wouldn’t turn out the way you desired it to?

Shu: <<is sad…he/she did not think about this>>

Ri: It seems it’s not about the fact that it’s easy to have a whatever team. It’s about the fact that it’s a big deal to have a team, a real one.

Scrum master – a sad story

Shu: I want to become a Scrum Master.

Ri: Why?

Shu: Because it’s easy, look at them, at their daily work: organize some meetings, make some reports and that’s it. Oh I forgot about motivation, pardon, pseudo-motivation.

Ri: Do you think that’s what a Scrum Master has to do ?

Shu: I’m not saying that this is what they should be doing, but what I have seen them doing, in the companies that I worked for.

Ri: No Shu, if you want to be a Scrum Master, you need to be a good one. Why would you want to be like that?

Shu: Because it’s easier, and because this is what most companies want, good reports. You have to have good Excel skills(or other similar tools), to present the stats of the project, and you will be the best Scrum Master for that company.

Ri: It’s not like that…

Shu: I saw Scrum Masters who encourage the team members to put working hours on tasks, which look good on reports, no matter if those hours tell the truth about the work to be done. It’s all about a nice burndown graphic.

Ri: Really?

Shu: Yes. I can give you an example, something that happened to me once: in a daily meeting the Scrum Master asked me how long it takes to finish that user story. I told him that I need 16 hours to finish. Can you imagine what the answer was?

Ri: No…

Shu: He puts 8 hours down and told me: there are 8 hours until the sprint is done, you have to manage with that.

Ri: That’s strange.

Shu: Yes, it is, but they want to send nice reports to management. But in some cases the management is surprised to see that the project fails, even if they received good reports all along. Unfortunately, this kind of situations, don’t raise a flag and, that in my opinion is sad.

Ri : I understand what you are saying, but if you see this and don’t like it, and don’t agree with it, why do you want to be like them?

Shu: Anger

Ri: Hey… You said that you don’t agree with the image that those Scrum Masters have, about their work, right?

Shu: Yes….

Ri: So….?

Shu: I know…I don’t have to act like them, and this applies no matter the position you have in the team: scrum master, developer, tester…

Ri: And…?

Shu: If I want to be a Scrum Master, I’ll have to act based on what I know a great Scrum Master should do. I don’t have to do things that I don’t agree with, only to have that position. But this would also mean that, maybe, for that company, I am not a good Scrum Master.

Ri:….<<a sigh>>…

Shu: hmm…, to be a good Scrum Master is hard as hell. So, actually, the fact that a Scrum Master is acting as they should, might be the reason why she/he might not be a good fit for the company.

Ri: When you want to solve problems, things get messy, really messy. It’s not about fluffy bunnies. I hope you’ll not be that kind of Scrum Master who in retrospectives, or in talks with their managers, does not have the gut to call things by their name, and instead be full of platitudes.

Shu: ….<<a sigh>>…

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

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