On the idea of testers being underrated – Part 2

In the first part Marius expressed his opinion regarding this subject, below I try to articulate my thoughts.

I came across the topic on linkedin, and I couldn’t resist to not comment on it. I personally don’t experience that people from other departments that work with me would underrate me as a tester (or maybe I just haven’t noticed yet), but I see it happening to other testers a lot. I want to discuss two main points that I kept thinking of as I was reading the original article(1) and that might have a lot in common with why that is happening.
 
I. The „test automation“ fallacy
Most of us testers often use the wrong terminology when we talk about the opportunities for using automation – especially when using it for build confirmation purposes.

In that case the tester often designs and encodes a suite of checks that he runs after each new build, to see if the results of the suite changed since the last time the suite had been run.
In certain situations, this is often an efficient way of how to save time. However, we can’t talk about that as „test automation“. Why not? This goes all the way down to the question „what is a test?“.

There are many definitions of testing. Since I believe testing is best thought of as a skilled social activity, I prefer the definition offered by James Bach and Michael Bolton. They define a test as an „instance of testing“, where testing stands for „the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.“(2)

So how do I myself approach the encoding of an automated check?

1. At first I have to get to know the product I’m testing; I have to learn about the product – for that I use exploration, studying, questioning, modeling, observation, inference, etc. I can’t set up a machine to do it for me.

2. Then I have to make some decisions about the tradeoffs:

a. Which features of the product are crucial to do regression testing on?
b. What specific checks will be valuable to automate for those features?
c. What tools will I use for the automation?

3. Next, I have to design and encode the check.

4. I have to tell the computer what the words „pass“ and „fail“ mean; I have to think of an oracle, which is self verifying – that means, that I will have to think of what is the anticipated result of the check and include it to the code (this is often called an assertion), so that the computer will be able to tell, if the check passed.

But that’s not all yet, is it? If the check fails, it doesn’t automatically have to mean that there’s a bug in the product – and not even that the feature, which I wrote the check for in the product has changed – maybe just the environment is down. Or the tool is badly configured. Or there’s a bug in my automation – so if I see a check fail, I have to go back to it and make sense of what had really happened. Machines by themselves can’t do that either.

The „it’s all just semantics“ argument

You can see that there’s a lot of human interaction happening while creating automation checks. If we talk about this complex activity as „test automation“, it leads to the belief that testing can be automated – especially by the managers who are not skilled in testing and want to save money where possible. Why would they appreciate testers if we project the illusion of replaceability?
Why wouldn’t they think that they can replace humans with machinery if all that testers do is talking about new ways of using „test automation“ or performing „automated testing“?
Testers like Michael Bolton and James Bach came up with the idea of using much more suitable term “checking”(2) years ago, yet most people in the testing industry still cling to the test automation nonsense. They choose to dismiss the difference between checking and testing with the argument that it’s just semantics and it’s not really that important – but it hurts us testers the most.

II. The obsession with bad certifications

A lot of testers fall into the ISTQB/TMap/<whatever else> certification trap: “I’m certified, therefore I’m a professional tester!”. They might get the feeling that since they already accomplished to get a piece of paper that certifies that they passed a bad exam, they don’t have to invest their resources to further education anymore.

The number one problem that I have with these certifications is that they don’t teach testers how to test. They teach testers to memorize a book and then pick 1 from 4 options as an answer on the exam. And you have to get only 65% of the answers right to pass it anyway. 😊 (3)

I’m talking mainly about ISTQB CTFL here; how can a tester with that certification be taken seriously, if it takes what – a day? – to memorize the “right” answers to the questions, which you know beforehand?

If you compare ISTQB CTFL certification to a different engineering certification such as Offensive Security Certified Professional (OSCP) (4) it’s like night and day. I see OSCP as the kind of certification that actually might be useful if you really feel the urge to measure the depth of skill of an individual with a certification; the student goes through 24 hour challenge in an unfamiliar lab environment to do actual tasks related to security and must show off his skills while doing that.
You might say that it’s silly to compare the advanced OSCP to the most basic ISTQB exam – but even the most basic programming certifications are from a large part built on examples of code that the students have to understand to be able to pass the exam, not on memorizing a book about programming theory. But nobody does ANY actual testing in ISTQB’s CTFL – yet people still buy their expensive courses and pay for the exams.

