Becoming agile

Agile, through the storms

Archive for the category “Human Relations”

20 Jul 2014

Beaten Team Syndrome

You may have noticed that my blog has moved to the Practical Agile website.

So I have been importing a few old posts, and just posted a new one today. Click to read my latest post Beaten Team Syndrome –

What is it about? Have you seen, or maybe experienced yourself, a team that was taking more and more and more scope, when clearly it will be impossible to them to deliver?

And who tends to take the blame? Of course – the team!

My latest post compares this to a well known social behavior – Battered Person Syndrome, and suggests some practical ways, particularly for the Scrum Master or team lead, to identify and handle it.

As always, please comment – I am always happy to engage in discussion.

Posted in Agile, Human Relations and tagged , , | Leave a comment
13 Dec 2013
5 Comments

Everything is Hunky Dori, Always, No Matter What

What might it mean when you ask someone “how are you?” and the answer is always hunky dory?
Gene Hughson in his latest post  refers to The Daily WTF’s post on a system that never reports an error. This provokes several thoughts.

How it all went pear-shaped

How it all went pear-shaped Photo by Ted and Dani Percival http://www.flickr.com/photos/tedpercival/

1. There is a fantasy to create fail-safe systems. There is a similar fantasy to create fail-safe organizations and teams. The truth is that we would much prefer systems (both software and organizational) that are safe-to-fail. Since most software systems and most organizations operate in complex environments which are impossible to predict, knowing what failed is paramount to the evolution of the system.

In an analogy, we would love that our children will have developed magical qualities to get top grades, be friends with everyone they wish, etc. However, we will become much better parents if we invested efforts to help them let us know when they need our help.

2. In the past, Windows, based on the x86 architecture, had a magical error that told us everything: General Protection Fault. Maybe the fantasy at Intel and/or Microsoft was that the x86 with Windows 3.1 is a super quality system, that fails on seldom occasions, so only GPF is required in such conditions (of course, this is a wild and unvalidated hypothesis for the sake of the argument only).
In practice, Even the infamous Dr. Watson, in “his” first versions, was not good enough to tell us what’s wrong, and additional tools were required.
Luckily today Windows combined with 3rd party tools is much better at telling us what went wrong.
Moreover, modern tools tell us what is going wrong now, and even what is about to go wrong.

3. Conways Law tells us that the architecture of the organization is a reflection of the product architecture (and vice versa).
Relating to B.M’s co-worker in Daily WTF’s post, rather than putting the responsibility on him/her, I wonder if and how their organization is structured to hide faults, and what does it mean to admit having made an error.

In organizational life, when your team members always keep telling you that everything is OK, a good advice is to explore how you contribute together to not telling when they could use your help. What are you collectively avoiding to address the real problem issues.
Parallelly, if you are getting frequent customer complaints that are undetectable before the product is released, a good advice is to explore how your architecture is contributing to hiding away such errors.

Posted in Agile, Human Relations, Quality and tagged , , , , , , , , , , , , , ,
18 Nov 2013
9 Comments

Don’t Worry, Be Happy… Until One Day

Continuing the disclaimer of two other posts I am referring to – this is not a political post.

Gene Hughson has recently written on the US healthcare.gov project, in response to Uncle Bob’s post from November 12th.



This is not the first time that a software failure had caused severe damage to mammoth projects. Here’s a short quote from Wikipedia on the first launch of Ariane 5:

“Ariane 5’s first test flight (Ariane 5 Flight 501) on 4 June 1996 failed, with the rocket self-destructing 37 seconds after launch because of a malfunction in the control software. A data conversion from 64-bit floating point value to 16-bit signed integer value to be stored in a variable representing horizontal bias caused a processor trap (operand error) because the floating point value was too large to be represented by a 16-bit signed integer.”
Source: http://en.wikipedia.org/wiki/Ariane_5#Notable_launches

The emphasis I have added points to a basic flaw in computer programming, often experienced by novice engineers. One would expect that a high-profile aerospace project will hire better engineers than that, don’t you agree?

Uncle Bob Martin thinks so:

“[…] So, if I were in government right now, I’d be thinking about laws to regulate the Software Industry. I’d be thinking about what languages and processes we should force them to use, what auditing should be done, what schooling is necessary, etc. etc. I’d be thinking about passing laws to get this unruly and chaotic industry under some kind of control.
If I were the President right now, I might even be thinking about creating a new Czar or Cabinet position: The Secretary of Software Quality. Someone who could regulate this misbehaving industry upon which so much of our future depends.”

Moreover, Uncle Bob refers to another aerospace disaster – the Challenger explosion, and the engineers’ responsibility in not stopping the launch:

“It’s easy to blame the managers. It’s appropriate to blame the managers. But it was the engineers who knew. On paper, the engineers did everything right. But they knew. They knew. And they failed to stop the launch. They failed to say: NO!, loud enough for the right people to hear.”

In response, Gene Hughson writes:

“Considering that all indications are that the laws and regulations around government purchasing and contracting contributed to this mess, I’m not sure how additional regulation is supposed to fix it.”

Sadly for our industry, I agree with Gene. Yes, engineering practice has, on the whole, a long, long way to go to become anywhere near excellent. I have a lot of respect for Uncle Bob for his huge contribution there.

But the Challenger disaster is first and foremost not an engineering failure. The disastrous potential of the problematic seal was known for a long time before it actually materialized, to everyone’s shock.

