Clarke Ching's Rocks and Snowballs

Tag: your it.

The bottleneck in the project I’m currently working on has just moved.

It used to be someone else.  We worked hard to help them work harder and faster.  They did

Now we are the bottleneck.  Now everyone is looking at us, not them.  And the project is nearing it’s end.  The pressure is on.

We had a team meeting.  We explained how, although we had all worked hard so far, we had to figure out how to work harder and faster.  The eyes were on us. 

I explained how – in a metaphoric sense – my testicles were on the chopping block. 

• We brainstormed,
• We figured out a few inspired, but simple, interventions (that weren’t needed until we became the bottleneck),
• We made progress.
• We thanked everyone and started to pack up.

Then Graeme, one of the more humours members of our team, said, “That was a good meeting.  Don’t worry, Clarke.  I think your testicles are in a safe hands”. 

Hmmm …

Agile Scotland December 5 Meeting : Automated Acceptance Testing by Paul Wilson

The next AgileScotland meeting will be on "Automated Acceptance Testing" by long-term AgileScotlander Paul Wilson on December 5th.  It will start at 7:30 in the usual place: Currie and Brown's offices, on the Ground Floor, No. 1 Osborne Terrace, Edinburgh, EH12 5HG

Automated Acceptance Testing is one of the most exciting - and important - developments within the Agile community.   To my mind it is an important sign that Agile is maturing.  Unfortunately, I've found that while it's easy to understand intellectually, you can't appreciate it fully until you've seen it in action or done it.  Brian Swann ran a fantastic session in February 2004 and Tim Bacon's covered it in his course earlier this year, and I'm thrilled to have another session.

Paul knows his stuff.  I've just given a series of lectures to Eddie Gray's 4th year software engineering students at Glasgow Caledonian University and Paul helped me out earlier this week by running a very informative session on Unit testing.  I don't want to make Paul blush, but an anonomous colleague of Paul's recently told me that he "is an absolute master when it comes to Automated Acceptance Testing. He has a finger in every technological pie and is full of knowledge on the subject in every  technology! FIT, Exactor, JWebFit,  Fitness, Watir, Selenium - he's got them all down!".

Please join us on December 5th for what should be a very interesting session.

Clarke
www.clarkeching.com

Pursue your interests ...

My boss, a successful businessman,  says he works for the money … but his eyes light up when he talks about agile.

Made me think of this:

Mark Albion, Author of the book "Making a Life, Making a Living" cites a study by Srully Blotnick:

"A study of business school graduates tracked the careers of 1,500 people from 1960 to 1980. From the beginning, the graduates were grouped into two categories. Category A consisted of people who said they wanted to make money first so they could do what they really wanted to do later after they took care of their financial concerns. Those in category B pursued their interests first, sure that the money eventually would follow.

What percentage fell into each category? Of the 1,500 graduates in the survey, the money-now category A's comprised 83 percent or 1,245 people. Category B risk takers made up 17 percent, 255 graduates.

After 20 years, there were 101 millionaires in the group. Only one came from category A, 100 from category B.

[From George Ambler at Leading Forward blog]

 

spam

The last time I deleted my spam folder in GMail was 21:31 on the 9th of November.

As I type it is the 15:19 on the 20th of November.

I currently have 751 spam messages in my Gmail folder.

• That’s 70 each day.
• That’s 3 an hour.
• That’s one every 20 minutes.

How come these people can send pornography to me once every 20 minutes without going to jail?

What if I was 10 years old?

Theory of Constraints and software development.

Earlier this week David Anderson presented the results of applying Theory of Constraints DBR solution (the operations/manufacturing solution) to a software team at the Barcelona TOCICO conference:

With no new resources, no changes to how the team performed software engineering tasks like design, coding and testing, the changes to how the work was queued and estimated resulted in a 155% productivity gain in 9 months. The lead time was reduced to a maximum of 5 weeks – typically 14 days. Due date performance improved to greater than 90%. The backlog was worked off and the department is no longer seen as an organizational constraint. Customers are delighted.

The paper.  The presentation.

Must say that I'm personally thrilled to see this paper because I'm about to do the same with a client and having David's name and paper behind me adds great credibility. 

I owe you another beer David :)

Testing

1.  My boss asked me today if I knew a good test manager who might be looking for work in Scotland.

I thought for a bit then – rather uncharitably – responded that I didn’t know anyone who would want to be a test manager. 

Don’t get me wrong – I actually have a couple of friends who are good test managers – but what a horrible job: cleaning up everyone else's mistakes, then being the messenger who gets shot with the news that the project is going to (almost inevitably) run late.

The Testing phase is wrongly named.  It should be more correctly called the “Rework” phase because that’s what is actually happening – the project is fixing what it’s just built.  Quality in software development (and everywhere else too) should be about building quality in, not inspecting defects out.   If you have anything other than a very brief “proving” phase then you’re not building quality in.  That’s why I’m so damned obsessed / evangelical about incremental / iterative / agile software development - because it builds quality in. 

Of course, that didn’t answer my bosses question, but it felt good :)

2.  Coincidently, I got home tonight to find permission from Mary Poppendieck to quote the following passage from a recent email discussion.  It’s nicely written and apt.

> Quick has always been associated with dirty for a good reason. 

… Lean organizations routinely break the link between fast and sloppy.  In fact, organizations that are consistently fast have to be highly disciplined and have extremely low defect rates.  Examples include Toyota, Dell, FedEx, PatientKeeper (Medical software) and many others. 

In software development, the key is to have a “Stop the Line” culture; one that does not believe that defects should be added to a queue and refuses to build any inventory of code with lurking defects. The trick is to operate so as to find every defect the minute it occurs and stop and fix it immediately.  Impossible? Okay, then how about doing everything possible to approach the goal. 