[Sidenote: I met people who took the ISTQB courses (not just the CTFL, but also the advanced level test manager course) and shared with me that all they did there was listening to the instructor reading the syllabus with two or three examples and it was a complete waste of money and time. I don’t understand how they (ISTQB) can charge money for this.

On the other hand, I also met people, who claimed they enjoyed the course only because their instructor was more open-minded and left out bunch of the syllabus nonsense, which he replaced with some useful examples. Good for those people – they managed to got at least some value out of it, but still – would you want to support such organization when they clearly don’t care about your experience with the courses, as long as you buy them?]

Some testers do their exams just because they think there’s no other option than bad factory school courses. That’s not true. It is not „a certification“ in the ISTQB sense of the word, but there are four awesome courses in a series called Black Box Software Testing (BBST) by Cem Kaner and they are as close to teaching real testing as you might currently get.(5)

Conclusion
Of course there’s more to the topic than just these two points. But even when considering just these two, I really can’t blame people outside of the testing space that they treat some of us testers like second class citizens at work. When we are done with taking ridiculous certifications (and then bragging about passing it on social media sites) and we stop talking about testing as the next-to-be-replaced-with-machinery department, then we can stand a chance of not being underrated.

[Thanks to Michael Bolton and James Bach for their helpful reviews.]


(1) Claire Goss, “ Testers – Is it our own fault we are Underrated?!”,  http://www.exactest.ie/blog-testers-underrated.html

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

(3) “CTFL2018”, https://www.istqb.org/about-as/faqs.html?view=category&id=79

(4) “Offensive Security Certified Professional”, https://www.offensive-security.com/information-security-certifications/oscp-offensive-security-certified-professional/

(5) “About the Black Box Software Testing Courses”, https://www.associationforsoftwaretesting.org/courses/

About the idea that testers are underrated – Part 1

In a previous blog post I spoke about me being incapable to defend testing and testers.. What stroke me when I wrote that blog post was a discussion I had with a prospect. This prospect clearly expressed that testers, if they would have been in the project, should have been paid much less than developers with same experience. For example a senior tester should not be paid the same as a senior developer, actually it should be half of the price paid for a senior developer.

What was even harder for me was that my colleagues somehow agreed. In those moments, shortly  after the discussion with the prospect concentrated on other subjects, images of all testers from the firm flashed in front of my eyes. When I ran those images through my mind, there were a few dozen of testers, I realized that they also do not see testing as I see it. For me, testing is Context Driven Testing(via Rapid Software Testing(1), Black Box Software Testing(2)), for them it is more like Factory Style testing(3).

It’s time to speak/act about testing the proper way (and by testing I mean the testing envisioned by Jerry Weinberg, Cem Kaner, James Bach, Michael Bolton… – this line of direction). It’s becoming really embarrassing how such an important discipline is being trivialized in such a ugly/unprofessional/shameful/disgraceful manner in our industry.

The main issue here is not about “underselling”/”underrating”(4), these  things are effects. It’s about under-appreciation of the craft of testing. Seriously, what expectation should that tester have about being appreciated when the tester sees himself/herself as a manual/automation tester or qa automation tester and so on? I saw in interviews that testers are asked about how they write a test case, if they know jira/redmine/…, and if they know waterfall/agile/.. methodologies. Seriously?! And we wonder why testing is badly seen? I saw testers who encourage these kind of interviews( well, despite the fact that they label themselves as testers, for me they are not). The sad part is that managers believe this nonsense and are paying for it and they will be fooled again that “test automation” can solve/replace everything. Actually, if a tester is defined by writing test cases, knowing jira/redmine and knowing some agile/waterfall, no wonder,  all can say that their work can be automated or underrated.

Are testers to blame for this?  For sure they should do more to defend their craft.  It’s time for testers to know what professionalism in testing really is(5).

