Tacit knowledge, testing, requirements, management

Have you ever wondered why it does not make sense to ask or expect  for complete written requirements? 

Do you know why trying to write all test cases to capture the testing needed to be done will bring you to a dead end? 

 

Sometime ago I worked on a big project. There were about 50 people involved. These people were divided into various teams. And these teams handled various products from the entire suite.  

One of those products was hard to install. Imagine that simple settings that could be saved in a config file, like xml or json, were saved in windows registries. The installation of the suite in production was a ‘special’ event on its own. I use the word ‘special’ not in a good sense. Each time an install was being done; people were awake in the middle of the night to stay to test it. But this was one problem in a sea of problems. 

One day, the man responsible for the product installation announced his resignation. His resignation worried me. I asked my colleagues in the office. They weren’t worried. They said, “it’s a different situation, but look, the man who is leaving also writes in a wiki. So, it will be ok”. They had the impression that all what is needed will be made explicit. 

For me this did not make any sense. Not all knowledge can be made explicit. We have a lot of implicit knowledge. Harry Collins in his wonderful book named Tacit and Explicit Knowledge explains why. Imagine that knowledge can be represented like an iceberg. What is above the water is the explicit part and beneath the water the tacit part. So:

  • weak or relational tacit knowledge – Is tacit because of the relationships between people that arise in a social life context. For example:

* concealed knowledge – knowledge which is kept secret intentionally;

* ostensive knowledge – knowledge which is hard to be described/comprehended. Because of that we point to a word, object or a practice to describe it;

* logistically demanding knowledge -imagine a person who knows where everything is, but would not be able to list it if asked), 

* mismatched silences – knowledge kept secret without intention;

* unrecognized knowledge – a person is doing certain things in certain ways. This person would not tell another person because it might not know if these are worth to be told for the second person.

  • medium or somatic tacit knowledge – is tacit because it is incorporated in the human body. How we type, how we juggle, how we balance on a bicycle. What is also important here is about the contrast between conscious and unconscious processing, just think of the process of learning/riding a bike.
  • strong or collective tacit knowledge – is about the social aspects/interactions/relations people have and the knowledge that derives from this. These will influence also the social judgment of why certain things were done. The most important thing is that these things cannot be described and learned by explanation; it must be practiced in a social environment.
 

For me this was the decipher key of this type of situation. It was more than clear to me that even with all the goodwill, that man could not have written everything in a wiki and that things would have escaped to him. And this is ok, normal. I felt calm. I don’t know how to describe this calm; maybe it was a calm because it helped me focus on what I knew would come. 

Do you wonder how the story ended? That moment I anticipated arrived, and it was a difficult moment for my colleagues in that project. So difficult that replacement also suffered enormous stress and left.

Connection with test cases:

In the example above I said about that man who had to write about the steps (and nifty details) related to an installation. But this also applies to requirements, test cases. We have the impression that if we will concentrate all our efforts on writing and managing by test cases is the way to go. Actually, it is a waste, a not so good direction because on testing we do much much more. There are so many aspects which can be covered that it is really hard to articulate it. 

With this overemphasis on test cases we ignore the way we are and how we gain knowledge. Testing encompases many things like learning, critical thinking, experiencing and many others. A lot of this is not explicit but tacit. 

For example, I said about critical thinking, this is for me a form of ostensive knowledge. I used 2 words  to point to an entire discipline not so easy to describe and comprehend. 

Learning about the product involves also understanding why certain decisions were made about that product. Being aware that certain knowledge will be kept secret without intention, mismatched silences or not being aware that an information is so important that needs to be shared-unrecognized knowledge.

Experiencing a certain product might not be easy at all. Information might popup only when discussing with persons involved in the process of working/developing with that product(collective tacit knowledge).

Connection with requirements:

Is helpful to have things written down especially for remembering them. In Scrum, for example, we write to remember but we do not write to communicate the Product Backlog Items(PBI’s) – the PO tells them. 

Also this helps in setting more realistic expectations about written requirements. 

Connection with management:

The story I gave was the moment when I understood the importance of theory and practice (praxis) , in this case regarding some aspects of tacit and explicit knowledge. As a manager it helped me to size up an unexpected situation and also be aware of things that might happen.

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/

Discussion about hiring developers

