The Tricky Bit
The Tricky Bit
Posted by Uncle Bob on Friday, April 23, 2010
I once heard a story about the early days of the Concorde. A british MP was on board for a demonstration flight. As the jet went supersonic he disappointedly commented to one of the designers that it didn’t feel any different at all. The designer beamed and said: “Yes, that was the tricky bit.”
I wonder if the MP would have been happier if the plane had begun to vibrate and shake and make terrifying noises.
While at #openvolcano10, Gojko Adzic and Steve Freeman told the story of a company in which one team, among many, had gone agile. Over time that team managed to get into a nice rhythm, passing it’s continuous builds, adding lots of business value, working normal hours, and keeping their customers happy. Meanwhile other teams at this company were facing delays, defects, frustrated customers, and lots of overtime.
The managers at this company looked at the agile team, working like a well-oiled machine, and looked at all the other teams toiling in vain at the bilge pump, and came to the conclusion that the project that the agile team was working on was too simple to keep them busy. That the other teams’ projects were far more difficult. It didn’t even occur to them that the agile team had figured out the tricky bit.
Comments
Attila 15 minutes later:
I was just saying something along the same lines in a conversation earlier this week; namely, that real significant changes are often the ones that go unnoticed, because they Make Things Work As They Are Supposed To.
01001000011000010110111001101011 17 minutes later:
How does the story end? Did they break up the team? Did they try to make them work overtime with more stuff?
Its amazing what ignorance can do but if this is a real example I am curious as to the ending?
I want you to tell me that they saw reason but I am afraid that you actually might not…
Rosco 21 minutes later:
Whats the bet they paid them less as a result? ;)
Mohinder 42 minutes later:
I think the moral of the story is that Agile makes simpler things simple and harder simpler. Still I would like to know the ending now that I am in suspense mode.
Tristan about 1 hour later:
Happens in all jobs where a good system gets put in place by one team and the others struggle…
(eg a busier office gets their work done, so they are assumed to not have enough work whereas the office with less work and more staff doesn’t get it done due to bad processes so has more resources thrown at it).
Dave Aronson about 1 hour later:
Reminds me of a story I once heard. There was a programmer, and when the PHB gave her work to do, he was sure it was some horrendously complex thing that would take her forever. But she figured out ways to do it simply. The PHB figured, oh, well, I guess it wasn’t that complex after all—and made light of her work, saying he only gave her simple stuff….
Simon Harris about 3 hours later:
Agile or otherwise, it continually frustrates me that in many companies the greatest programmers do get the least credit, for this very reason. To most managers, their simple, efficient solutions make it look like they are hardly working at all – that’s the tricky bit right there, making it look easy.
It’s the guys who slave over a keyboard twelve hours a day and churn out reams of brute-force slop who look like the best employees, and are credited as such.
Tim Ottinger about 3 hours later:
You don’t know how many times I’ve seen managers fired for having well-run machines, and how often they were replaced by crisis-generating buffoons. Looking busy is more important to stupid managers than competence. I had a job not too long ago where employees were valued based on how many hours they work, how quickly and seldom they took bathroom breaks, and how quickly they walked as they entered the building in the morning. Sheer buffoonery, and a good reason I found better employment elsewhere.
Paul about 3 hours later:
It also goes back to a problem I’m facing in my (non agile) big company: should I work well (almost agile at team level) and nobody hear about me and still be a lambda employee or should I create my own little crisis, make a lot of noise, and finaly deliver a half cook solution so I can be seen as a small hero by my bosses ?
Joe about 4 hours later:
One successful agile implementation I worked on was closed down in favor of the less effective teams because “obviously there wasn’t enough work for us.”
Another fired the manager for being successful. It is discouraging, to say the least.
Esko Luontola about 5 hours later:
@Dave Aronson: I remember that as well. I think it was at The Daily WTF. I tried searching for it, but did not find it. Would somebody have the link?
Jason Y about 5 hours later:
I think sharing stories like this-pointing out how backwards rewarding busyness is-will help managers, developers, and other IT staff to “get a clue” who otherwise would not. So thanks for sharing.
Mick Maguire about 6 hours later:
Bob, I’m totally in the scenario now – leading 3 Agile dev teams in a non-Agile IT environment.
I even had to sit an listen to our CIO wax lyrical the other day about how “the future belongs to the immigrants” because “they will work 20 hours a day and bring sleeping bags to work”. The implication being that my teams were lazy because they work at a sustainable pace. no matter that the groups that the individuals that he was using as his example (for his horrible racial stereotypes) we actually known for poor communication, late releases and bad quality!
RichardHowells 1 day later:
This is not new.
In 1981 I saw a newly hired programmer tackle a job where two succesive teams had crashed and burned. He was given it on the basis that being new he would not be aware that it was a poisoned chalice.
Through a new (to the company) program design method he had the hard part up and working within a couple of weeks.
Management reaction. “Ah. It couldn’t have been as hard as we thought.”
After a couple of years of seeing consistent superior delivery managementdid eventually come to believe he really had a better method.
Pete 3 days later:
@Dave Aronson: I think the story you may be thinking of is quoted here, and is from ‘Software Requirements & Specifications’ by Michael Jackson
Spark Plug 3 days later:
Bob, I’m totally in the scenario now – leading 3 Agile dev teams in a non-Agile IT environment.
Andrew Jackman 4 days later:
This is the team I am on. We are still going, still delivering value to our customers. It’s a nice team to work on.
The team founders established the team as an XP group, and we have worked hard to maintain the XP practices against the corporate imposition on other teams of a high ceremony and heavy CMMI implementation. We have never been asked how we manage to deliver working software frequently… although we work hard to promote our practices within the IT group.
We don’t get the overnight support calls that pay out for each new incident, so we earn less than other teams, but we sleep well. :)
John Tropea about 1 month later:
This is a repost of a comment I left on the Anecdote bloghttp://www.anecdote.com.au/archives/2010/02/its_how_you_rec.html
This reminds me of the concept of the “silent hero” in the book the Black Swan. p xxiii http://www.amazon.com/Black-Swan-Impact-Highly-Improbable/dp/1400063515#reader_1400063515
The thought experiment is that what if cockpit locks were passed as legislation…which could of prevented some consequences of 9-11.
This person who imposed locks on cockpit doors doesn’t get a statue in the city or recognition, but those who rescued victims during the aftermath did.