Also, it’s time for the Agile community to understand that testing, the real one, is very different: http://www.developsense.com/presentations/2017-09-TestingIsTestingAgileIsContext.pdf (careful, it’s a long document – not just a list of platitudes. It’s serious stuff . No fooling around.). After reading this document and thinking of that kind of tester and testing described there, for sure  the words “underrated” and “underselling” will not popup in anyone’s head anymore in regards to testing and testers. They will say, probably, something like: “wow, what I saw till now regarding testing was a bad comedy” or “I lost money in a stupid way”.

I am a developer trying to make a sense of what real testing is. I was glad to see a public feedback about this topic from a Context Driven Tester, Klára Jánová. In part 2 of this post is her feedback regarding the subject discussed here.


(1) James Bach, Michael Bolton, “Rapid Software Testing”, https://rapid-software-testing.com/

(2) Cem Kaner, “Black Box Software Testing course”, http://www.testingeducation.org/BBST/

(3) James Bach, Michael Bolton, “RST Appendices”, http://www.satisfice.com/rst-appendices.pdf (pages 3 to 7)

(4) Claire Goss, “Testers – Is it our own fault we are Underrated?!” http://www.exactest.ie/blog-testers-underrated.html

(5) Robert C. Martin, “Sapient Testing: The “Professionalism” meme”, https://sites.google.com/site/unclebobconsultingllc/home/articles/sapient-testing-the-professionalism-meme

Stories, Story points and Velocity

This topic keeps appearing constantly in my current contexts, but also on LinkedIn. But why?

Below I’ll try to mention some possible reasons why this is happening. Although I’ll mention them separately maybe they are not fully separated – there might be some connection between them. In a way, I would like to emphasize that, in a certain moment and context, one predominates.So:

  1. The desire to learn about these (stories(1), story points(2), velocity(3)) :It might happen that someone might want to learn about these concepts because of her/his own discoveries/investigations/curiosity and trying to make a sense of the reality, which might be contradictory – though I have doubts that there are lot of people asking this without being influenced by the points I will specify bellow.
  2. Dominant thinking: now this is the trend. Try to speak with someone and do a planning without using the notion of story, story points and velocity. For example look at FDD, you can do this without those notions. In FDD, this is articulated in a different way. For Scrum actually these(stories, story points, velocity), as Alistair Cockburn rightly said, are barnacles(3) (look at Scrum Guide, but also Scrum Plop). Sometimes, it seems, is dangerous not to go with the dominant thinking, if applicable.
  3. Trainings : Here I do not speak about the trainings made by the best in the industry (by best I mean Uncle Bob, Jim Coplien, James Bach, Michael Bolton, Alistair Cockburn, Ron Jeffries, Ward Cunningham, Dave Snowden, etc. I could mention more, but you get the idea). I want to emphasize those trainings made by some people which only know some phrases and that’s it. That kind of people, that are not capable to express and teach their students the bounded applicability of those techniques – for them is best practice to follow and that’s it. So: bad trainings;
  4. Target(s) : I think this is the most dangerous reason. Is about the Goodhart’s law: ”Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes”(4). I am amazed of how many anomalies are generated by this. So, some people want to learn more, but they do not understand, I think, that those things((stories, story points, velocity)) are used in a perverted/wrong way, or maybe they understand, but they need an ammunition to attack the targets.
  5. Tools(jira, redmine) : There are tools which entice managers to ask for things because they can generate beautiful graphics with them. I would say that, in a way the tool (or bad manager who thinks only linearly) dictates how things gets done, not people. I think these kind of managers equate agility with these tools …, which is sad. Just think about aggressive/subtitle micro management or think about handling a project just by using estimations and nothing else or that desire for predictivity – well these tools offer “support” for this and many other things. So: bad using of tools.

Conclusion: If I would have had to give a short and fast answer, probably I would have said about the possibility of anomalous/pervert/not ok context. I’m well aware that is possible that I’m influenced by certain biases I have.


(1) Ron Jeffries, “Essential XP: Card, Conversation, Confirmation”, https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

(2) Ron Jeffries, Google group conversation about why story points were invented, https://groups.google.com/forum/#!msg/scrumalliance/ag8W8xtKQs8/4cOpyt8Jgr0J

(3) Martin Fowler, “XpVelocity” , https://martinfowler.com/bliki/XpVelocity.html

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

