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”,

(2) Alistair Cockburn, “Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams”,

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.


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”,

(2) Dave Snowden, “The Origins of Cynefin”,

(3) Dave Snowden, “Risk and Resilience”,

(4) Alistair Cockburn, “Crystal Clear Applied: The Seven Properties of Running an Agile Project”,

(6) Alistair Cockburn, “Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams”,

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,

(2) Alistair Cockburn, “Crystal methodologies”,

(3) Manifesto for Agile Software Development,

(4) Craig Trudell,  Yuki Hagiwara,  Ma Jie,”Humans replacing robots herald Toyota’s vision of future”,

(5) Dave Snowden, “Multi-ontology sense making; a new simplicity in decision making“

(6) Dave Snowden, “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,

(2) Robert C. Martin, “The Agile Team”,

(3) Dave Snowden, “Managing the situated 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.

Why would you automate, in testing, anything?

If with the word “everything” it was, for me, like an exacerbation regarding automation well with the word “anything” is something else.

Initially I thought that “anything” word is problematic because it seemed like absolute word which ignores  context. But actually – I had to stay and think about it for 2 months – it might open the perspective of making sense of the multi-ontologies. It invites to dig more. Is like putting under the question why bother to try to automate something and because of this, in a way, it points into a direction to take context into consideration. Context which is situational, relational, temporal, …

Why would you automate, in testing, everything?

A bit of context:  I was trying to answer a question Michael Bolton put on the Rapid Software Testing Slack chat group, the question was “Why would you automate anything?”. Yes, it was the word “anything” not the word “everything”. In trying to respond to the original question I answered also to the question from the title of this post. In my head was a mixture of those two different words, strange…

Below are several reasons I spot it about why is this desire to automate, well to automate everything :

– some managers does not have a clue what professional testing is ( by professional testing I mean Rapid Software Testing a Context Driven Methodology). The managers still think of it in manufacturing terms(” automate as much as we can”). And because of this then they want a way to speed up things. They see testing as tangible stuff. When I say management, I’m not referring only at the first level, but at all levels in an IT company;

– some testers who are not aware of their profession. Is a trend now with (using) tools, who encourage this. It seems the marketing promoting the tools is doing a good job. And novices (we should not confuse years worked with years of experience) think this is the way. Then with the help of uninformed management we arrive at the desire to automate everything. Somehow these testers are not aware of the misinformation they are doing, is not an  intentional thing;

– some testers who see the trend( the dominant thinking)  and for their personal advantage go on this path. They don’t care about the interest of the project. This is sick and a unprofessional behaviour which I witnessed several times;

– some programmers who are ignorant of what a tester really does. They think, because of their arrogance, that are too smart to need a tester or to respect him/her. For me this enters in the unprofessionalism behaviour;

– some programmers with good intentions seeing the benefit in automation but trying to make a general rule without having other thoughts. For sure these are not senior/advanced developers. I say this because a real senior/advanced developer knows the plethora of the possible problems and they shut up and think, holistically, before speaking/making a decision;

– a teacher/mentor/manager making their people to think about what it means to automate everything. I can extend here the idea that a tester/programer might do this do investigate/search/discover more about this topic.

Being agile without noise

This evening I remembered how I begun to work and how I made sense of agile. These vivid memories appeared because I saw a person with whom I worked in those days.

I don’t recall, while working there, the word “agile” being pronounced. It was one year and a half after the agile manifesto was signed. I remember now that I saw on the company’s site a page with text and a nice simple image describing the agile stuff, but in a personalized way! I was searching the web site of the company not because I was being told to do it, but because I was curious of what was on their site.

There, in those days, in the day to day work, in a discussion you would have not heard remarques like:

“we are agile”;
“we do scrum”;
“I am a scrum master”;
“I am an agile coach”;
“As a scrum master or agile coach I would…”;
“this is not agile”;
“this is waterfall”;
“ yes we are agile … we have sprints”;
The person I speak about, I think is one of the best professionals I have worked with. I tried to imagine his response on the question “Do you work agile?” or something similar. I think it would have been like asking Morihei Ueshiba if he knows about martial arts. I think his response would have been a smile. A smile letting you know that you started with the wrong question.

At that moment in that firm there were 3 persons like him. These professionals were complete, if I can say so – they were the top of the seniors: good programming skills and knowledge, mentorship, working with requirements, working with the client directly, handling people,… — they were one of a kind.

I saw this guy handling in one day: ColdFusion, C# and C++. And it was so natural to him. I said C# because I went to him with my work which was bad. He asked me  “Why did you do it like this?”. I tried to give him an explanation and I remembered he said stuff, but he saw hesitation/doubt/lack of knowledge/stupidity in me. He took the keyboard and begun to work in my code. He was, in that moment, in a lot of pressure because he had other stuff to finish. I was so impressed on how he begun to program and explain. It was guiding with facts/attitude not just words or platitudes.

