Management

What is testing for me

Some days ago I had the occasion to make a presentation regarding testing. But I had one dilemma before. How could I have been able to do this presentation without me being able to say what testing is for me?

There is a concept, praxis, that started my quest to understand how theory can inform and make sense in the practices, in my day to day work. And when I say practices I think about practices in testing, management and programming. There are lots of them. I began to cover some of them, please look here for examples. The concept I am speaking about now is the complexity theory.

Is not easy to explain this complexity thing. I like how Edgar Morin explains the complexity. For him complexity is like a tissue or fabric of inseparable associated diverse elements. But at a second look, those elements represent: events, actions, interactions, feedbacks, hazards.

I like the header image because it is trying visually to show this complexity. You can see in the image some dots, connection between the dots, but it also shows patterns that can be formed (different lines, triangles, pentagons, polygons and so many others). In our day to day life those dots might represent things like:

Technical details in our product(components and objects relating to each other, the fractality of the code, mixing up unrelated abstraction and so on)
Humans with their roles working on a product
Risks
Requirements

And then there is another important detail and that is the fact that humans think in patterns.

So, what is testing for me? Testing is about finding those relevant patterns that matters within a complex system.

Those patterns might mean whatever is relevant in spotting problems within the product or process. These patterns are not static, they continuously change.

Risks, feelings, management

What if everyone –our managers, auditors, testers — got it wrong with the topic of risks?

What if what we witness regarding risk management is just a charade ?

Long ago, I read Jerry Weinberg say, “The definition of quality is always political and emotional.” That resonated with me then and still does.

I had to get out of a project. At that time I occupied a management position. Usually in taking over a project there are some intermediate steps that need to be done. There was no pressure. It was time for my replacement, let’s call him John, to take it over.

John was also in a management position. We both worked on the same big suite of products. My project was an integration project, making the communication between products from the suite work. Part of the problem in my project, before taking over, was that it contained hacks. By hacks I mean things which did not belong there at all but on the other products,at the source.Unfortunately, managers from the other products did not want to apply the needed fixes on their parts, to remove those hacks. So all the garbage needed to be fixed on their part was thrown on this integration project, before I came.

My team fixed these problems in both the integration product and the other products from the suite.

As I reflect back on my conversations with John,I remember several things that appeared “off.” He seemed very detached about topics we needed to discuss in order for him to take up the project . My perception was that John had exaggerated detachment. When he spoke with me everything was ok. But with the others(management from client , our management, teams) his conversation was all about risks.

I did not mind at all that John was concerned about risks. What I did not understand in those moments was his lack of convergence. John spoke with me about risks but in a calm way. When he spoke with others he was doing it in an alarming and exaggerating way. Also I have noticed certain resistance from the teams he had. Anyway that exaggerated perceived detachment in combination with how he handled the risks puzzled me.

Feelings, as much as data, play an important role in decision making.

Then, I found some scientific research about risks, the risks as feelings hypothesis. This hypothesis says that response to risky situations and how we evaluate them are influenced directly by our emotions/affect. The traditional models of evaluating risks tell us about probabilities and consequences but nothing else. But these, actually, are seriously influenced by feelings.(1)

But there is more. You may wonder why us , in IT, should we care about these studies? Because, is about validated scientific knowledge. Things which other disciplines already studied and proved it. We only have to cross the corridor to these disciplines and learn from them. I like the word praxis to describe this.

So, I spoke about the psychological part. But there are also sociological and anthropological studies. These studies show that risk perception has roots also in sociological and cultural elements. For example, the sociological component is telling us how we are influenced in dealing with risks by colleagues, friends, family. The anthropological component tells us that people within groups minimize certain risks and exaggerate others as a way to maintain or control a group.(2)

I realized John had feelings, and those feelings might lead him to assess risks differently than I did. Maybe he felt fear because of the history of the project.

As said above there is also a sociological part which might help in making sense of this situation. I tried to understand from whom he was taking certain technical information. Who was advising him on this part. And I realized it was about some of his team members who did not want to be involved in the take over.

The anthropological component helped me to understand the exaggerated escalation to management. It was a way to maneuver the management groups by playing with risks.

Till that moment I only witnessed a shallow view of how risks were used by management. It was an eye opener to me regarding risks and how they should be used in management, testing, audits.