(5) Dave Snowden, “The Strathern variation”, http://cognitive-edge.com/blog/the-strathern-variation/

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

An example of what it means for a deeply experienced person to held an interview for hiring

Yesterday I wrote about why it matters that a deeply experienced/senior person held an interview.

Today is time to write about such kind of person(although to say about him that is senior is too little, he is much much more) . Is about a special and important example of an action, made by him, in context of interviews . Is special and important because he helped people which now are ok because of him.

His name is Flaviu Boldea.

Almost 4 years ago we held lots of interviews. I was sad because I saw good/nice/pleasant people which did not passed the interview. With his calm voice he told me that this does not mean it should stop there. If I see a candidate which is ok, as a person, but is not passing, yet, the evaluation to offer him/her my time to help them prepare. Is important to say that he had done this several times before, so his words were not just some empty words.

I liked that he did not transform this in a process to do in the company. No no, it was about our willing, as simple persons, to help from our free time. It was about taking the responsibility of doing something and not to abdicate after saying no. It was not easy at all, but it was rewarding.

Experience/type of people involved/seniority/professionalism/craftsmanship/… matters.

About an anomaly in interviews and evaluations within companies

Too often I began to see a strange thing regarding people who make interviews for hiring or evaluates other people in companies. I saw that those persons are not actually seniors(deeply experienced) although there are , in the company, also seniors, who can handle this part. As I said, is a thing I experienced – maybe is not generally applicable, but it made me think deeply about this.

Another detail I did not mention is that these evaluations are made after a checklist, sometimes having a Dreyfuss representation.

I am not speaking regarding the practice that, at interviews for hiring, team members can join the interview just to see the type of the person being interviewed.

I try to be careful about dichotomies in the sense that more often  people use dichotomies when dealing with situations when is not the case. So, in our context, I imagine that is possible that at a certain moment a person with not so much experience can hold an interview/evaluation because of a special context( for example he/she is alone and is an urgent need).

Why I  thought that this might be a problem? Because:

  • experience matters. It matters because of the: different types of situations that person had, different types of skills he/she has acquired, the knowledge he/she has gained, the bad experiences he/she lived(all those lessons learned the hard way), familiarity of situation(s),…;
  • is hard for the evaluator to transcend the things. What if that checklist will not be of any direct help, does it mean the candidates will not be evaluated ok?;
  • It will be hard for him/her to see not just the letter of the law, but also the spirit of the law;
  • the language will be different. And now, I remembered Alistair Cockburn work. A Shu level has a different language than the Ha level or the Ri level or the Kokoro level. A Kokoro level having passed through all stages, if I can say so, will be able to understand and recognize the other levels even the Kokoro level itself. This means it will be a problem to decodify/interpret/analyze/acknowledge what the respondent will say;
  • Go to other domains like medicine. Is it normal for an intern to decide a certain level of an experienced surgeon?

Is important to mention that this evaluation can have an important impact on the person being evaluated( maybe is about money, image, dreams, promotion which can be affected in a bad way) or on the company also. Should an evaluation be let in hands of the not experienced? I hope not. I hope to see human judgment prevail, not to see some actions inspired by a checklist used by inexperienced people.(note: checklists are good, but when I see that for each type of problem the answer is to make a checklist then, maybe, something is not ok).

Shallow and risky view of technical debt

I spoke about technical debt in previous posts here, here, here and here .

Once again I have noticed, how the shallow view of (what is nowadays called) technical debt can ignore risky situations. Risky because some people can ignore certain things which might be problematic. I am referring to some managers, but there are also some “shallow” developers who have an apparent good discourse but nothing else. They think that a number (like the one offered by Sonar for example) is enough to provide them comfort when handling/managing/running/reporting on a project, when actually that number should not be interpreted so inclusively.

So, here are some premises:

  1. I said above “nowadays” because I noticed a difference between what technical debt meant initially, in 1992, and what technical debt is today, for a lot of people.