Context: A lot of managers, product owners try to solve the problem of hiring only based on some specific skill sets. This is problematic because it shows a control mentality. But what happens when the needed skill sets change? We modify the team based on the skillset or we let them the chance to adapt, learn?(1)  Which approach is more agile?

Shu: Hi Ri. There is a thing which puzzles me, regarding the process of hiring developers. Tell me if I am wrong. 

Ri: Hi Shu, which thing?

Shu: Very often I see an announcement with  the following form: “We need a senior .Net/React/Vue/Java/Angular/… developer”. For sure a certain language/framework matters if it is known, but  is not enough – at least not for a senior. Seniority should not be tied to a certain technology only. 

Ri: Is it maybe just an unfortunate choice of words? Maybe they want to say a “senior developer with Net/React/Vue/Java/Angular/… skills”

Shu: I do not think this, because of a strange effect I saw. Is about how teams are formed, at least what I have noticed in the past. 

Ri: Could you tell me more…

Shu: You have a well functioning team and a new project comes. That project needs a React developer. No one in the current team has worked with React, but they are willing to learn. But it does not matter. A well functioning team will be broken because of that. Is a framework which can be mastered in a week or two by a person who knows things. 

Ri: Tell me more about other skills a developer should have.

Shu: Design, analysis, algorithms, architecture, OOP, testing, experience with at least 2 languages and platforms,… 

Ri: Why at least 2 languages and platforms? 

Shu: Because the elders  say so? 🙂 

Ri: Why do they say this? 

Shu: Maybe because of biases. 

Ri: And also, maybe, because a developer who will not have fear approaching multiple languages/technologies she/he will understand what unites them actually. When doing this, in the end maybe, will understand that in order to adapt fast she/he will need a common ground. And this common ground transcends the language/technology. 

[Shu is thinking] 

Shu: By common ground you mean clean code, architecture, domain analysis, patterns, Liskov principle, algorithms,…. 

Ri: Yes. So, what you are trying to say is that the problem is about the locus of attention being in a slightly wrong direction? 

Shu: Yes…

Ri: There are some things, among others, to consider when hiring:

– Hiring is also about learning. We want those developers, testers to learn when the market/product/needs/conditions will change. We do not want to destroy circle and community of trust(2). “Experience is not a state but a process”(3) ;

– If the focus when forming a team is first on the technology used, then on the available people and only then on the social aspects of the persons in that team and the learning, then it will be problematic and sad. 


(1) Strongly influenced by James Coplien in Scrum – Product Owner class discussion [October 2019]

(2) Jeff Sutherland, James O. Coplien, “Circle of trust”, http://www.scrumbook.org/product-organization-pattern-language/development-team/circle-of-trust.html 

(3) James Coplien, Scrum – Product Owner class discussion [October 2019]

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.

How testers can provide value for developers

On the Rapid Software Testing slack Channel(1), one month ago, an interesting  question was put by David Högberg:

Here is an interesting story and question from my friend in another Slack-group:

(translated from Swedish)

”Today was the last day of a sprint in one of the teams I coach at….

A backend developer has been very productive this sprint, he has pulled in more tickets than planned and finished those. Instead of pulling in another ticket on the last day he took the initiative to work on the unit test coverage and integration test coverage in our most important repository.

Now we have 100% code coverage for both unit and integration (API) and a branch coverage above 90%.

Besides this he always tests his own code, with both wide and deep understanding of the requirements. He always ask for feedback regarding his own testing, wants critical code reviews and practises risk-based exploratory testing.

This is what QA-coaches and testers will have to work with in the future. How do we create value for these future developers?”

….What are your thoughts regarding my friend’s question? How can testers provide value to developers who deeply care about code quality and at the same time are good at testing themselves?” (2)

The point raised by David Högberg is important and should not be ignored. Also, I saw that some testers were somehow speechless regarding this, like there was nothing to say/do/challenge/help.

There are lots of things testers can do. Testers must/can challenge things and there is a lot to challenge. So, for example:

1. The fact that what the developer does are unit checks , integration checks not tests.(3)

