Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Posts Tagged ‘lean’
Conway’s Law
Wednesday, November 9th, 2011Magic potions Vs. Continuous improvement
Thursday, September 15th, 2011In order to understand something, sometimes it’s easier to understand it by defining what the opposite is.
Recently, I was trying to explain to someone the fundamental principle behind continuous improvement was. Do you ever run into the scenario where you find yourself in a conversation and you hear:
“We need to build an X, it will solve all our problems and make our code bug free.”
Conversations like this, immediately sound off alarm bells in my head, because what’s essentially being suggested is a magic potion, a concoction to cure all ills, an elixir of eternal life or just plain old powered tiger scrotum.
The overuse of hyperbole and setting truly unrealistic expectations in software development only results in continuous disappointment, and slowly kills a team spirit and stakeholder trust.
Aim for steady incremental continuos improvement with small achievable micro goals, know when to pat yourself and your team on the back when they have achieved them, and make sure going off solo on a magical quest to slay a dragon get’s stigmatised and not rewarded.
A short story about the value of automated testing.
Saturday, July 9th, 2011For the last few weeks, my team has been working on some pretty fundamental changes for Nokia maps on the web.
But that’s the short term. For the last six months my team has been working hard on getting a suite of automated tests up and running, and I’m proud to say we now have close to 1000 Jasmine unit tests and 200 cucumber acceptance scenarios running on every commit.
So I was delighted, when I heard that this week, one of the new changes had broken 52 of our acceptance tests.
Why should I be delighted?
Doesn’t that mean the team now has to go away and fix 52 acceptance tests? Well, yes, and that was certainly the way the team saw it, until I said:
“Now imagine we didn’t have those tests. What would have happened?”
And then we all started to realise, the power of automated testing.
So if we didn’t have automated testing, what would have actually happened?
Well, someone would have gone into the code. Found the piece of code that needed changing. And changed it. Probably tested it in the one place they knew about. Committed it. And moved on. Completely oblivious to the fact that they’d broken the application in 51 other different places.
Then the build would have gone to QA, the QA’s would have found the 52 different breakages, raised 52 new bugs, and sent them back to the developers.
Then the developers would have gone into the code, tried to fix those 52 bugs, and probably caused another 50 regressions. Which would then go to the QA team, be raised and go back to the developers for fixing. Eventually this hugely inefficient cycle would have continued until the build gets to an extremely brittle stability, a bit like building a house of cards, and it would have gone live.
However, with the tests, those bugs were caught. Immediately. And fixed. Immediately. Those 52 broken acceptance tests, saved us potentially months and months of rework.
So the moral of the story is, when you reduce the feedback cycle of a bug, with the saftey net of automated tests, it allows you to develop in confidence, giving you warning to what you’ve broken and giving you the opportunity to fix it then and there (however having the discipline to do this is another story). In Lean, this is referred to as ‘building integrity and quality into the product from the beginning of the cycle’, rather than trying to add it in at the end with a torturous QA cycle.
The truth about innovation
Friday, July 1st, 2011I thought I would share the slide deck for a short talk I held on the truth about innovation in agile environments.
Innovation
View more presentations from simonKenyonShepard.
The google toilet.
Sunday, November 14th, 2010When I was small I used to have a soft toy puppet version of Gordon the Gopher from TV’s Going Live!
As Gordon was a fairly large part of my then life, I went to all lengths to make sure he was fully integrated into the family. Part of this involved me building Gordon several miniature versions of common house hold white goods. The Gordon sized versions were mainly built from Toothpaste boxes, old sewing thread spools, straws and colored card. He had a washing machine to wash his various different coats, a vacuum cleaner (unfortunately Dyson had not invented his yet so this was just a plain old Hoover style one) and finally, in a fit of reality, racked with concern that he did not have anywhere to relieve himself, I built Gordon a toilet. The toilet was a fairly anatomically accurate recreation. It had a bowl, a cistern, a pipe connection to the cistern, and a small flushing handle.
What does this have to do with anything? Well recently I was lucky enough to come across this:
What.
What the Fuck is this?
I can hear your brain exploding now.
Yes, that’s right my friends. This image here. This, is the future of toilets. The cisternless toilet.
One must assume that the reason for a cistern, comes from tradition. To get an effective bowl clean, a reasonable water pressure is required. Maybe in the past common households did not have this water pressure available which lead to the design of the high-up cistern, which then was moved down to the low down cistern. But now, in modern days, actually all that’s required is a simple valve to the local water system, that is controllable by the operator.
So where the hell am I going with this?
This problem is a brilliant illustration of a common modern day coding problem. The problem, at the beginning of a project you have certain constraints (i.e. low water pressure), then someone designs a system (i.e. the high cistern) to deal with this problem. Then someone designs a better system (the lower cistern), and then someone else designs a better more efficient but more complicated system (the cistern with two buttons for different flush types). But in reality, all that is needed is time, to wait for the constraint to be resolved, and then careful thought on what is actually needed, in this case, the simplest most elegant solution is just essentially a on/off tap.
This is why I call it the Google toilet, because it’s simple, elegant, robust, easy to maintain and repair, and it does exactly what you need it to do, without complicating the matter by giving you different options and choices to make (do I need a big flush or a small flush? hmm let me evaluate…). It reminds me of a talk on usability given by Aza Raskin of Mozilla:
Better practices : Another great Dan North Talk
Tuesday, November 2nd, 2010Another great talk from the Simon Pegg of software. Don’t know how I missed this one and it’s slightly depressing that he was discussing this stuff back in 2007 and now it’s 2010. But anyway, I think his point about Lean production line development and software developement being different and more like car design development are very important and echo’d in the Poppendieck books. So sit down, get a cup of tea and take half an hour to watch this talk.
Scrum sucks… or some great videos on real agile and lean software production.
Monday, June 7th, 2010He he. I’m sure I’ll get someone’s attention with that…
Obviously, scrum doesn’t suck, it’s just a large number of people misunderstand it, and get taken advantage of by ruthless ‘trainers’ who promise to solve all your problems with their magical new process. Maybe a more apt title would be “process sucks” but I like to enrage and make massive over generalised statements so there we go.
To back me up though, I am going to post these great talks by Dan North that I found recently. I’ve always been a big fan of his blog, and his articles about BDD and story analysis are massivly insightful.
Why your Agile roll-out is Failing - Dan North from Øredev on Vimeo.
Dan North - Our Obsession with Efficiency from Øredev on Vimeo.