““The Rogers Commission found NASA’s organizational culture and decision-making processes had been key contributing factors to the accident. NASA managers had known contractor Morton Thiokol’s design of the SRBs contained a potentially catastrophic flaw in the O-rings since 1977, but failed to address it properly. They also disregarded warnings (an example of “go fever”) from engineers about the dangers of launching posed by the low temperatures of that morning and had failed in adequately reporting these technical concerns to their superiors.”
Source: http://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disaster

At the end of the day, it boils down to the fact that NASA’s leadership were operating under the false belief that with every launch of the shuttle, the risk of the seal failing reduces, completely opposite to common sense.

Mr. Larry Hirschhorn has an excellent description of this in his book The Workplace Within.

In such atmosphere, when my managers, and their managers, are so indifferent to life-threatening flaws, heck, why should I exercise excellence in my mundane tasks? Why should I risk my own livelihood? After all, this is the culture here, in this workplace.

It is heartbreaking that the loss of the Columbia can be attributed to similar management pitfalls as that of the Challenger:

“In a risk-management scenario similar to the Challenger disaster, NASA management failed to recognize the relevance of engineering concerns for safety for imaging to inspect possible damage, and failed to respond to engineer requests about the status of astronaut inspection of the left wing. Engineers made three separate requests for Department of Defense (DOD) imaging of the shuttle in orbit to more precisely determine damage.”
Source: http://en.wikipedia.org/wiki/Space_Shuttle_Columbia_disaster

Coming back to Uncle Bob’s conclusions, in his talk, How schools kill creativity, Sir Ken Robinson points out that the school system, in its efforts to teach, are killing creativity in favor of grades. We can only assume that legislating computer engineering studies will, at best, not harm the existing engineering quality. It will probably achieve worse – well certified engineers, with little ability or drive to excel.

This failure has little to do with teaching and certifications, and all too much to do with culture, professionalism, and plain simple awareness.

When managers practice such “It will be OK” attitude, everyone does. By the sound of it, the healthcare.gov failure discussed here is not that far off.

In 1992, Prime Minister Yitzhak Rabin was speaking at the Staff and Command school to prospect senior officers. Here’s what he had to say about “It will be OK”:

“One of our painful problems has a name. A given name and a surname. It is the combination of two words – ‘Yihyeh B’seder’ [“it will be OK”]. This combination of words, which many voice in the day to day life of the State of Israel, is unbearable.

Behind these two words is generally hidden everything which is not OK. The arrogance and sense of self confidence, strength and power which has no place.

The ‘Yihyeh B’seder’ has accompanied us already for a long time. For many years. And it is the hallmark of an atmosphere that borders on irresponsibility in many areas of our lives.

The ‘Yihyeh B’seder’, that same friendly slap on the shoulder, that wink, that ‘count on me’, is the hallmark of the lack of order; a lack of discipline and an absence of professionalism; the presence of negligence; an atmosphere of covering up; which to my great sorrow is the legacy of many public bodies in Israel – not just the IDF.

It is devouring us.

And we have already learned the hard and painful way that ‘Yihyeh B’seder’ means that very much is not OK.”

Source:
http://www.imra.org.il/story.php3?id=46224

No, Uncle Bob, engineers are not to blame on this. Management must take responsibility for nourishing a culture that allows such poor standards.

Posted in Human Relations, Quality and tagged , , , , , , , , , , , , ,
15 Nov 2013
6 Comments

The Sovietization of Scrum

When I just finished reading Gabi Steinhardt’s The McDonaldization of the Development Team I felt angry, almost furious, and a strong urge to utter on the keyboard what a load of nonsense this is. And then I stopped and thought to myself – why am I so angry? The answer, so I believe, is that in many ways Gabi is right. That is, he is getting many of the facts wrong, but he is not alone there – similar misconceptions of Agile and Scrum are being made in many organizations and by many experts.

There must be something else. Many Agilists claim that agility is the right thing for today’s ever changing pace, need for speed, yada, yada, yada – you know the drill. So how come many Agile implementations fail to deliver? The answer must be elsewhere – or at least, in Agile and some other thing or things.

This is what made me so angry. Although Gabi’s comparison of Agile and McDonalizing is, in my view, wrong, he is right in saying that Scrum in particular, and Agile in large, are weak in addressing the notion that resistance to Agile has a meaning. That there is a meaning behind what goes on in an organization deciding to adopt Scrum on one hand and in-practice, at the same time, sabotages its own decisions on the other.

But first, let me address some facts gone wrong in Gabi’s post.

The Industrial Revolution

All the facts in this part of the post are correct. I wish to add another observation which is missing, yet extremely relevant:

Prior to the Industrial Revolution, the social structure was very clear: You could either be Royal, Noble, Knight or Peasant. The class of your parents would determine your class, and that’s it. Your professional status, on the other hand, was quite different: In the craftsmanship process, you would start as an apprentice, learn for years, and hope to become a master. You’d hope that your master would “kick the bucket” or a master in a near town would, and so you’d have the opportunity to become one. The learning process itself was not standard and not proven.

Classes were very clear; Professional path wasn’t.

Then the Industrial Revolution came: All of a sudden you could get a job that respects its owner very quickly. You’d apply to Ford, get trained, and Hey Presto, you have a profession. Your stature, on the other hand, became very unclear. Noblesse and Knighthood gradually became not strictly Blue Blood anymore. Peasants of old all of a sudden became respectable citizens.