You would have gone to these guys and you could have not tricked them with a simple discourse/speach or induce them in error with charm or platitudes.

For them was so natural to be in that spirit. They made no hassle about it. It was like it was written in the manifesto and I did not had the sensation of rigidity in the approaches we made at that time. We made daily and I did not realize I made daily, it was so natural…

I am glad and so lucky that I understood from them how…well you got it.

Conclusion: I think Jerry Weinberg was right when he said that “Agile methods will be successful if and when we stop seeing them as anything other than normal, sensible, professional methods of developing software.”(1)

◎ Image from

(1) Gerald M. Weinberg, “Agile impressions”,

What a Scrum Master should or should not do

In my circles, I see lots of confusions/discussions regarding what a SM should or should not do. I already wrote before about the need of a SM for a project. Sometimes I feel this role is trivialized, that is being used as excuses of not doing things.

“Most arguments seem to be about conclusions, when they’re really about premises”(1) . So the premises:

● Beside the role as a SM or PO, it might happen that the organization will consider the SM or PO also in a position of middle management (PM, TL). But the discourse regarding PM/TL is changed a little bit: The PM/TL has to take care the project is OK, whatever that would mean…

This might contradict the Scrum thinking/philosophy, but this is another story. The idea is that we have to deal with this reality and acknowledge it.

● The Scrum Guide describes SM relation with PO, team and the organization. The Scrum guide might seem simple, but actually I feel it as a rather exceptional condensation of a lot of information. Take for example just the word “facilitation”, I think days can be spent only on treating and understanding this word.

I have some, let’s say, rhetorical questions:

– Shouldn’t a, good, really good, not mediocre, SM understand PO work in order to help him? By this I mean, maybe, to acquire skills of PO. The better the SM understand the PO, the better SM he becomes because he’ll be able to be more helpful for PO (and subsequently for the team);

– Should the SM help the team by removing impediments and creating high value products only by ‘organization means’ and by encouraging them(being supportive)? Where is his personal touch? By ‘organizational means’ I mean that the organization should help the SM no matter the problem, of course via standard tools/ways of working to solve the problems. SM should be creative, be autonomous and adapt solutions to the specificity of each project.

How the SM will really coach the team in self organizing and cross functionality if it does not participate in the current work? Should encouraging with platitudes be enough? Bringing others to do it? Hmmm….Maybe encouraging without facts and actions will have a small impact.

What I want to say is that, maybe maybe, we need to consider that a SM should be also technical. By technical I mean a developer or a tester(I belong to the Rapid Software Testing testing school just to be clear what I mean by tester) or …, so she/he can take info not only from others(like horoscope)  and numbers(we are mature people still)(4).  I think I would phrase it more generally that they should be with the “skin in the game”.

Yes is possible to have the non-technical SM…but…but…this will be helpful, for SM, as rather than rely entirely on the input of the others, SM will be able to make his/her own assessment based on his/her experience and validate it and not take it for granted.

I saw that in delicate situations where a project must be saved a good multi-skilled SM is being put into play, when the others kind of SM are being let aside maybe because is safer…

I feel there is a tendency to put as SM people with no or little experience/knowledge but with good discourse…. – that’s why I am tough! I try to imagine a surgery team in a hospital organized by Scrum, then the SM for that surgery can be the physiotherapist? Just to be clear: Scrum is good, but in the proper boundary.

● Tuckman model(*) of team formation and development. The situational leadership model is changing depending on the stage the team currently is in. So it might be directing or coaching or supporting or delegating. So within the same Scrum team the tactics of SM might or should change.

● Last, but not least, I think is imperiously needed to be aware of the “multi-ontology sense making”(2). I like that this invites us to transcend the type of system we are in. Scrum, in Cynefin(3) parlance, is at the boundary between complex and complicated. But a dynamic of project/situation will not always stay in a certain type of system. What if suddenly from complicated the type of the situation will change between chaos and complex. What should a SM do? Stay and use the techniques/tactics for which Scrum is designed? Shouldn’t try to adapt and consider the appropriate techniques/tactics/measures of action for the corresponding type of system? Ok, it will no longer be SM by the book, so?


So, I hope to see more SM’s:

○ who are very well prepared;

○ that stop using platitudes;

○ that know about Nonaka work ( even if they my not agree with some of his work );

○ who know the work of Jim Coplien (dailys are his idea/inspiration from Scrum; and the technical book he wrote “Lean Architecture: for Agile Software Development” is great);

○ who stop trying to be pseudo-psychologists;

