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/ or use this link https://web.archive.org/web/20091123034027/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/

Crystal (Clear) – Part 3

This is the third part of this series and is about the seven properties of Crystal(1)(2) applied in our context narrated by one of the team members, Alexandra Vasile, so:

“After working in the context of this project I realized that for sure the context on which I worked before, which claimed to be agile/scrum, was out of track. They reversed individuals and interactions with processes and tools.

Our work was to create a tool which helped all the other teams. We needed to move fast, to respond prompt to the unplanned things that appeared, take care not to disturb the others work.

Crystal has the following seven properties. I will come across them and discuss each related to this specific situation:

  1. Frequent Delivery – our work was delivered everyday in the test platform, and was tested by us and by the other teams which used that code. Every month, our code was included in the production delivery. This helped us to have a quick feedback regarding our work and in case of problems we could respond fast. At the begining of the month we did not have the whole picture of what was going to be delivered, at the detail level, we only had the direction of the changes. In a way, problems which occurred on production helped us a lot because it aid more to rafinate our decisions, priorities and daily work. Almost each time a bug appeared everything stopped and we tried to fix it. There are rare the occasions when we postpone one bug for more than a month.
  1. Reflective Improvement – This thought exercise did not happened because a protocol was in place. If it was a protocol, for sure, I did not felt it. Is like common sense prevailed also here. It just happened without too much hassle. We stayed and reflected on 2 occasions: when a bug appeared in production or when the monthly release was done to production. Everytime a problem occurs, we all discussed, sometimes very nervous, tried to find a solution/way to improve and not to make the same mistake again.

If I think better and try to make associations with past work, we had dailys when we took the coffee, but for sure were not those kind of dailys were reporting was done.

  1. Osmotic Communication – It seems this was a critical point in our physical setup. In other occasions/projects although we were collocated actually it did not matter because conversation happened almost exclusively on Skype, so strange. The fact that we stayed in the same office, with the business expert, closed to each other helped us.  We communicated frequently between us, we knew what the others were doing. We didn’t need special meetings for that. We intervened when we heard a discussion between the other team members and shared our opinion/knowledge/piece of advice – we helped each other. This aids us a lot.

We had a Skype group shared with the client. We put on the Skype group, as a profile image, an italian police car and agents from DIA, for us it was a way to say “ok, no fooling around”.

  1. Personal Safety – We felt safe in the team. We didn’t had fear to make a mistake. Our team lead encouraged us a lot, he told us is ok if we also do make mistakes because we learn from that – who didn’t work, didn’t make mistakes. We helped each other, between us it wasn’t a competition. If someone made a mistake, nobody putted him/her on the wall, on contrary it was helped to find a solution. Another thing very important was that we trusted each other. That’s why it’s very important how the teams are build, because if you are in a team where you are not trusted this implies in a way that you don’t have trust in the other team members either. And when you don’t feel safe you will never do your best.
  1. Focus – The team was built specially for this project. It was a very important premise from the beginning that the persons involved will have to work full time on this subject, no part time work or partially involved. It was very important because the work needed to be done involved full concentration. We set from the beginning some premises and we all knew the final scope.
  1. Easy Access to Expert Users – The business expert, the one which envisioned the tool was with us. Also the members of the team knew the sub-parts of the product. When we had some unknowns we knew who were the persons to ask.
  1. Technical Environment with Automated Tests, Configuration Management, and Frequent Integration – Since almost most of our work involved repairing and fixing existing code we needed these changes on the test platform as soon as possible.Without knowing, the other teams by testing their product indirectly tested also our work.

Probably some will say the same things could have been done in other ways. What was nice is that we were able to see another unknown face of agile in this case was Crystal. Our scope was to move fast, to deliver quickly the work which was needed, because without this tool, which we made, they spend more than 90 days to have some things done, which now with the tool are ready in ~20  minutes.”

(1) Alistair Cockburn, “Crystal Clear Applied: The Seven Properties of Running an Agile Project”,  http://www.informit.com/articles/article.aspx?p=345009

(2) Alistair Cockburn, “Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams”, https://www.amazon.com/gp/aw/d/0201699478

Crystal (Clear) – Part 2

In the previous post I tried to describe the why, in this second part I try to describe the context and some particulars.

The vision/direction