Companies dealing with regulated software find that the best place to start is by writing the spec (SRS) as executable tests, and then running these tests against the (integrated) code AS IT IS BEING WRITTEN, so that defects are flagged (and fixed) immediately.  This process provides automatic traceability of code to spec and a daily log of the state of the code. Regulators love it. 

Back-end verification is done also, but when a verification process routinely finds defects, then testing is being done too late.

3.  If you know a good test manager or a good process/business analyst looking for an extraordinary job in Scotland then send me a note to cching at vision.com.

NHS IT project chaos

Today's Sunday Times leads with a story telling us that 'A COMPUTER project costing £6.2 billion that is central to Tony Blair’s National Health Service reforms is in “grave” danger of being “derailed”... '

Why?  The senior civil servant in charge puts the root cause down to too many last minute changes:

• In the e-mail exchanges in September, Granger blames a senior civil servant in the Department of Health for the fiasco, criticising her repeated last-minute changes and failure to heed his advice.
• Granger censures Margaret Edwards, the department’s director for access and patient choice, for adding numerous new specifications to the booking programme
• He concludes: “Unfortunately, your consistently late requests will not enable us to rescue the missed opportunities and targets.”
• Granger complains that the project has been allowed to change beyond   recognition from the original specification. "The original request from your predecessor and yourself was for an Electronic Booking System. The change of this to Choose and Book occurred in (the second quarter of) 2003. This was the first of what are now recurrent major changes in your requirements."

Well, there's a suprise: they couldn't get the specifications right up front and so they had lot's of last minute changes.  This is THE big problem with the waterfall method and it was the basis of my MBA dissertation.  And, it's the exact problem that the Agile methods solve: you can't prevent change, so embrace it.

Automated Testing ... in manufacturing ?

Have you ever thought much about manufacturing?  Did you know that someone actually writes programs for  the big machines in factories?  Did you know that those very same people use automated virtual testing to test that the factory produces the product they designed using their CAD/CAM designs?

• First, someone designs what the component being manufactured should look like.  They use CAD/CAM software.
• Second, someone writes the programs for the CNC (computer numerical controlled) machine that will produce the component.
• Third, they run the CNC machine’s instructions/programs  through simulation software and then compare the geometric shape produced by the simulation with the designs in the CAD/CAM system.
• Fourth, they may even run this process for an entire factory.  That’s right: they simulate an entire factory.

An email friend of mine, Randy, from one of my TOC lists mentioned this in passing, so I asked him for some links:

Here are some links to some leading simulation software vendors selling systems that read in a program and output the result as a graphical display of the geometry or path programmed, or deviations from comparison with the desired output (eg CAD model) with the actual programmed output, and may also include the influence of machine dynamics (ie momentum and inertia) on the results. The machine being simulated could be a computer numerical controlled (CNC) machine tool, or perhaps a robot, or in the case of Delmia's full suite, an entire factory of machines and robots working in synchronization.

http://www.delmia.com/gallery/pdf/DELMIA_VirtualNC.pdf

http://www.fanuc.co.jp/en/product/robot/roboguide/index.html

http://www.cgtech.com/verification.htm#CNC%20Control%20Emulation

The terminology will likely be very obtuse - here are a few (hopefully) clarifications:

• G-code   - low level programs run on machine controller computers
• APT CL - path description output of APT programming language, a high level geometric programming language with English-like commands
• Gouge checking - detection of physical collision of tool with machine, fixture or parts
• Postprocessor - a translator that produces G-code output for a specific machine, part of every CAM system

As a aside, here is a link to a simple description of APT (automatically programmed tools) - a very elegant and unusual programming language to solve any geometric problems. http://claymore.engineer.gvsu.edu/~jackh/eod/mechtron/mechtron-580.html

So much to learn from manufacturing … so little time …

IT Conversation - Brewster Kahle from the Internet Archive

Here’s a fascinating 90 minute talk by the guy who bought us the indespensible Internet Archive. 

[via Stuart Roebuck]

Agile Scotland

Hi everyone,

Clarke Ching typing from Scotland.

I run the Agile Scotland special interest group.  We meet in Edinburgh once each month and generally we get a good turnout  – between 10 and 30 people attend each evening.  We have had a number of well known and respected Agile speakers over the last few years – David Anderson, Mary and Tom Poppendieck, Tim Bacon, Rachel Davies, Martin Fowler, Charlie Poole, Ken Schwaber to name just a few – plus we’ve had a good number of excellent presentations from the locals input.  I happily admit that I’ve enjoyed and learnt from every single AgileScotland event that I’ve attended.

My objectives with the group are to (a) build a community of agile practitioners in Scotland (b) spread knowledge within the community and (c) spread the word about Agile within Scotland. 

But currently I have two problems with running AgileScotland:

1. Although it hasn’t happened yet, I’m concerned that one day I’ll run out of ideas for new sessions.  We are starting to recover topics that we’ve already covered – for instance, we’ve just had our 2nd DSDM session in 3 years and we’ve had a few TDD demonstrations – but thats not really bothering me.  But, I would like to maybe consider different topics, different formats, … but it’s a little nerve racking experimenting like this.
2. I’m failing on my third objective – to spread the agile word.  We get a few new faces each month but … not many.  I also get a bit of interest from newbies (strangely, most of them work for my former employer) but many of them don’t come to our evening events.

So … The purpose of this note is to ask for advice and suggestions.

I know that a number of AgileScotland members read my blog.  Any advice?  Email me at agile.Scotland@gmail.com.

I know that there are a lot of similar groups around the world.  Any advice?  Are you in the same position of me?

Many thanks,

Clarke