○ who understand that to be a coach/mentor requires preparation, lot of it;

○ who understand that agile does not equal Scrum;

○ who dare to ‘dirty’ her/his hands and to help the team by working effectively in the project, of course, making use of the skills they have when she/he thinks that the benefits of this action are bigger than the possible disruptions;

○ who will have no problem to let another one be SM and she/he be a simple member of the development team, at least temporary;

○ who will realize that she/he is Master not after a few days of training, but after years and years of work and preparation;

○ who understand the job of a developer and the job of a tester, and then realize that you cannot switch one with another with the excuse of self-organization;

I know there are other schools of thought and is ok. I accept their opinion, but this does not imply that I also agree with them. Context matters a lot.

(*)Update February 27, 2018:

I indicated Tuckman model because in the agile world is a very known model. My intention was to show that a team is not in a single state at all, but on the contrary.

I reviewed the original paper where Tuckman wrote about this. Actually this model is not proven. In the initial paper “Developmental Sequence in Small groups”(5) he reviewed the existing literature regarding  “dealing with developmental sequence in small groups” and he suggested  “fruitful areas for further research”. So is a “statement suggested by data presented and subject to further test”.

Ten years after the original paper was published another one was published, “Stages of Small-Group Development Revisited”(6), in order “to examine published research on small-group development done in the last ten years that would constitute an empirical test of Tuckman’s hypothesis”. In the conclusion is stated that “It is noteworthy that since 1965 there have been few studies that report empirical data concerning these stages of group development…There is a need to supply statistical evidence as to the usefulness and applicability of the various models suggested in the literature”

(1) Michael Bolton, “Testing, Checking, and Changing the Language”:

(2) Dave Snowden, “Multi-ontology sense making; a new simplicity in decision making“

(3) Dave Snowden, Mary E. Boone, “A Leader’s Framework for Decision Making”

(4) James Bach, “No KPIs: Use Discussion”, see comments,

(5) Bruce W. Tuckman, “Developmental Sequence in Small Groups”,

(6) Bruce W. Tuckman Mary Ann Jensen, “Stages of Small-Group Development Revisted”,

Incapable to defend real testing

I am a developer, also a Team Lead. I remember now the moment when I realized that if I’m a better developer is also because of the help of a good testers. Initially it was like a cognitive dissonance: how come a good tester help me be a better developer? Even stranger for me was that when I realised this, I was deep involved (still deep involved) with TDD, unit tests and Automated Acceptance Testing.

There are devs who think that if they do tdd/unit tests everything will be ok and testers will do “some clicks”. Or even worse, the testers, for those devs, should check all the nonsense made by a developer, because that developer will not test. So strange. So a developer should not experiment, learn, explore, investigate, find relevant information from his/her own work.

I am sad. I was unable today to defend the real craft of testing (Rapid Software Testing). In a way, I felt that I was not able to defend those testers who contributed to  make me better professional. So strange feeling.

Then I begun to think more. Now is a lot of talk regarding “manual” testing and “automated” testing.

Note: I told to a marketing person that she is doing “manual” marketing. And this sound so strange almost like offending. I told her about testing and “manual” testing and she understood. Still I can’t forget that it almost sound offending.

Why do they say “manual” testing? Maybe because a tester should just verify a specification, no matter the form of that specification – wait, I am wrong, is a user story with acceptance criteria, of course. Since is a clear specification, it is imagined, I think, that they can also write what they will test – some will say they write the test…. Hmmm…So, if they can write it down this means they don’t need a tester with experience – may be temporary – , a junior should be enough because anyway acceptance criteria are done by the Product Owner. But if a junior can do it, then … wait we can automate those steps, yes, yes via UI. So, hmm, why not get rid also of the junior tester, because we have the automation which is the ultimate goal actually. A click of a button and that’s it. For sure that automation code will be developed not by experienced developers like it would be the production code, no, no we have “automation” testers.

So why a tester should matter so much when actually he/she is only doing some of the shallow testing a developer must do? Shallow and clear steps which can be done by anyone.

So, I imagine that’s why – briefly described – some testers are being called manual and automated.

If testers spend time on shallow bugs they will not have time to see for deeper ones. Such deep that neither a dev can’t see it.

But what do those testers that I was not capable to defend? They, although they might not phrase it like this: investigate, doubts, searching for information, pose questions, questions everything, do more than confirm acceptance criteria, they challenge the actual criteria, they make definition of done/ready relative when all the other thinks are clear and absolute, are able to begin testing without specifications if needed, be able to show the multidimensionality of a problem/specification/story, use any tools which can help them (not just selenium or…), they will not answer to different problems with same answer because they are aware of context, support developers, …. please see here for a much longer list:


Sorry colleagues testers :(.