I mentioned audits. I would like to see an auditor knowing these aspects of risks. Maybe this will help in order to be able to see the spirit of the law and not just the letter of the law. Risks combined with the tacit knowledge might help understand the why’s of why certain risks are articulated, handled and made public in a very specific way. Audits is not about simple receipts ignoring the context and professionalism of a discipline.

Emotions play an important aspect in, risks, judgment/evaluation/assessment. How right Jerry Weinberg was.

(1) Risks as Feelings, Loewenstein, George F. and Weber, Elke U. and Hsee, Christopher K., Psychological Bulletin, Vol. 127, 2001, Available at SSRN: https://ssrn.com/abstract=929947

(2) Perception of Risk, Paul Slovic, Science 17 Apr 1987:Vol. 236, Issue 4799, pp. 280-285, https://science.sciencemag.org/content/236/4799/280

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.

Discussion about showing all testing scenarios

Context: Have you ever had a conversation about test automation where the manager wanted you to automate “everything”? Or the manager asked you to show him/her all the scenarios? And how can we explain it in a simple way? Below is a small/simple dialog trying to do this.

Manager: Is there a place I can see the testing outputs for all applications? What scenarios are tested and which are not?

Tester: We cannot simply show “all the scenarios”. Testing is not a finite set of scenarios but an exploration of the product to discover new information.

Manager: I do not understand. Everywhere you look they do this.

Tester: Indeed. Look. Maybe there is more to say here. I understand your preoccupation. May I try to offer a perspective? Maybe it will help us. That’s what people say they do. The reality is more complex.

Manager: <<the manager makes a gesture that is ready to listen, but the tester perceived some doubts>>

Tester: I like to use an example that is connected with a problem posed by international terrorism. Yes, it sounds strange and curious at the same time, I think. It was a guy, Max Boisot(1), that tried to explain via a simple analogy why they were not able to catch lots of attacks. Imagine that we have 10 points. These points can represent people, requirements, code packages/branches and other things regarding product development.

Look at this image, please do not stress with math formulas, take it as it is:

Manager: So those points can represent different things in a project?

Tester: yes. Actually just imagine the realities of a project like a woven fabric of different things(events, actions, interactions, feedback, dangers, determinations) that are inseparably associated.

Manager: Ok <<said with a long Ooo>>

Tester: Do you see in the drawing that multiple geometric figures can be created via 2 or 3 or 4 dots?

Manager: Yes, different kind of triangles, polygons

Tester: Yes, Max Boisot named them patterns. The total number of these is 3.5 trillion. In real life some of them matter, some of them not. But in testing we must look for those that matter through all the existing ones. Somehow I froze at your request because it is impossible for me to give you what you said. I would do it but it is hard if not impossible.

Manager: Hmmm. And what about automation?

Tester: We can automate a thing which is explicit and deterministic in an algorithmic way. We cannot automate sensemaking, critical thinking, studying, modeling, interpretation. All these , among other things, are part of the process of testing.

Manager: But every company I look at does this. It seems that every company follows the same thread/trend. Why do they consider it that it can be done, that you can automate everything?

Tester: First , I think that there is a lot of marketing out there. Then how do we expect people who were hired or built a career or had a certification to admit they were not so right? Is not easy.

Manager: You did not finish the idea with automation and the geometric figures

Tester: Yes. There are three important things:

– even with the best programers we can’t cover and prove those 3.5 trillion patterns

– I say this because there are different types of coverages(2), I know of at least 100 of them. If you’ll ask a programmer she/he will tell you, maybe, about code coverage.

– As people, we are pattern detectors, etc. If you encourage our agency, we can see patterns in the data/product a tool can’t see.

Manager: But I need a way to show that we are on top of the situation and that we can detect the problems.

Tester: There are ways. For example, to manage testing we can use Session Based Test Management(3). To discover problems we have a long range of heuristics and techniques to do it.

Manager: Ok. But we have to discuss these also. Let’s fix another meeting for this.

Tester: Of course

(1) Connecting the dots, Max Boisot, https://web.archive.org/web/20091123034027/http://www.hlswatch.com/2009/11/12/nidal-hasan-and-the-problem-of-connecting-the-dots/

Note: I searched for the original link of the article “Connecting the dots” but is no longer available.

(2) Software Negligence and Testing Coverage, Cem Kaner, http://www.badsoftware.com/coverage.htm

(3) Session-Based Test Management, James Bach, Jon Bach , https://www.satisfice.com/download/session-based-test-management

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

The hidden dimensions of code review(s) – part 2