2. He said that he reached 100% code coverage for unit checks and integration checks. Actually code coverage is a measure and number for programers only. This is because it helps the developer to see areas not covered at all, not how well that area of code is covered. So, this number should not be exposed to management, because you can have 100% code coverage without code actually being covered. From the moment when you hear that code coverage number is exposed, there might be trouble – I know it sounds strange, but for me is a sign of exaggerated confidence. Maybe I am wrong, but for me is a heuristic for looking with care, because of the things which can’t be articulated in simple boolean confirmation statements.

I have to say that each time when I discuss with managers I try to do my best to convince them to ignore the code coverage number and the fact that it means nothing.

By the way, when I have the occasion I ask programers this simple question: So you are so confident with the unit checks?  If the answer yes, then I ask: Good, are you ready to bet you salary for 3 months that I’ll not find any problems? Usually, I perceive hesitation.

A good technique to verify the actual lines/conditions, in terms of coverage, is mutation checking(4). Even with this technique, I have in my mind the difference between testing and checking! (3)

3. As a tester you can help the developer with the sampling, the data she/he is choosing. And, as you know, this is not a skill which can be learned in a day or two. Sampling at the unit and at the integration level is important and I saw a lot of times unit checks and integration checks which repeat themselves.

I do not mention that testers, need to know very well about cognitive biases, critical thinking.

4. The developer said that he/she made unit checks? Perfect. Challenge that. Take a look at this brilliant article by James Coplien: Why Most Unit Testing is Waste . You’ll notice that this article is not so easy to digest, is deep – it speaks about the theory of information, also it does not follow the current dominant thinking about unit tests. I’m sure it will help you to make that developer think. Maybe negative reactions can take place, but is OK, we want fruitful disagreements.

5. The developer said he/she is doing TDD? TDD does not help at big architecture and OOP. It helps, maybe, at the micro level, but for sure not macro. This means architecture, OOP is fully exposed in a big and nasty ways. Maybe integration checks can help to see that the parts are fitting together, but are not helping to see that they are ok built. What this means? Well… nasty things are hidden at the integration boundaries. Developers don’t do OOP, but Class Oriented Programming. OOP would mean to reflect the mental model of users, which this does not happen. All the work is split between a lot of classes and functions. I think you can imagine the dangers.

Regarding TDD, I noticed that some persons begun to make some research about it and it is interesting: A Comparative Case Study on the Impact of Test-Driven Development on Program Design and Test Coverage or Does Test-Driven Development Improve the Program Code? Alarming Results from a Comparative Case Study

By the way, I also liked this post: TDD is dead. Long live testing

So, please, go and see the research, I doubt a lot of programmers do that…

6. Unit checks and integration checks is also code, this means that is prone affected by things like: bugs, maintenance, design, analysis, architecture.

7. I love the article of Max Boisot with the patterns(5). For example: for 10 dots there are 45 possible links and 3.5 trillion possible patterns. I’m sure in applications there are more than 10 connected dots. Is not possible for a developer, no matter how smart he/she is, to be sure he/she covered all the possible patterns and also to be aware which pattern is more important than other(s).

8. Regarding “A backend developer has been very productive this sprint, he has pulled in more tickets than planned and finished those.” Maybe I’m interpreting this in a wrong way, but sorry… I’m not interested in the productivity of the developer. This is a very nasty stuff. For me is important that the team and the whole work to be ok. When I read productivity of individual, I begun to doubt the good functioning of the team and this is bloody dangerous. Is like measuring tester for the bugs introduced, sorry, but no. Were there any other members actually working on stuff? If yes, why he did not took care to help finish that?  – I’m deducing this from the text, maybe I’m wrong. In Scrum the team works on a single PBI at a time.

Still the list is short. I would have added about cognitive dissonance, of how the team structure affects the code structure, but you got the idea…

Conclusion: So how testers might create value for these kind of developers? I think that when a tester will put this question then is a good sign because learning/helping continues.


(1) Michael Bolton, “RST Slack Channel”, https://www.developsense.com/blog/2017/10/rst-slack-channel/

(2) Text used with permission, thx David Högberg

(3) James Bach, Michael Bolton,”Testing and Checking Refined”, https://www.satisfice.com/blog/archives/856

(4) Robert C. Martin, “Mutation Testing”, https://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTesting.html

(5) “The problem of connecting the dots”, https://sensing-ontologies.com/the-problem-of-connecting-the-dots/

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