So, the original meaning of the message intended to be transmitted, was that technical debt is about the misalignment between the current code and known requirements[1]  – I think here might also fit in what Jim Coplien said: that maybe it wasn’t the requirements that have changed, but our understanding of the requirements were the ones that changed[2]. Ward Cunningham actually made in 2009 a new video regarding technical debt in which he “reflects on the history, motivation and common misunderstanding of the “debt metaphor” as motivation for refactoring.”[3]

What technical debt means now: messy code.

I think that, maybe, it’s ok for the original message/meaning to be known in the sense that might bring a new nonconscious perspective. The perspective that can ultimately help, by shaking the bases itself, to a better end.

  1. Martin Fowler tries to depict technical debt in an interesting way by using the quadrant[4]. This part is important because it shows us some dimensions of this concept that are not covered in our analysis/actions/approaches and are not so easily summarized into a number.
  1. Static code analysis tools do not give us straight clear information regarding SOLID principles, or  “4 rules of simple design”, or lean architecture[5]. For example:
  • Regarding SOLID: SRP can be deduced by looking at coupling and cyclomatic complexity. DIP can be deduced by looking at cyclomatic complexity. ISP by looking at empty methods, long methods and cyclomatic complexity. LSP…nothing [6].
  • “4 rules of simple design”: “Reveals intention” is about human judgment [6].

“No duplication” it might seem easy, but is not quite like this; I agree that there are good tools to measure this, but it doesn’t mean that all duplication is bad at a certain moment. I have observed that is not about a number, but in fact it’s about several numbers because it depends on the minimum number of block lines considered when making the comparison(try to run duplication analysis by changing the minimum block size).

  • “Lean architecture”: A special context might be built to make lean architecture at its place, but even if we do this, anomalies can / will still be introduced. I do not think it’s that easy to measure via static code analysis tools;
  1. I understand the need for tool(s) and I’m all for using tools – I’ve just recently developed two – because after all we’re homo faber. But besides that, we are also homo narrans, and these are axes among the atlas in what really makes us homo sapiens[7].

Conclusions:

– It is usually said, in my circles, to try/justify a new idea(bad or good) by saying: ”At least now we have something, before we had nothing”. The premises mentioned above are a way to contribute more to that “at least now we have something”, now I would say “we have a little more”;

– The following question often arises, in my circles: “What can we do better?”. The intent of the mentioned premises is the belief that by exposing them we will be in a much better position to expose/treat/manage/act/test/tackle what is technical debt;

– It’s good that we have Sonar, NDepend, … I do not deny their usefulness. But we have to understand their limited applicability;

– I understand that there is a need to show to our customers, if needed and applicable, that we handle/manage/tackle technical debt. Let’s say that it’s like a sale/marketing that we have to do, if I can say so. But at the same time, it should not be mistakenly believed that those numbers will save a project or even indicate reality. That’s why it means nothing to me to hear someone say that “the technical debt is just 1/2/3/…days to work on”;

Small Note: More technologies, especially those based on JavaScript, do not yet have the tools of code analysis as pertinent as possible. Javascript is an OOP language, for example. It’s great that there are tools like JSLint or something to find duplicates, but it does not quite indicate the cruel reality of a situation(I am thinking of design, oop, architecture when I say this).

– I do not think that technical debt can be described by just a simple number, just look at the dimensions exposed by Martin Fowler. So, we might have a management problem which should not be handled only via Sonar or alike. From those dimensions I think we might spot some social things;

– I do not believe it’s enough to establish together with the client the rules for Sonar or alike, only use them and that’s it; we have to go beyond;

– We need seniority and human judgment, a tool cannot offer this. It can help, but it cannot substitute them completely;


[1] Michael “Doc” Norton, “Technical Debt”, https://cleancoders.com/episode/technical-debt-episode-1/show

[2] I am still looking for the reference…

[3] Ward Cunningham, “Debt Metaphor”, https://www.youtube.com/watch?v=pqeJFYwnkjE

[4] Martin Fowler, “Technical Debt Quadrant”, https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

[5] Jim Coplien, “Lean Architecture”, https://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208

[6] Michael “Doc” Norton, “Tracking and Managing”, https://cleancoders.com/episode/technical-debt-episode-2/show

[7] Dave Snowden, “Of material objects” , http://cognitive-edge.com/blog/of-material-objects/

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