Some dimensions will be treated in this blog post and on part 3 of this blog posts series(see part 1 here) , my friend, Ionut Albescu will help out with the dimensions and sub-dimensions which were left out.

The dimensions

■ Programming(Design, Clean Code, Refactoring, Unit Checking)

There are a lot of materials covering these aspects. Just search for books by James Coplien, Robert C. Martin, Martin Fowler, Michael Feathers and you will get an idea of each of these topics. Usually, in appearance, this is the dimension were code review is concentrated. I said in appearance because these topics cannot be mastered in a month or two, not at all. But is more, although management/customers/end users will expect programmers to excel in this… well is not quite like this…

Programming – Impact

This sub-dimension is to make the programmer aware of how the functionality she/he implemented will impact the final user. How many programmers think that because of their work an end user can be fired?

■ Testing

Here I am thinking about Context Driven Testing(1) school of thought, especially Rapid Software Testing(2). This testing has its roots in cognitive psychology and epistemology(3). Please read the work of James Bach, Michael Bolton, Cem Kaner, Jerry Weinberg.

If you are a developer and want to ignore this dimension than I advise you to think better. You will lose the chance to be an even better professional.

Testing – History

James Bach, some time ago, pointed me out about the book “Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs”. I was thrilled to see how many things can be deduced just by looking in the source control history. I was able to see the weak points of code and where to concentrate the refactoring. It was there in front of my eyes the Paretto principle, helping me in prioritizing work, but also helping testers in guiding their test strategy.

Testing – Testability of the application

We need to give the application control points so the testers, programmers can exercise more easily certain scenarios. For example replacing more easily components. If we can’t do this, then is a red flag.

Testing – Risks

4 sub-dimensions listed here are from the wonderful paper “Risks Analysis Heuristics (for Digital Products)”(4): project factors, technology factors, specification factors, operational factors. Studying this paper made me realize that coding is not just about if, else, while… instructions.

The tester(s) have a different mindset, which should be viewed as a complementary to the one we already have, as a developer. Developers look at the code with the assumption that is right, but we need testers to look at the code with the assumption that is wrong(they are negative, they focus on failure(3)).

■ Business

All the code should be driven by the business need. Use cases/activities should drive the code and it’s structure. How do you know that a duplication is not just a temporary one which in the end will no longer exist? How do you know that you are applying ok the Single Responsibility Principle? Well guided by the business, the actors.

Business – Analysis

I remember we discussed the heuristic “Mary had a little lamb”(5). This heuristic help identify ambiguity statements which are in written form. The secret is to concentrate on each word one by one and then in combinations. Let’s take the word “Mary”. We concentrate on this word by posing questions: Why Mary? Why not Giovanni? Let’s take the word “had” from the sentence: Why it had? What happened that no longer has it? What about present, future? Will it have another one in the future?.

I love this technique. A lot of programmers want and expect fully written requirements without side effects. But is not possible because:

– it is a lot of tacit knowledge;

– is one thing for people to see the data(let’s not forget that even with the highest concentration we partially see/scan stuff), one is to pay attention to it and a different thing to act upon that data. (6)

Most of the time we go on the supposition that we know what customers/end users want. But is it like that? What if the end user does not know? What if the end user is unaware of certain things, on which we might help, which are possible and they may want it? Why to code a thing and put a lot of effort in abstractions, algorithms when … maybe … that is not the path to follow?

Is time for a lot of programmers to grow up and not ask for things just because it will be easier for them. Or search for excuses not to do work. They will code certain business things. This means they are directly responsible to understand and make sure they understand those business things. Christopher Alexander put it very nicely: “Please forgive me, I’m going to be very direct and blunt for a horrible second. It could be thought that the technical way in which you currently look at programming is almost as if you were willing to be ‘guns for hire.’In other words, you are the technicians. You know how to make the programs work.‘Tell us what to do,Daddy, and we’ll do it.’That is the worm in the apple.”(7)

Business – Impact

Here is about building products and delivering projects that make an impact, not just ship software.

There is a technique for doing this which is called Impact Mapping(8).

Impact mapping is a planning technique which uses in a very inspired way guiding mind maps in helping achieve this by guiding/facilitating the process. It shifts the focus from just doing what the customer orders to focus on collaborating with all involved parties. The goal of the impact maps focuses on the question “Why are we doing this?” and gives a strong guidance on how to do this. This work collaboration between senior technical and business people is a must because the code changes based on this interaction. The abstractions, objects, architecture is strongly influenced by this. The business must be known by senior programmer – is a sine qua non condition for the seniority of the programmer.