The vision of this project was borned because of a pain. Pain experienced by a lot of people trying to make the software work for a new certain type of client. People from all levels of the company were involved. The existing product we speak was formed by 3 big sub-products. This meant that integration between the 3 sub-products had to work. We knew about this problem for some time, but usually people react when there is a great need or a pain. So I waited for this occasion, all the other efforts being useless, to rise the idea that it can be solved and all this integration setup to take ~20 minutes.

The team formation

In those difficult moments, from the start, the right technical persons were being chosen to make the integration work for that new client. After a month of big presure the problem was solved and it was decided that we should make the project. I asked for those initial persons. I did not said: “Please give me one person from project A, another one from project B, and one from Project C”. When I spoke with the responsible for each of the sub-project, I asked them for the specific person. I emphasized the fact that I need those persons, by saying their full name, and that is not a coincidence that is about them. I wanted to show the importance of each of the person needed.

A team is not formed by choosing randomly/available/free people, not at all … is much more difficult.

Before going to speak regarding the possibility to have a new project I spoke which each of the persons which I wanted in the new team. For me it was clear that no other person would qualify, so the project would have been with them or not at all. I wanted to have their approval and permission. I have said to them no platitudes or pseudo-motivation stuff. I say this because otherwise I would have consider that I would tell bullshit and offend them and that is not an option for me. They agreed and so the work to form the team started.

It was not easy, but in the end, the desired team was formed: 5 persons. The respect between us, at least what I felt, was enormous. I realized again that once the right people are in place then we can concentrate on the nasty things from the outside. At least we knew that no problems would occur from inside and I was right. I am amazed of how much energy is lost on trying to solve internal problems just because the team is formed in a careless way, a lot of energy is lost and not on solving the real problem(s).

In all this a wonderful person from the client helped us a lot.

Strategy

We knew what we wanted to do grosso modo. We begun the discussions between us, in Crystal parlance I would say it was the  “Reflective Improvement”. There are many details which can be said regarding how we defined the strategy and documented it to offer vizibility, but one thing I remembered vividly is the technique named “Advocatus Diaboli”(1) which helped us a lot. We knew from the start that the colleague, playing the devil advocate, intention was not to hurt us, not at all. Actually he was more like the guardian angel and this from the moment when that pain begun.

Although we had the strategy, we knew surprises will occur, we realized from the beginning that we will meet those unknown unknowns(2).

Also we decided to use a different style of reporting to show our progress and we used the Parking Lots diagrams from FDD(Feature Driven Development) – we wanted to see better the forest from the trees and also to avoid possible anomalies with the current techniques involved with story points – a future blog post will be done regarding this.

Robustness vs Resilience(3)

We knew we couldn’t tackle an important subject and repair code without causing problems/bugs in production. There were too many instabilities we had to deal with. Even if a  problem would have occured in production, we knew we would have to solve it as soon as possible, to recover fast. This way of thinking helped us not being paralyzed/rigid in our approach. What I can say is that is strange when one team focus on resilience and all the others on robustness(actually was rigidity), still we did not gave up. On each occasion I had, I tried to emphasize the need to concentrate on resilience not on robustness.

The Seven Properties of Crystal(4)(5)

For me these properties were like constraints in the complex adaptive systems. But I let one of the team members to describe these properties in connection with the project, in the next post.

(1) “Devil’s advocate”, https://en.wikipedia.org/wiki/Devil%27s_advocate

(2) Dave Snowden, “The Origins of Cynefin”, http://old.cognitive-edge.com/wp-content/uploads/2010/08/The-Origins-of-Cynefin-Cognitive-Edge.pdf

(3) Dave Snowden, “Risk and Resilience”, https://www.youtube.com/watch?v=2Hhu0ihG3kY

(4) Alistair Cockburn, “Crystal Clear Applied: The Seven Properties of Running an Agile Project”,  http://www.informit.com/articles/article.aspx?p=345009

(6) Alistair Cockburn, “Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams”, https://www.amazon.com/gp/aw/d/0201699478

Crystal (Clear) – Part 1

Recently I saw a video from an agile conference(1). I have looked at the video because of two persons appearing in that video: Dave Snowden  and Alistair Cockburn. Dave Snowden is co-author of DSDM and Alistair Cockburn is creator of Crystal methodologies(2). In that agile meeting, where the term agile was coined(3), these 2 methodologies were represented also.

