Monday, 13 December 2010

Edward Deming and his Red Bead Experiment, in practice.

We had an interesting brown bag lunch meeting the other day about Edward Demings red bead experiment. I've heard and read about it before but never got to participate, it was interesting, thought provoking and fun. Some good discussions afterwards as well.

Edward Deming was a management consultant and statistician. He had a massive impact on the management styles and philosophy of Japanese business in the 50's and 60's. He used the red bead experiment to illustrate the impact that a system, and traditional management approaches, can have on individuals who work within a system, and how traditional management approaches (slogans, the usefulness of targets, annual appraisals and financial rewards) are not always (if ever) that effective at improving quality.

Details on the red bead experiment and how it is performed can be found here For our results in the actual experiment read on.

The session was run by a thoughtworks colleague, in a really good way, we had the workers, the management, the QA staff, and lots of fun.

The workers were set targets of 5 defects max per person ( a total of 15 per iteration for the team)
The 3 workers, were split into 2 average and 1 good (what ever that means)

Iteration1234Developer Totals
Iteration Totals2323202591

After iteration 1 workers were told that their efforts were not good enough, and basically told off by management. This made no difference, and so, after iteration 2 the workers were given incentives and appraisals, if they upped their game they would be given hard cash. This worked and management were encouraged to do more of that, offering bigger rewards for better performance.
But iteration 4 was the worst yet and so managers assumed that the incentives had failed because no one actually achieved them last time.

So what does this actually tell us?
That in a fixed system where the workers have no ability to manage or better themselves or their work, the management effectively can not effect workers performance though traditional carrot and stick management.

How does this relate to Software?
I have found that as software developers we don't get to change the system as a whole very often. Often software is seen as the solution to business problems, when actually changing the system would be a better approach. Just by making the process electronic doesn't always work and often makes things worse or masks the underlying problem. This is just another reason why software projects fail.

The experiment also relates to the software development process. If software engineers work in a rigid system where QA and strict process is seen as putting the quality in. Where the engineers don't have the ability to change their environment (technology, process, physical environment, methodology) then no amount of incentives, slogans, rewards can make the software produced better (less defects, meeting business requirements more effectively, etc.). I have seen this at several clients, and can say that clients who have empowered workers have a big advantage, these companies have better motivated, more professional developers and in the end better software.

Systems Thinking is a really interesting field at the moment and if you want to read more do a google for Edward Deming, systems thinking and John Sedden.

So even if you are CMM level 5 (i.e your processes are robust and repeatable) you can still have quality issues, The red bead experiment highlights that it is not process that produces quality, nor rewards, targets or incentives, its the system within which workers work that matters and their ability and motivation to help change and adapt the system.

Tuesday, 7 December 2010

Selenium 2, webdriver for .net c#

Webdriver tests that are fast to write and fast to run are essential for BDD. I was really supprised at how fast your tests can actually run, even the setup is quick IE opens instantly, providing a very quick test code loop.

1. Download selenium 2 from i got for this exmple
2. Add project references to nunit.framework, webdriver.common and webdriver.IE or webdriver.firefox
3. Using NUnit (No tutorial for that here, google it) create a test class that uses webdriver

using System;
using NUnit.Framework;
using OpenQA.Selenium.IE;

namespace AcceptanceTests
    public class Class1
        private InternetExplorerDriver _driver;

        public void FixtureSetUp()
            _driver = new InternetExplorerDriver();
            _driver.Manage().Timeouts().ImplicitlyWait(new TimeSpan(0, 0, 30));

        public void FixtureTearDown()
            if (_driver != null) _driver.Close();

        public void GoogleShouldBeInTheTitleWhenNavigatingToGoogleHomePage()


            Assert.AreEqual("Google", _driver.Title);

4. Run your tests
5. Done