Forming a team discussion metaphor

Shu(1): I need your help.

Ri: About what?

Shu: Help me with a metaphor. I see teams formed just by simple association of people, at least this is my feeling.  I want to tell my boss, or anyone who does this, that is not quite like this. Sometimes is hard for me to explain a certain subject without being to verbose. But now I need something simple, but powerful to explain what I feel.

Ri: Hmm….[smiling]

Shu: Is hard to start a new battle and a lot of problems will appear because of this …. help me please.

[A moment of silence appears. Shu is looking at Ri puzzled. Suddenly the Ri’s face became serious and his right palm suddenly and firmly is put on the table.]

Ri: Look at the fingers. All have their place.

[Shu looked for several seconds, and put his right hand near Ri’s hand]

Shu: And my fingers are not on your hand and your fingers are not on my hand. Each have its place.

[Ri smiled]

Ri: You see, with this hand you can do a lot of things. It depends on you. The cohesion of the fingers helps in doing different things. They work for a purpose/goal. The same is with people, they are different and they have to work for a common goal/purpose/direction.

[Shu interrupts Ri, like continuing what Ri says]

Shu: And you cannot do that if you are not careful on how you choose those people. If you have a broken/abnormal finger it affects the things you can do with the hand.

[Ri smiled]


From a discussion had with clinical psychologist Dr. Ion Zamfir regarding management.


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

The problem of connecting the dots

Recently I read an article (1) . The article is about Fred Brooks, his book (“‎The Mythical Man-Month‎”’) and the fact that the overhead of communication is direct proportionality with the number of people and  the number of different communication channels, also increases rapidly with the number of employees.

I liked a lot the drawings from the article. It was a very nice representation of this connection between increasing the number of people and increasing the number of communication channels. After I read the article, I realised those images don’t fully represent the whole story.

The following things activated in my head, maybe I am wrong, but still:

1) Max Boisot made similar drawings(2) and observed an interesting thing – yes, at that moment, he was speaking in the context of international terrorism. So, depending on the number of dots he have:

-for N=4 we have 6 possible links and 64 possible patterns;

-for N=10 we have 45 possible links and 3.5 trillion possible patterns;

-for N=12 we have 66 possible links and 4.700 quadrillion possible patterns;

For him dots were the data, links the information and patterns the knowledge. And an important point is to process the patterns.

2) Then I remembered what Dave Snowden said regarding identity in humans, inspired by anthropology :”Identity is fluid in humans, we move between roles depending on context and have developed rituals by which we can temporarily align our identity with a role for collective purpose.”(3)

So, maybe one dot, from the drawing, actually  can be more than one dot because people can shift identities.

3) For sure Fred Brooks was right in the sense that we should not add people late in the project. And yes “‎The Mythical Man-Month” is a wonderful book.

Conclusion: In a sense those drawings, from the article mentioned, made me visualize how nasty things can be. Those drawings are beautiful, but somehow incomplete, is just the tip of the iceberg. They made me understand better how tangled complexity can be.

Regarding the conclusion “les managers doivent s’assurer d’optimiser le nombre de salariés travaillant sur une tâche, ni trop, ni trop peu…” –> I think that, if the manager (first line manager) is not involved in the work(does not interact with the system, is not with the ‘skin in the game’)  the chance to make bad decisions is increased a lot. I think is possible for a project with just 3 people to give a lot of headache. The manager should be aware that:

– there will always be hidden surprises;

– there will be volatility;

– when there is prediction to be sure unpredicted things will pop-up.

Note: The title of this blog post is inspired by (2)


(1) Cadreo, “La loi de Brooks ou pourquoi la multiplication des collaborateurs fait perdre du temps”, https://www.cadreo.com/actualites/dt-loi-brooks-ou-pourquoi-multiplier-les-collaborateurs-sur-un-projet-fait-perdre-du-temps

(2) Christopher  Bellavita, “Nidal Hasan and the problem of connecting the dots”, http://www.hlswatch.com/2009/11/12/nidal-hasan-and-the-problem-of-connecting-the-dots/

(3) Dave Snowden, “Three or five?”, http://cognitive-edge.com/blog/three-or-five/