Classes became unclear; Professional path was.

And then the Post Industrial Milieu came: Professions became complex and complicated. Becoming a great Programmer (a craftsperson, or Master) involves a lot of learning, as well as vast experience. The same goes for a master of Product Manager (where do you get a degree in Computer Product Management?). At the same time, the social structure is vague: a degree-less person can come up with an idea for a small operating system, and become the richest person worldwide, not to mention one of the most influential ones – a position once reserved almost uniquely for Kings and Queens.

Classes remain unclear; Professional path also becomes unclear again.

The McDonald Way

Nothing more to add, other than that The McDonald Brothers, descendants of Irish immigrants to the US, established a single restaurant in 1938, developed their own “Speedee Service System”, and franchised the largest food chain ever starting 1953.

Unclear class structure and unprecedented career path. Point above proven.

The Scrum Development Team

This is where Gabi’s blog post symbolizes what takes place in so many organizations: misinterpreting the original intents of Scrum and of Agility. Please don’t get me wrong – this is not a criticism against Gabi. Nor is it an attempt to say something bad about such organizations. This is a fact: Agile is failing miserably in delivering its message to the world. I would make a wild guess that about 5% of Agile transitions become successful in a reasonable period of time. Not so complementing for Agile.

Examples from the post:

“[Scrum]… guidelines are reminiscent of mild to extreme socialist-economic models…”

Agile and Socialism are very, very much apart from one another. To name one major difference, Socialism calls for uniformity; Scrum advocates “One size does not fit all” – even within the same organization and team.

“Scrum recognizes no titles for Development Team members other than Developer…”

There is confusion here between title and role. A Developer can, and is expected to take the role of, for example, a Programmer, and it will be a disaster for the team if this particular person would write technical documents – and the team, all Developers in the team, are expected to recognize that.

Coming back to the opening of the blog post:

“Over that last decade we have seen […] Agile software development methods […]” (emphasis not in original).

Agile and Scrum and other similar modern organizational concepts, do not define themselves as methods. Instead, they define themselves as frameworks, which, the organization is expected and encouraged to adjust and then inspect-and-adapt indefinitely.

“So what can we expect when we take a […] team […] of highly competitive and smart individuals?”

It so emerges that Scrum does not encourage hiding competition within the team. Nor does it suggest that competition is neither bad nor good. Instead, taking Gabi’s example, competition is there, and the team and its eco-system should practice examining whether such competition is helpful or detrimental. Thereafter, team members should decide together how to address such competition.

So where did we go wrong?

I am suggesting that there is something else lurking here. Agile is failing because practitioners do not recognize that the resistance has a meaning. Conversely, organizations that relate to this resistance as meaningful data succeed in addressing them, become successful in implementing Agile.

For example, resistance could symbolize the fear within management in light of the extreme uncertainty. Even if this organization did, with great intention, everything Gabi himself advocates, I wish to hypothesize that they would still sabotage Gabi’s advice because the uncertainty as a source of fear would still remain.

The fact that these (more or less) 5% of organizations transitioning to agile succeed is not merely because they are becoming Agile. I wish to hypothesize that they succeed because they are conscious of potential sources to make them fail.

That is why Agile is still failing, as will any other new buzzword in this industry.

Yes, business people and engineering people should communicate better. Yes, business people should have a clearer say than is currently prescribed by Scrum. Will writing this on a manifesto and advocating it help? Hell, no. Well, not until we look at each specific organization with its own unique and concrete fears, anxieties, pitfalls, etc., and stop looking for any kind of silver-bullet that will save all organizations.

Posted in Agile, Human Relations and tagged , , , , , , , , , , , , ,
08 Oct 2013
6 Comments

Gantt Fetish

“A fetish (derived from the French fétiche; which comes from the Portuguese feitiço; and this in turn from Latin facticius, “artificial” and facere, “to make”) is an object believed to have supernatural powers, or in particular, a man-made object that has power over others. Essentially, fetishism is the emic attribution of inherent value or powers to an object.”
Source: Wikipedia, http://en.wikipedia.org/wiki/Fetishism

Engineering projects, and software projects are no exception, tend to become complex and challenging. Naturally, the bigger and the more individuals are involved in making it, the projects becomes more complex.

Also naturally, when organizations make projects, they wish to simplify them. To make them more visible and understood, so that they are more controllable and manageable. One aspect of this complexity is to understand the dependencies between steps towards completing the project.

Luckily there is a widespread tool to achieve visibility of such dependencies within the project: The Gantt Chart.

“A Gantt chart is a type of bar chart, developed by Henry Gantt in the 1910s, that illustrates a project schedule. Gantt charts illustrate the start and finish dates

of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e. precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical “TODAY” line...”
Source: Wikipedia, http://en.wikipedia.org/wiki/Gantt_chart Emphasis added.

A typical Gantt chart might look like this:

A Gantt Chart

Source: de.wikipedia.org, http://commons.wikimedia.org/wiki/File:OpenProj-screenshot.jpg1

The advantages of such a chart include that it can quite clearly show the project’s critical path, its progress (how much was done, and how much is left to do), when to expect its completion, and more.

How does this relate to fetishism?