When looking at this video I noticed one remark, made by Alistair Cockburn, which made me sad, he said: “…….is like Crystal Clear, completely irrelevant…”. Is it irrelevant? For me and my team members surely was not. We have applied Crystal, recently, 2 times:

  • A project started at the end of 2016 and ended in February 2018;
  • A project lasted for 3 months at the beginning of 2017.

I noticed that is hard to use a way of working which is different than the dominant way of working, in this case Scrum – but I think this would have happened also if dominant methodology would have been something else,  because is about people, not methodologies. I noticed that some people, calling themselves Scrum Master or fully devoted to Scrum, if I can say so, were disturbed by this and I do not understand why. I say this because Scrum has its roots also in Toyota Production System, in this sense I try to imagine a great line manager  or a Kami-sama(4) who will avoid learning/investigating/exploring/experimenting something just because “that’s how things are”…

But let me tell you why Crystal proved useful to us:

-it helped us to respond promptly in a multi-ontologic(5) space → we had the properties ( frequent delivery; reflective improvement;  osmotic communication; personal safety;focus; easy access to expert users; technical environment with automated tests, configuration management, and frequent integration)  as guidance then techniques followed;

-It was like a cognitive activation that allowed us to be agile, but also to be pragmatic and solve the problems we had. And yes they, my team, realized they can be agile by other means;

-It helped us to face that volatility is needed ( well actually will appear unannounced)  sometimes in projects, although the trend -in my circles – is against volatility;

-it helped me to think at the granularity(5). I mean how things (techniques, events, formalities) combine. With Scrum, on how was applied and enforced upon on us, we saw we were like paralyzed ( all was very rigid like being strait-laced. What mattered was velocity and predictability. Things were done but without the knowledge of why. We had to put stuff in sprints because we had to fill in those sprints and a lot of energy was lost with that.We were trying to  solve something, but is not that we had clear list of the things to be done; it was about creativity, investigation, experimentation, observation. Yet we knew that at the end of each month things, important things, had to be delivered. Delivered, and as far as I was concerned without useless pressure and fully aware that those things will/might fail and they failed, and it was/should be ok to fail; but things went ok also because of those preceding failures among other things. A short answer would be that people respond to something  based on patterns of the recent past experiences, whether good or bad )

-I like to say that it also solved a sociological problem. In a way, Scrum is becoming ironized, unfortunately, especially Scrum Masters – as I said is about people and how prepared they are and even more their desire to be prepared. Members of my team have had very bad experiences with that kind of Scrum and begun to doubt the religiosity which surrounds it.

I was very proud, that in a monthly meeting, when a presentation was made regarding the ways of working, Crystal was there – in a list of 8 or 10 projects. I think 50 people saw the Crystal in that slide. And when I had the occasion I spoke about Crystal.

Those lines above were written when the big project was in danger of not “receiving the final acceptance”. I was calm because anyway our work was in production already, each month our work was delivered in production and things were ok. And if things were not ok we responded fast. Is important to make this note, because usually the description of something differs depending on the outcome – in this case the outcome was  rather a sad one. The lines above were reviewed by all the team members. And finally, things are ok, it seems.

Crystal is relevant for me, and it was for my team. Each time an intern is assigned to me I’ll take care they will know also about Alistair Cockburn, Jim Highsmith. So maybe Alistair Cockburn work is not lost, for me it matters – I know I am just one person but I am :).

In the next post I’ll detail a little bit the how.

(1) AgileByExample 2017: Discussion panel, https://www.youtube.com/watch?v=WTZlLBUo1gE

(2) Alistair Cockburn, “Crystal methodologies”, http://alistair.cockburn.us/Crystal+methodologies

(3) Manifesto for Agile Software Development, http://agilemanifesto.org/

(4) Craig Trudell,  Yuki Hagiwara,  Ma Jie,”Humans replacing robots herald Toyota’s vision of future”, http://www.livemint.com/Companies/B53nQRpNGDTrVMYrcD1RBK/Humans-replacing-robots-herald-Toyotas-vision-of-future.html

(5) Dave Snowden, “Multi-ontology sense making; a new simplicity in decision making“   http://cognitive-edge.com/articles/multi-ontology-sense-making-a-new-simplicity-in-decision-making/

(6) Dave Snowden, “Granularity”, http://cognitive-edge.com/blog/granularity/

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

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

Now I’ll try to give the long answer:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A longer answer will be published in a future post.