Becoming agile

Agile, through the storms

Archive for the tag “Larry Hirschhorn”

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

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.

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.

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


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

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,

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 activitiesGantt charts can be used to show current schedule status using percent-complete shadings and a vertical “TODAY” line...”
Source: Wikipedia, Emphasis added.

A typical Gantt chart might look like this:

A Gantt Chart


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 ( [GPL (, GFDL ( or CC-BY-SA-3.0 (, 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.

Post Navigation