Let’s describe a plausible scenario of creating a Gannt chart with dependencies in a project. Our project consists of changes in three integrative products and ten teams of engineers across these products. In the beginning, product managers in each of the products create a list of requirements, and lay them
down on a Gantt chart, and then they work together to combine a composite Gannt chart to visualize the expected work on the entire project, including all three products.

So far there is some waste in this approach, yet it could be attributed to a necessary waste2.

At this point I wish to draw your attention to a feature of Gannt charts: the milestones, typically denoted as a diamond symbol (‘♦‘), as in the chart above.

In order to meet a milestone we need to know whether there are dependencies between tasks, and in our plausible story, the VP development has asked all teams to provide all dependencies in the project: which team/person you depend upon, and which team/person depends on you. “Please provide this
information by end of the week”, said the manager.

Of course, none of this can occur in your organization. This is only hypothetical. A hypothetical plausible scenario.

The result is that all teams and all their managers are now engaged in reviewing all the activities to be completed by the end of the project, attempting to provide dependencies.

This is likely the complete opposite of principle #7 of the agile manifesto: “Working software is the primary measure of progress”.

And yet, all these people are now working towards a common goal: provide all dependencies by EOW.

Recall that fetish “is an object believed to have supernatural powers, or in particular, a man-made object that has power over others”.

Seemingly this is good: Everyone, or at least many, are now working together towards a common goal. However, the object of this goal is not the real thing (making working software). Rather, all are working towards an object that is believed to provide powers that will enable managers to better monitor and
control the execution of the project. Nothing to do with working software. Nothing a sensible customer will be willing to pay for.

Moreover, among the top reasons for project failures are changing requirements (11.8%), unrealistic expectations (5.9%) and unrealistic timeframes (4.3%), according to the 2011 Standish Group Chaos Report. According to State of Agile 2012 report, the second most important reason for going Agile is changing requirements, by 29% of respondents.

It goes without saying that investing days of work in getting all known dependencies in a Gantt chart (or any other media, for the sake of the argument) is a largely futile exercise.

In his 1988 book, The Workplace Within, Larry Hirschhorn refers (to management training techniques) as follows: “[These]… will fail, of course, if the technique functions as a fetish. Fetishes are not transitional objects. Like sexual fetishes, they block relationships between people and are used inflexibly. Social-scientific methodologies that are used indiscriminately function as fetishes.”

I do truly that Gantt charts are a good thing – as long as they are not being used indiscriminately. I have worked with a Scrum team that produced a Gantt chart during every Sprint Planning ceremony. At first I felt opposed to the idea. I talked to the Scrum Master about it, and he said it’s working for them, and I said nothing more. The truth was that it was working for them – it helped the team deliver more responsibly and predictably.
A few months later, they stopped using it – the tool was not required anymore. They were not using it indiscriminately.

At the end of the day, the object of our work is working software. Visualizing dependencies or milestones or critical paths is important if, and only if, it effectively contributes to the working software of the project it relates to.

Update – 2013.10.15:
In response to referring to his book, Larry Hirschhorn points out Eli Goldratt’s Theory of Constraints as an alternative to mapping dependencies (Thank You!).
My interpretation is – rather than spending time on identifying dependencies, look for bottlenecks (“Buffers”, in Eli Goldratt’s terms) and attend to them, until new bottlenecks are found, and repeat forever. Set the pace of the process according to the observed pace of the slowest bottleneck (“Drum”), and let all other elements in the process observe this pace (“Rope”).