How to make people hate the idea of estimations

Once in awhile the topic of estimations pops out in my activity. I said once in awhile because I am thinking to a special kind of way to do estimations or better said how the idea of estimation is put on the scene in some contexts.  This topic I have had it in my mind for a long time, which became obvious again these days.

So:

1. Usually, when you ask people whether certain items can be made in a sprint ,people can say, maybe, also after some calibration, a clear answer like: “Yes, we think is ok for this sprint to do these” or “Yes, it makes sense to have those items for this sprint”. This means that although not explicitly, but implicitly, an estimation is being made.

Notes:

–  Let’s suppose that some unknowns were already clarified because of some spikes/investigations done a priori;

– “calibration” is an important word[1];

But, and maybe I am wrong,  the same people when asked in detail(hours/points in the sprint) they will not feel comfortable with the estimation and with the meeting(s), because of doing this. I think this happens also because humans are messy[2] and is ok.

What is not so ok, I think, is why to ask more specific estimation detail, for a sprint, when already the team said those things can be made in the sprint, and of course with the information they have for now is the maximum of work they can accept as a team?

There are some possible answers I can think of:

– maybe someone wants control in the sprint( maybe the managers of the manager of the project impose on him , or lack of trust, or outsourcing context where client  paying by day involuntary triggers this need or because he/she knows that the setup of the team is not ok(let’s say the competency of team members)).

– I saw how tools like Jira entice some managers to ask these things;

– they do not understand why sprints/iterations were created;

2. Then are those estimations when getting a project and it has to be finished in, let’s say, 6 months. And the estimations “must be ok, they must not be wrong”. So, we have an initial “must be ok” estimation. But then after 4 sprints again a new estimation is done – of course I imagine people joy to do that because the estimation wanted to be done, strangely, must be “ok”…

So that kind of project is being managed in a way by the “must be ok” estimations, if I can say so – just to make me clear: I am speaking about ( and I am influenced by Alicia Juarrero[3] ) using estimations as a placid background, like an equilibrium structure, like an indication of stability( small deviations around equilibrium).

Note: I am assuming that a project is not in an obvious state, it can be also in complex situations.

Conclusion:

Estimations – in a way or the other – we use them. We use them implicitly or explicitly or deduced and in various forms( relative, time, distributions…) and it makes sense as a concept.

I think that the estimations, more often, are being used by managers in a wrong way, for example like a pressure consciously/unconsciously/unknowingly. And this is actually the problem. Maybe this is happening because of the mechanistic way of their thinking or lack of knowledge or … They choose the wrong metaphor, they do not deal with a refinery/factory, but with an ecology.  Also, probably at least what I saw, most of them do not take a look at what psychology, neuroscience have to say about this and adapt their actions.

I do not think is ok to encourage the dichotomy ProEstimate and No Estimate, I think here is a continuum between them.


(1) Adrian Lander, “Linked In discussion”, https://www.linkedin.com/feed/update/urn:li:activity:6426405267491164160

(2) Dave Snowden, “Humans are messy”, http://cognitive-edge.com/blog/humans-are-messy/

(3) Alicia Juarrero, “Safe-Fail, NOT Fail-Safe  ”, https://vimeo.com/95646156

Forming a team, an agile perspective

I’m seriously concerned about this topic because I see the disastrous effects of its bad handling every day.  It’s not enough to put some people together and ask them, usually in a perverse, detached and manipulative way, that no matter the difficulties encountered, they should make it work because this is what professionals do – in a way this is like an abdication of the job a manager should do rigorously. I know it’s hard, damn hard, I made my share of mistakes …

I wrote about this topic before.

But this time I would like to recall two important perspectives, from the agile world, that unfortunately seem to be ignored:

1. Early this year a nice interview(1) with Jerry Weinberg was published. In it, he described one method to form a team:

“…We put together teams. What I recommend is people put together their agile teams by what I call incremental consensus. You start with one person who you feel has the personal qualities. Stop emphasizing very soon with what I read about is people emphasizing: you got to have the most skilled coder and you can put all the best coders together and then you have an agile team. Now you find someone who has got these personal qualities: they know how to communicate , they’re willing to communicate, they’re willing to admit their mistakes and learn. And you start with that person. And you say: okay now among all the people we have available to us who would you like most to team up with to do a good job; you understand the agile principles. And they choose of course… it’s one person so it’s a consensus and the person has to want to be on it … Now you have two people. Now you say to them: okay now come to an agreement on who else you’d like to have. If you started with the right person the process goes on and they put together a team that really does well; and they take awhile to learn but they can learn the skills, technical skills, more easily than they can learn the personal skills, the people’s skills as we call them…”