Business – Demo

At the end people will see the result of the code, not the code itself. This result is the desired effect. This means that the end user, the Product Owner have to see it and the programmer to get an early feedback. So this aspect can help the developer to be ok/prepared when doing the Demo.

■ UX

Most often the work of the programmers is reflected in the UI. The final user does not see what is underneath. I really like how James Coplien makes the connection between object oriented programming and UX. Is normal because via UX we try to translate as much as we can the mental model of the user and then that mental model must be reflected in code.

■ Human

Very often we forget the social aspect of programming. We do not realize that architecture, for example, has a social aspect. This is very important.

Is not easy to integrate and make work two or more, different, personalities. I wrote before about this. There can be a conflict, a political stuff, sadness, ….All this can affect and will affect the quality of the code review.

In the mind map we put the word “Affinity” to be aware of all the subjectivity that can be present.

We put the word “Experience” because:

– of seeing bad examples. People who were considered seniors but they were affecting in a bad way how the review was done. Also the other team members, the juniors one, were influenced by these “seniors”;

– the experience plays a role in review because of the learning that can be done. Having an experienced developer that can share knowledge hands on;

– people with no programing experience , like some testers, were posing interesting questions. And the explanation towards them had to change a little bit;

About inattentional blindness, I wrote before about this aspect and code reviews.

Partial Conclusion

– Trygve Reenskaug had an interesting idea: the reviewer having the responsibility of the code being reviewed, not the programmer who wrote it. That for sure will change the dynamic of code reviews and it can make code review(s) more valuable/interesting not just a monoton approve step(9);

– After we (Alexandra Vasile, Marius Jantea, Ionuț Albescu and I) created the mind map and thought together at those dimensions and explanations I realized that in my subconsciousness I might have been influenced by the wonderful book named “Handbook of Technical Reviews” written by Jerry Weinberg(10);

– Seeing how code reviews are being done/treated gave me a clue regarding the dynamic of the team and possible sociological/management/organizational problems that might be there. I say this because a characteristic of complex systems is fractality;

– Do you feel to modify the mind map, to add more dimensions and sub-dimensions? Good;

On Part 3 of this blog post my friend Ionuț Albescu will continue in clarifying the other dimensions which were left out and also will give his personal touch on this subject of code reviews.

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

(2) Rapid Software Testing Methodology, https://www.satisfice.com/rapid-testing-methodology

(3) James Bach, “Lessons Learned in Software Testing: A Context-Driven Approach”, https://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124#

(4) James Bach, Michael Bolton, “Risks Analysis Heuristics (for Digital Products)”, http://www.developsense.com/resources/RiskHeuristics.pdf

(5) Jerry Weinberg, “Exploring Requirements” https://leanpub.com/b/requirements#bundle-page-exploringrequirementsone

(6) Dave Snowden, “See-Attend-Act”, https://cognitive-edge.com/blog/see-attend-act1/

(7) Christopher Alexander, “The Origins of Pattern Theory: The Future of the Theory, and the Generation of a Living World”, https://pdfs.semanticscholar.org/7157/ee5a77c6fd64f8b8b2282225f113205370e9.pdf

(8) Gojko Adzic, “Impact mapping”, https://leanpub.com/impact-mapping

(9) Trygve Reenskaug, “DCI: Re-thinking the foundations of object orientation and of programming”, https://vimeo.com/8235394

(10) Jerry Weinberg, “Handbook of Technical Reviews”, https://leanpub.com/handbookoftechnicalreviewsfourthedition

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 – 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.

About best practice

This idea of best practice continue to pop up. For me is disturbing, in the sense that some practices are being introduced just because near them appears the word “best”. And this is bloody dangerous. In the lines below, I try to decompress what I have just said because I realized that even though we speak about 2 words, is important to say what those 2 words might mean and all the thoughts regarding them.

As a premise, I have to say that language is very important because it can trigger different kind of thoughts( I thought is not true, but after reading some of Antonio Damasio work, I am sure now) . For example, I told to a Scrum Master that her role is like an attractor ( attractor idea from Lorenz attractor). I could have used a word which Scrum Masters are accustomed, but I might have failed to communicate what I wanted to say.

So, for me there are 2 things/directions to think about this topic, at least to try to clarify or see if is some coherence. First what some might really mean/think by “best practice” and second, see what exactly really is “best practice”.