1Gantt chart image by Projity Incorporated (http://www.openproj.org/product-overview) [GPL (http://www.gnu.org/licenses/gpl.html), GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)%5D, via Wikimedia Commons

2of course one could argue that this whole concept is a waste: that creating a single backlog and not attempting to draw the anticipated progress is more sensible. This may be the topic of a separate blog post.

Posted in Agile, Human Relations and tagged , , , , , , , , , , , , , ,
10 Jun 2013
1 Comment

Scrum Master is Not Merely a Facilitator

For some reason, for many the essence of the Scrum Master role boils down to: “remove impediments for the team” or “is responsible for the Scrum process”.

Others declare that “the Scrum Master is a kind of a PMO”, or “a facilitator for the team”. Not that it is not part of the Scrum Master role – but it certainly is not the essence.

Furthermore, such statements are demeaning, in my view. Strong word, and yet, making statements such as the above, to me, indicates that the speaker may not yet understand what agility really means.

And please don’t get me wrong – it’s not that I think that facilitation is something to look down at. On the contrary – facilitators can save a conference from failing miserably. Similar arguments can be made on PMOs. These roles and professions are important and significant in their own right. But this is not the essence of the Scrum Master. Moreover, it takes courage to step out of these simplistic views of the Scrum Master, and delve into the complexity of becoming one. What follows is highlighting the other, more important, aspects of being a Scrum Master

Photo by OregonDOT, source: http://www.flickr.com/photos/oregondot/6235421713/

Read more…

Posted in Agile, Human Relations and tagged , , , , , , , , ,
27 May 2013
3 Comments

There’s a lion lurking in the organization

(Or is agile just another way of hiding it away?)

Imagine the following scenario

Fred is a senior developer. The team is doing Scrum for about 10 sprints now, and the ceremonies are kind-of getting into a routine. The team is committing for work to do, and delivering more-or-less what they promised. And yet, Fred is not a happy chappy.

The team is coming to their third release, and there are talks that regression period must be on time, on track this time.

In his frustration, Fred talks to his Scrum Master, expressing his concern that developers must do regression testing yet again in the upcoming regression period. Clearly developers should do coding, and testers should do testing.

Joe, the Scrum Master reminds Fred that regression is for the entire team, not just for testers, and that they are all in the same boat, and that by coding away during regression they are merely adding more technical debt to an already potentially unstable release.

Fred walks back to his desk, muttering “right; and my testing skills are so good, that all bugs will be uncovered. Such a good tester I am”.

What just happened here?

What are Fred and Joe really talking about? What aren’t they talking about?

Given the conversation of these two individuals, what can we say about the atmosphere in this team?

Teams, Organizations and Lions

There is a lion lurking here.

A normal person reaction to seeing a lion would be: increased alertness, increased heart rate and increased perspiration – the automatic physical reaction required for survival in face of danger. This is vital for survival, yet not a pleasant experience.

Therefore, a normal person, having the knowledge that a lion is lurking would act to avoid being seen by the lion: Acting cautiously, refraining from conspicuous and sudden gestures.


Photo by cheetah100 source: http://www.flickr.com/photos/devcentre/327960789/

Let’s relate this back Fred and Joe. Fred might be trying to say: I’m a damn good programmer, and by doing testing, I will be exposing my weaknesses. This is something I am not prepared to do!

Joe, on the other hand, is hiding behind Scrum (teamwork, technical debt) in order to avoid Fred’s issues. He is using Scrum as a defense mechanism against dealing with what Fred has to say.

The thought of confronting these covert issues provokes anxiety. As if Joe is telling himself: I am afraid that if I talk to Fred directly about his subjective experience of being a tester, it may feel as if a lion is about to attack me. I am not prepared to handle such an experience.

Of course, both Fred and Joe don’t necessarily articulate these thoughts to themselves. This, in itself, is too frightening. So they both unconsciously use their survival mechanism not to wake the lion lurking in the grass:

Fred resolves to focus on developing new stuff; Joe is using Scrum to get Fred to do testing, as he thinks the entire team also should.

Dealing with Lions

Is Scrum to blame here? Is Scrum in particular, and Agile in general doomed to fail in such situations like all other organizational methodologies?

I think not. Read more…

Posted in Agile, Human Relations and tagged , , , , , , ,
17 May 2013

My name is Acme.com, and I have ADHD

I attended a conference on ADHD recently, and, while I discovered that probably I, too, suffer from some form of ADHD, it occurred to me that many organizations I work with, and worked at, also suffer from organizational ADHD.

What follows in this blog post is describing what is ADHD and some of its symptoms of ADHD in humans, their manifestation in organizations, and how agility may serve as a treatment.

To begin with, ADHD is not something you cure. It is something you learn to live with, sometimes to the extent that the well-being of the individual (or the organization) is not impacted by ADHD. At others, it is something one must be aware of, and accept its limitations and drawbacks. What more, there are some qualities that significantly define the population of individuals with ADHD – they are pleasers, keen to succeed, tend to be artistic and creative, and more. I wish to hypothesize the organizations with ADHD also have such collective qualities – but this will remain for further analysis.

A disclaimer

This blog post is what it is – a blog post. By no means does this even attempt to be a scientific work, nor is it based on extensive empirical data. It is based on my own experience, with my own subjective analysis, and lame insights.

The reader’s initial response is likely to be ‘surely not our organization’. And yet, let me share some of my thoughts following the conference. Please revisit your original thoughts after reading the entire post.

ADHD in Organizations and Potential Treatment

In this post I discuss Scrum as a potential treatment. If you like, Scrum to organizations is like Ritalin to humans. (I actually intended to have this as the title, and opted eventually to the existing one).


Photo by unfolded, source: http://www.flickr.com/photos/unfolded/3698543176/

ADHD is transparent

Transparent in humans

First and foremost, people (and children) suffering from ADHD do not know that they suffer from something. Anything. It is transparent. And by that I mean in several forms:

It is transparent in the sense that individuals suffering from ADHD commonly looks like any other person. Yes, they have some subjective difficulties that they try very hard to hide, so others will not think they are different or lesser than others. They try very hard to stay within boundaries – something they find incredibly hard. They do so because they want so badly to be good – and they are considered good children or person.

Transparent in organizations

Now let’s talk about organizations: If you think that your organization is potentially really good, and that you are trying very hard to keep it a good one, and you are convinced that other organizations are also the same – please read on. What comes next might also be relevant for you.

Note that I am not trying to say that something is wrong with your organization. It is transparent, remember? It is seen as a problem neither from the inside nor from the outside.

Scrum and Transparency

Scrum is about transparency. It is about taking empirical data relevant to your own organization, and using it to find out what your organization is really like.

Take, for example, this video (watch until about 16:00): http://youtu.be/IyNPeTn8fpo?t=13m33s

ADHD is about Attention Deficit

Attention deficit in humans

Individuals suffering from ADHD find it hard to stay focused – to maintain attention for long periods. That is, a child with ADHD can sit on the chair for hours on end doing homework. But in practice, within the first minute they run off the subject, moving to other things. Any disturbance – either external or internal will get them out of focus.

When reading a book, they will get stuck on the same line and read it again, and again, and again. If there’s a fly in the room, they will have to read the line again, because the noise distracts them. If they just recalled something that happened at school, they will need to read that line again.

Attention deficit in organizations

Take support for example: What do you do in your organization when a P1 support call comes in? Can the team still focus on existing requirement? Or do you turn to the P1? How about P2? How about a medium priority bug? How about when someone has a question to ask the team?

Often teams will work on multiple concurrent requirements, increasing the spread of effort and reducing the focus.

If this hits a chord, you might have organizational ADHD.

Scrum and attention deficit

Scrum provides a prescription of practices, aimed, among others, to focus the team frequently and effectively.

The team works in short sprints – preferably one week long, starting with a planning session – what will we do this week, and ending with a review – what have we accomplished.

In between the team will meet daily to plan together the daily tasks.

Scrum training and coaching also advocates focusing on few things during each day. Virtually every Scrum training graduate can quote the proverb “Stop Starting Start Finishing”.

ADHD interferes with organizing things

Organizing difficulty in individuals

Next, individuals suffering from ADHD find it very hard to organize themselves. They find it hard to maintain sequence of things, to make order of information, to focus on a single solution. Some individuals just can’t organize, and struggle with it frequently. Others find it helpful to organize meticulously, making sure, for example, that everything is prepared to the last detail in the evening to get it right in the morning. (For this reason, some individuals are wrongly diagnosed as suffering from OCD [Obsessive Compulsive Disorder] or only from OCD, while their obsession is secondary to the underlying ADHD). Treat the ADHD and the OCD will reduce or disappear altogether.

Organizing difficulty in organizations

Let’s get back to your organization. We already know that it is a very good one, and that you are trying very hard to keep it that way, despite the difficulties.

Do you find that your organization has difficulties to focus on things? To order the requirements correctly? To make sense of the right sequence to do things?

On the other hand, do you find that your organization is obsessed with planning, to get it absolutely right? Maybe even yourself? Maybe someone you work with? And do you, or colleagues, find it traumatic that things don’t go according to plans? And then you are disappointed that you did not plan well enough in advance?

Do you frequently find that integrations are hard? That deciding when to do the integrations is tough?

Have you experienced that prioritizing is particularly difficult? If you are working in a development team, did you ever find that deciding when to start testing your code is challenging? That in your team it is ‘easier’ to assign individuals work on one thing, and in practice everyone, or most, get eventually involved in everything, and that things then just don’t finish? Oh, oh, hold on to that thought – I am jumping ahead of myself. First let’s look back at Scrum.

Organizing difficulty and Scrum

Scrum prescribes two backlogs: The product backlog, and the sprint backlog.

Product backlog is intended for the upcoming 2-4 sprints, maybe the upcoming quarter.

Sprint backlog is intended for the upcoming sprint.

In both cases, Scrum prescribes to prioritize the backlog in ascending order. There will be no two items with the same priority.

This is hard to do, to begin with. And it is critical to having things organized such that the organization can focus better on what to do now and next.

ADHD and procrastination

Procrastination and individuals

Now that’s a real killer. A small confession: I mentioned that I recently attended a conference on ADHD. That was back in March. To be precise, it was on March 1st. The idea for this blog post was born that day. 77 days later I am finishing it up, with 76 days of zero progress on it.

As it turns, individuals that suffer from ADHD tend to procrastinate more than those who don’t. As a result, these individuals find themselves in a situation that they must start many things late. As a result of that, they find that they do not finish things.

For example, a person having ADHD condition might start to read several books in parallel, finishing only some, or none of them. Sometimes this person will only read the first few pages, and, although he or she really wants to read the book until the end, they cannot bring themselves to it.

Coming to the first point, that people with ADHD try very hard to be good, this puts them in an impossible situation: they simply cannot finish that book, and then they think that they are lazy and incompetent. Often, others will ‘helpfully’ tell them that they are lazy. Or incompetent. Or both.

Procrastination and organizations

Can you spot procrastination in your organization? Can you find that things are started and never get finished? That many things are being done in parallel, and few, or none, get really Done (and here’s a hint towards the Scrum treatment)?

And how do you feel about that? How do others make you feel about that? Do you think that, despite trying very hard to be really good, you feel that collectively you are lousy because you never or rarely finish things?

It is common to procrastinate in organizations – at the individual level, at the team level and at the greater circles as well.

Procrastination and Scrum

Scrum recommends defining a good Definition of Done, one that gets revisited now and again to reflect the changing maturity of the team. Done may mean finishing coding, or it may mean finishing coding and unit testing, or it may mean that Done is accepted by the customer.

Whatever the definition, the notion of Definition of Done provides the opportunity to realize whether collectively you are accumulating technical debt (that is, procrastinating), or not. Conversely, whether you are really finishing things off before moving on to the next ones.

ADHD and self-esteem

Self-esteem and individuals

As you may notice, there is a build-up of a vicious cycle that characterizes people suffering from ADHD. A person that has ADHD tends to be very critical of him/herself. Boys tend not to cry, and instead to come raging from school, and act it out instead of talk about it. Girls tend to cry it out in what seems to be hysteria.

It so emerges that these people tend to be more suicidal than others. Both in thoughts and in action.

Self-esteem and organizations

Back to your organization: Have you ever thought, or talked to someone that this place is going nowhere? That we are doomed? Does your organization tend to let-go of key individuals?

When things don’t go as you expected (and they never do) – do they get discussed? Or do they, instead, manifest in shouting, fighting, and other aggressive behaviors (a “boyish” organization)? Or do they manifest in whining about it, without actually talking about the real problems (a “girlish” organization)?

Self-esteem and Scrum

There are very few measurements I advocate. I can most likely make you discard any measurement you come up with by proving how it can be gamed, either consciously or not.

One indication that does help indirectly is a “fun-o-meter” – how good does it feel to be a member of your team?

I find that there is a strong correlation between self-organization and a working Scrum to the feel-good factor of a team. This comes both from what people are reporting and from my own subjective experience of working with a team. My own humble experience consists of probably a few dozens of teams. And I hear the same from others who witness successful Agile implementations.

Other ADHD symptoms

ADHD has other symptoms, and this post is already getting too long to detail others. At this point I wish to discuss the “treatment” part, in particular the contribution of Agile frameworks.

This post is not a comprehensive detail of ADHD symptoms, nor is it a comprehensive description of Scrum.

A dose of Scrum for Organizational ADHD

I will begin with some reservations. If the first part of the post appeals to you, you should be aware that not all organizations have all symptoms. Some organizations have some of the symptoms, but not all; some (probably not many) have none.

Note also, that Agile is not a ‘magic pill’. Neither is Ritalin. Sometimes it helps, sometimes it doesn’t, and at others it should be combined with other types of treatment.

The important things to remember are (and this applies both to Agile and to Ritalin…):

  • A lot of patience is required. Adopting agile is a frustrating experience. It might take a while before results show. It might take longer before the original goals are met – maybe even never.
  • Not all practices will work for you. The right ones need to be tried out and tested based on empirical data – what, in the middle and long term, does this do to your organization. TDD might be the right thing to do, it might not. It might not be relevant now, and might become necessary later on.
  • Collecting empirical data is hard! It requires focus, discipline, stamina, order, following sequences – the very things that are hard to do with ADHD. You will need responsible adults (parents or managers) to make it sustainable. If you are in management, this clause is intended for you!
  • In this post I have used the most popular Agile framework, Scrum, to exemplify how this treatment makes sense. Other agile frameworks may work better for you. Maybe non-agile frameworks are right for your organization. TOC (Theory of Constraints) is one such example.
  • Agile is not the only ‘cure’. I am a great believer in Agile – and you are welcome to take everything I say with a pinch of salt. I stand corrected – I encourage you to challenge me.

    How many Scrum pills a day should I take to get cured?

    I hope that this post is indicative enough to suggest that if done properly enough, Scrum may be a treatment to alleviate the ADHD symptoms of the organization.

    It is important to understand that’ like ADHD in individuals, there is no cure. Sorry to be the baddy on this. People don’t get cured from ADHD – they learn how to use the right treatment to live with it adequately. Organizations cannot be cured from Organizational ADHD – they either die, or use a treatment, such as Scrum, to avoid their dysfunctions resulting from their ADHD.

    Going back to transparency, Scrum doesn’t solve your problems; it makes them visible. Just like ADHD is transparent until you get diagnosed. Once you start doing Scrum, problems emerge, ones that you didn’t know they existed before. Quite often we hear that Scrum is creating problems in the process. This is like saying: “Until I started using Ritalin everything was great! Since I started it seems that I am crap in math. I’d rather not use the medicine, and not know about it”.

    Many of the Scrum practices sound counter intuitive initially. Try explaining to a child that watching TV is not going to help him/her do their homework, or that reading five book concurrently is not good for their book report.

    Similarly, explaining that feature-teams and cross-functional-teams are good is no easy task. This is a result of not seeing the problem – the same as a person that resents taking Ritalin because he/she does not accept the ADHD condition (in denial).

    We have completed our Scrum dosage. Are we done now?

    It is quite self-explanatory that if you don’t see the problem, and you don’t think you have one, you also don’t want to get help. Moreover, if, for example, there is an expert in the picture that tells you that you are procrastinating – when you are convinced that you are not, you will resent hearing about it. The contribution of Scrum (and Agile in general) is that by retrospecting frequently, there is a good chance that by reflecting with supporting empirical evidence, at some point, hopefully sooner than later, the team will accept that treatment is required.

    Retrospectives can become boring, and it is a good practice to play around with retrospective practices in order to get the team engaged.

    To analogize with ADHD in individuals, sometimes Ritalin works well, then Concerta may work better, and at others you may try out CBT like Attengo.

    Scrum beyond the organization

    It is worth mentioning that the Scrum practices are helpful not only in organizations – also in families. The book Agile Kids is a good example.

    Other thoughts

    I already mentioned that I wish to explore the relatedness between “Organizational ADHD” and creativity. If you have any information or input I will be happy to hear about it.

    I also mentioned that this post is not based on scientific evidence. It will be interesting to turn this hypothetical article into a research topic.

    Finally, if you are interested to learn more on this, or on other topics, feel free to contact me either by commenting on this work, or through the contact-me page.

Posted in Agile, Human Relations and tagged , , , , , | Leave a comment
16 Apr 2013
2 Comments

On Leadership, Humility and Independence

Today is Independence Day in Israel, and I want to share a short story on leadership. It is a story my dad told me many years ago.

My father served during and after the War of Independence under the direct command of General Sadeh, by then a highly acclaimed military officer. Following the war there was a major military exercise, and, as army exercises go, there was a recess for lunch. A temporary camp was set up; large tables were set with big vessels containing food. Soldiers queued up, mess-tin ready in their hands, and, when reached the large tables, those on duty served them.


Military Mess-tin. Credit goes to Collectors and Collections Forum in Tapuz (Hebrew)

Nearby another table was set up: chairs on either sides of the table, soldiers on duty serving the people sitting at the table. These were the officers, in charge of the exercise.

And then the command car arrived. General Sadeh, along with the rest of the people in the command car got out of the vehicle, and went, mess-tin in hand, to queue with the rest of the soldiers.

Needless to say that the rest of the officers, the ones being waited by other soldiers, did not know where to hide.

To this day I recall the sense of awe when my father told me the story. Not the kind associated with fear, rather with respect and trust.

General Sadeh did not stay with the army much longer afterwards. The story goes back to 1948, and Sadeh left the army in 1949, possibly due to some kind of political disagreement. He remained a much respected leader until and after his death in 1952.

There are many kinds of leadership, matching various conditions. It is often said that in the military a coercive, command-and-control is typically more suitable. Here’s one example of a leader that combined many styles of leadership, at times counter-intuitive, and yet has won the trust and respect of many, with unquestionable achievements. No doubt his opponents had much contribution to his retirement from the army service. Maybe even to his early demise. His legacy as a leader remains long after some of them.

This story tells me that it is not enough to sit at the officer’s table to become a respected leader. Sometimes, the opposite is true.

Posted in Human Relations and tagged , , , ,
18 Feb 2013

CoachRetreat – There is such a thing!

Imagine you are in an important meeting with someone, say a frustrated team member, and as soon as the meeting is over you think to yourself: “DOH! That was not how I meant it to be. I wish I could do it all over again”. Sounds familiar?

Well, sometimes you can!

It is called a CoachRetreat, and it allows you to try out the same situation multiple times, in several coaching techniques.


If have been very fortunate to co-facilitate with Yves Hanoulle such an event at the end of January, the third of its kind and the first in Israel.

More about this event, and also where do you need to do to attend one later in this post. If this is what you’re after just scroll down to Upcoming Coach Retreats – I will not take any offense 😉

First – what is it?

The idea came about from Oana Juncu and Yves Hanoulle, and is derived from combining two ideas Code Retreat and Coaching Dojo.

What’s a Code Retreat? It is a day-long event, during which participants work in pairs to solve the same kata, a programming problem, in several techniques and constraints. The solution to the problem is known, so participants focus on learning and excelling their engineering skills, and having fun at that.

What’s a Coaching Dojo? It is a short session, during which participants work in a small team to solve a kata, a coaching situation, they choose. One person or more are the Seekers (e.g. person or team seeking a solution to their problem), one person or more are the coaches, and the rest are observers. At the end the debrief together. So it’s taking a normally frustrating situation, and practicing it in a fun environment and getting timely feedback from peers.

Add 1 to 1 and now you have a Coach Retreat: It is a day long event, during which participants choose a kata, a coaching situation, and practice it in small groups multiple times during the day in various techniques.

How does it work?

The day begins with a short introduction and check-in (“Sad, Mad, Glad, Afraid“)

The group then chooses a kata.

The group then repeats five times:

  • Explain a technique in the large group
  • Split to small groups
  • Repeat 4 times:
    • Simulate the situation of the chosen kata in the learned technique
    • Debrief
  • Debrief in the large group

During the event participants are encouraged to contribute to a A-Ha wall – sharing and posting on it those insightful moments they have had during the day.


A-ha wall. Find more photos at http://www.flickr.com/photos/yveshanoulle/8437662905/in/set-72157632673041156

At the closing of the day there is a general debrief in a Circle of Questions.

The following coaching techniques were tried out during the event in Israel:

  • Solution Focused (or Futurespective, or History of the Future, if you like)
  • Yes And
  • Appreciative Inquiry
  • Pair Coaching
  • Click Rewind
  • Crucial Confrontations

You may read more about these techniques, including links to more details and proposals to additional ideas in the CoachRetreat website here.

At the recent event in Israel we managed to do more – something I personally feel very happy about: the Coach Retreat was sponsored and participated by three competing agile consulting organizations: Agile Sparks, Agile Planet, and our company Practical Agile. So participants could benefit from the knowledge and advise of six professional agile experts, working together in the same event. Following the success of this event, I hope to see more collaborations like this between us.

The CoachRetreat was great fun. I truly believe that fun at work is significant enough to mention it first – when we feel fun we work better and learn better. Certainly it helped this event become successful. During the day and afterwards I received feedback that the day is very meaningful for them – indicating that the format is generally good.

Sounds interesting? Do you feel you should attend one?

Upcoming Coach Retreats:

London on March 16th – http://skillsmatter.com/event/agile-scrum/coach-retreat. The event takes place at Skills Matter eXchange, and facilitated by Oana Juncu and Marcin Floryan.

Belgium on May 11th – http://www.co-learning.be/CoachRetreat/11052013. Exact location to be defined. The event will be faciliated by Yves Hanoulle.

If you are interested in organizing a Coach Retreat in your community, please do not hesitate to contact either:

Oana: @ojuncu

or Yves: @YvesHanoulle

or me: @kirschi_


Posted in Agile, Human Relations and tagged , , , , , , , , , , , , | Leave a comment

Post Navigation

← Older Entries