In 2016, after a horrible month of solving some issues, with a delicate suite of products, I realized that this is the time when the core problem could be solved. It could be solved because the key persons were prepared to allow the kind of work I had in my mind for almost 2 years. In that terrible month, I have worked with some wonderful people to fix the problems. I knew that the kind of work I wanted to do needed special people. Even before I spoke with the management, I spoke with each of them separately. I told them what I had in mind and the persons I wanted to do the work with. I needed their green light regarding the work that needs to be done, their future colleagues and if they were willing to join the team. I left them time to reflect on all those things. In this time I talked with no one else. After several days we spoke again, separately, and each of them gave the green light. Then I spoke with management and it was hard…but I was determined, if one of them could not join the new setup, I would not take in charge that new project/product. I wanted from each of the future team members their consensus. And as Jerry Weinberg said, it was not only about the technical skills of these people, it was much much more. Please watch the Jerry Weinberg interview.

2. Scrum Plop(2) – I am amazed that so many Scrum people, from my circles, are not aware of this. It’s about patterns that show and help on how to implement Scrum.  If Scrum guide seems abstract and hard to be decoded, well these patterns help a lot in making sense on how to implement Scrum. There is a pattern called Stable Teams(3) which accurately articulates the problem and also gives a solution:

“…Keep teams stable and avoid shuffling people around between teams. Stable teams tend to get to know their capacity, which makes it possible for the business to have some predictability. Dedicate team members to a single team whenever possible. Members of Stable Teams get to know each other. The team members experience each other’s work style and learn how much work they can do together. A Stable Team grows in familiarity and consistency of meeting mutual expectations and starts developing a Community of Trust…. what is often forgotten when measuring a team’s velocity is that the only way that a team can get to know their velocity is by having the same team members over a longer period of time…”

Trust is a key/serious/important word. Trust takes time because is arising from people interactions over a certain period of time. You cannot create a roadmap or a checklist on how to build trust within a team.

Since I mentioned Scrum above, it is important to also mention 2 important related details about it:

– an important detail, also applicable to teams, is about competence(4)/skill/mastery/expertise. Although this is an aspect that is not explicitly specified in the Scrum guide, it is a sine qua non condition for Scrum to work;

– management plays an important role when forming the team. Not an easy thing to do. But after they’ve formed the team, they should trust them and let them accomplish their mission(5).

Conclusion:

Every time I think about this subject, I think about families. Look at families, at how delicate  things can get sometimes, because family members can’t get along with each other. And it’s not like this problem can be easily solved by a parent, for example, by just saying: “hey, you are brothers, you are supposed to get along”. Some will say, when speaking about team members, that it’s not about friends or family members. And I say “Exactly. It’s even harder and it’s not that easy to impose things”. So, I imagine that for some managers it’s easier to pretend that they don’t know things/techniques  on forming a team, and then use some fancy words and clichés to “solve it”, thus tossing the effort they should have done onto the shoulders of other people. But the reality has its own style to deny certain approaches/ideas/opinions.

What was a surprise for me is that it can be really really dangerous to desire having a Stable Team. The surprise was even bigger that the danger came from people which actually, at least declaratively, supports and promotes Scrum and agility.


(1) Jerry Weinberg, “Agile for Humans #26: Agile Impressions and Errors with Jerry Weinberg”, https://www.youtube.com/watch?v=I_AOoSnhE-8

(2) Scrum Pattern Community, Jim Coplien – Product Owner for the Scrum Patterns effort, http://www.scrumplop.org/

(3) Stable Teams Pattern, https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/development-team/stable-teams

(4) Jim Coplien, “Ten things scrummers do wrong”, https://vimeo.com/42772592

(5) Alistair Cockburn, “Core scrum, barnacles, rumors and hearsay, improved version”, https://www.youtube.com/watch?v=AuUadPoi35M