So:

1. what some really might mean by “best practice” -> to really see what might they mean, I imagine there can be lot of inference.

Here I identified 2 directions also, there might be others:

1.1 some people want to say something else, but don’t have the words.

For example: We want to use a new JS framework, like Vue/React/Angular. No one knows the particulars. So someone might say: “What are the best practices for developing with Vue/React/Angular?” By saying this, in a way, is trying to see how to deal with uncertainty regarding that framework. For sure the official documentation/video trainings give a way to handle the work with Vue/React/Angular. This means that, by best practice that person might mean some common norm/recipes to tackle that UI framework. If that person will follow the patterns exposed by the documentation of others then he/she will be able to learn/do/search for the work – at least this might be his/her thoughts.

With this example I have noticed some things:

– Is one thing to learn a specific syntax. Then those, introductory, videos/documentation might help;

– Is a totally different story to structure/architect the code and not being biased by the UI framework. I have to say that I do not search for a Vue/React/Angular developer, I search for a craftsperson developer which is a totally different thing(1) – by the way this is becoming a serious problem, especially in outsourcing;

– Framework designers will not ask for my or yours permission to modify or retire a framework;

So, in this case, “best practice” might mean something like finding a way to deal with unknown. But, but, if by solving this unknown thing ( at least having the impression it can be solved) in the end might use the, so called, best practices. These best practices are like universal rules for that specific framework and might be in the thoughts of a lot of people. And here, at least for programmatic stuff, trouble might begin.

Small conclusion of this point: Best practice, maybe, is used in two ways. First to tackle/understand the unknown in a tacit way and then as universal receipts, but with no context awareness. And maybe the person using it not being aware of this.

1.2 Mechanistic thinking, truly believing/hoping there exists this “best practice” applicable everywhere.

For example, an upper manager who has to handle multiple projects, new and existing, in an outsourcing regime.

This kind of person might look to see best practices in architecture, again as recipes. He/she will want this because once it has the list of the so called architectures, then the architecture subject will no longer be a problem. He/she can really concentrate on hiring React/Vue/.Net/… developer, not a craftsperson developer.

With testing, he/she will ask the infamous ‘lets automate all’, and a common approach to all projects of what automation to be done, like using Gherkin and that’s it.

This kind of person, thinks that everything is the same. But he/she forgets that “God is in the details”(2).

These kind of persons will come with a checklist, to be sure that some practices, they already have in their head or imposed by others, pardon best practices, will be implemented. What is sad is that those practices are the same for each project, context is not considered at all. I have noticed that some use “good practice” , not “best practice”, but their dynamic of actions is the same, they only changed “best practice” with “good practice”.

Small conclusion of this point: Here “best practice” is much more dangerous than the one described in section 1.1, because it imposes a certain way of doing things no matter what. The dynamic of actions generated by this can and, I think, will generate lot of strange and unwanted things.

2. See what exactly really is “best practice”

Here I’m influenced by the book “Tools of Critical Thinking: Metathoughts for Psychology”, in the sense that is there a chapter which gives examples of a concept being true and wrong in the same moment – I hope I recall ok this.

Also I have to say that I’m influenced here by the work of Alicia Juarrero and Dave Snowden.

I like the idea of seeing context from the point of view of constraint and casualty. For contexts were best practice might be applicable the constraints are governing ones. They are very rigid. And regarding casualty it should imply that it can be identified very clear and without doubts that event B appeared because of event A and nothing else.(3)

So, the context must be very very rigid. But when we deal with human systems, generally speaking, if it will be constraint in such a way, it will crash or find hidden ways to do the work.

Small conclusion to this point: Even if best practice might mean and have a sense, for sure it has a bounded applicability and this is not understood by a lot of people.

Conclusion: When I hear the words “best practice”, for me is like a heuristic for sloppiness/anomally/something to raise the guard, which if is imposed, it might hurt a lot. For sure is a good indication to see the situated present and how analyze/see/make a sense of it .

(1) David Schmitz, “10 Tips for failing badly at Microservices”, https://www.youtube.com/watch?v=X0tjziAQfNQ

(2) James Coplien, “Lean Architecture: for Agile Software Development”, https://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208

(3) Dave Snowden and Mary E. Boone, “A Leader’s Framework for Decision Making“, https://hbr.org/2007/11/a-leaders-framework-for-decision-making