The path of knowledge

There was a curious thing my study partner said to me last year “I don't seem to be able to study like I used to when I was a teenager”.

I was on study leave myself at the time, and in a way was feeling the same thing.  I was working through a couple of textbooks – and found my process quite painfully slow.

Make no bones about it – self-study is hard.

But faced with a textbook we're all kind of guilty of trying to race to the finish.  Like knowledge is some kind of timed event.

We're also guilty of applying the worst kind of rose-coloured glasses when it comes to our school.  Few of us remember how bored we were in some classes, and how repetitive it was.

Fortunately I worked as a teacher, which gave me a different perspective.  And looking back, I think we learned a lot slower than we'd thing.

Teaching my class, we'd use a textbook as the basis of a lesson – introduce the topic, expand the ideas (sometimes building on another topic from last week), discuss them with students, maybe do a little bit of experimentation, then write them in a book.

All in all we'd perhaps cover the whole book over the period of a year, perhaps covering 2-4 pages an hour.  It's not the breakneck speed you'd think looking back.

And repetition was part of the key – I'd explain about a principle, we'd do an experiment about the principle, then we'd write the principle down.  So we'd go over the same piece of knowledge about 3 times in different ways so it would “stick”.

This is how we learn.  It's not about just reading new ideas, and going with them.  It's about looking at a new idea, examining your old ideas, and trying to build these new ideas on top/integrating with the old ones.

Something so complex mentally we can only take small bites at a time.  It's like watching a child develop.  When my son was born I thought he'd be crawling in weeks – didn't know what babies were like.

There's a chain of learning that goes on, where they develop new skills which expand what they can do.  They start out being about to do very little, just fragile.  But they develop the ability to move their limbs as they want to, they build up stomach muscles to allow them to sit up, they develop the ability to wriggle their legs, which eventually becomes crawling, which then becomes toddling, then they can walk, then they can run.

That's the sequence, and it takes over a year, and you can't “skip” a bit and just get to the walking – each ability is dependant on building the previous ability.  It's a kind of iterative piece of development.

The fascinating thing about babies as well is watching them develop and learn.  They learn as much from error what's not possible as from their successes.  But they're not afraid.  As adults we're terrified of failure to ridiculous levels, even though it offers us to learn from those mistakes and “do better”.

So what am I saying?  When it comes to education, it's a way of life, not a race, don't feel the need to put your "foot on the gas".  Try and learn just "a thing" a day, and build on it.  It's the way of successful learning.

Oh and don't be afraid to ask questions and try out the knowledge.  If you've got it wrong, it's best to kind of thing out your misconceptions early.

When “done” doesn't mean “ready”

Picking up a bit from yesterdays lament how in some companies the “unit test” is becoming a dying art on some software projects.

My original feeling – having worked on two projects now which called themselves “Agile” - was that Agile was a dangerous methodology indeed.  Many developers were building a kind of Kanban board with areas to show phases of development which included “Not started”, “Design”, “Coding”, “Done”.

And away they'd report to the project manager “oh yes this module is DONE”.  And so the project manager would come over to me as head of testing and it'd feel like we were put on the spot.

Because the developers version of “done” meant “finished writing coding” - it did not mean “unit tested”, “integrated into test environment” or even “ready for system testing”.


[It took Lisa Crispins book on Agile Testing to teach me that the aim of Agile development was to “bake in testing” and to test early and often]

I know from my own experience that code is just a lot of strange punctuation until you try and make it do something.  Saying code is “done” without executing it (ie testing) is like making a new recipe for a cake, baking it, but not really eating it to see if it's any good.

Mmmm – delicious cake!

I think one of the problems is Agile encourages people to adopt a “framework” and not a “rigid process”, and it means some people who say they're adopting Agile are really perhaps cutting things too far.

The way I see it – you have a process in place, and you have to look through it, and work out which elements add value, and need to be kept, and which are just unneeded overhead which add nothing.  And whatever we're using - Waterfall or Agile we need to be sure to try and strip down what we do, but be vigilant to keep the things that are adding value.

It would be a brave developer to tell me that testing does not add value to code, or that unit tests have never shown problems the developer did not foresee.


So developers beware – whether it's “Agile”, “waterfall” or “v-model”, your code is not “done” until it's “tested” ...


Erm not that I see developers as "the enemy", I just think some adopting Agile or whatever need to see the "bigger picture" of software development, and not just the coding segment.

Returning to the beginning …

I've had an interesting couple of days...  

I came across a book in my personal collection that's responsible for “starting it all” - my career in software engineering!

As I've been writing on this blog, I've found myself mentally referring to ideas I was sure originated from there.  And so I've decided it would be interesting 15 years on to return to the book, and compared “what I learned” from the book (ie pure theory) with “what I now know” (hard experience).

My education background is actually science/engineering/teaching – not “computers”, and it was during some PhD research I found myself more and more driven to use computers and write programs to analyse my data.

Originally I was using BASIC, but all the cool kids in the Department were using C++.  So I picked up a book by Michael J. Pont – Software Engineering with C++ and CASE Tools.  It's a mammoth book – 900 pages!

It's also kind of 3 books in one – it teaches you C++ language, it teaches you to use CASE Tools (not heard of them used since 2003) and then this thing called “software engineering”.  And it's the last area I've been revisiting.

For years this was the only book I'd read on testing, so opening it up, I was surprised to find no testing chapter.  In fact it covers testing in really only 4 pages.

That is – it only directly mentions testing in one spot – testing as a process.  However throughout as part of the discussion of software engineering there is a discussion about quality, about checking the quality of code at every level.  It's very similar to the Agile idea of “quality being baked in”, ie test early and ensure that any code meets at least basic functionality before passing it on.

I know as a developer I was very diligent about checking my code “worked” before passing it on.  I wouldn't do the obligatory developer “victory dance” until I was sure of this.

In recent years I'm somewhat alarmed on some projects how some development teams are in such a race to finish that this basic level of testing is just skipped.  It's almost going the way of “if it builds, it's good”.

Ironically in the “bad old days” test teams used to be made of developers with no coding to do.  Bad for testing, good for development.  As many developers would learn how their code would eventually be tested, and get their head around checks they needed to perform.

Maybe I need to start running a testing bootcamp with my developers.






[The book itself is probably a bit dated now - it's even got screenshots from Windows 3.1, C++ is now superceeded by C#, and CASE design tools replaced by Agile whiteboards.  It's still a very good book, Michael Pont having a superb writing style, and provides very detailed case studies to get your head around]

Pace

At school I used to hate running cross country/long distance.  Mainly this was because our sadistic gym teacher would leave cross country for the dead of winter, when the pitch was too frozen for Rugby.

I was dreadful – always at the back of the pack, keeping the asthma kid company.  My teacher used to tell me to beat the pain and the stitch by running faster.  Games teachers hey?

But that wasn't the whole story – don't write me completely off as the non-athletic science geek.  I was very good in Rugby, and also a fairly decent 100 metre runner.

But long distance – no way.

So I went through life convinced I couldn't run.  Until a few years ago an instructor at my local gym talked me into trying out a running program.  It was interesting – I told him “look I can't run”.  So he talked me through it …

The first week you run for just a minute, and then walk for a minute.  You do this for 20 minutes, three times a day.  “Hey”, I said, “I can run for just ONE minute”.  The week after you're running two minutes, walking for two.

Before you know it you're running 5 minutes, walking for 2, and doing this for 28 minutes.  Then two slots of 15 minutes, with a 1 minute walk between.  Then you're achieving a continuous run for 5km.

So this left me at 36 being a better runner than when I was 16.  On the face of it, it makes no sense – I don't feel fitter than when I was 16, I'm older, and certainly much heavier.

The difference was pace – pure and simple.

At school I never learned to moderate my pace – so I'd try and run cross country at 100m speeds.  Which is okay for 100m … maybe even 500.  But the pace isn't sustainable – and then it hurts.

The trick is to find a speed - and okay we're talking here about a slower speed - that's sustainable for your distance.

To be honest I tend to call any running I do “jogging” - it's faster than walking, even speed walking.  But it's no great speed – but heck I'm doing it.

At the Hutt City Triathlon (where the run segment is first), I was passed by a huge number of folk.  But then about half way around, I started to catch some of them up.  Their run pace was unsustainable, and they were now walking.  And as I say, I might not be lightening, but I'm faster than walking.

It was a good feeling – a kind of tortoise one-upmanship on a few hares.


Okay – so far so sporting anecdotes.  Why is this in a test blog?

In approaching testing for a big iteration, esp in a waterfall-esque project, we do tend to treat it as a race.  A race to test, a race to finish.

Unlike the hares on the triathlon we're probably more guilty of walk, walk, crawl, crawl … oh my God the deadline's nearly here – run, run, run!!!

The trick to avoid those last minute panic sprints is to try and work at a sustainable pace.  It's easy to say, but it's another thing to achieve it.

Especially in the early stages of a project, it's difficult to get hold of information or people – I'm getting at the moment for instance a lot of "look I'm too busy, I'll try and get back to you next week".  Which pretty much leaves the test group at an amber light – ready to move off, but not really able to.  And alas going around with thumbscrews only gets you so far ...


At the moment to keep up some kind of pace, we've identified we might need to use SOAP UI for testing the first iteration.  So we're trying to familiarise ourselves with that now, so we don't have to later.  Looking at what data we need, and preparing it – actions we might have left until a little later.

Keeping busy can feel a major occupation at times when the developers are running a month late, and you've nothing to test.  But it's an essential for a test team.  Lack of pace in a project is worse for the morale of a team than being overworked.

However giving team members tasks just to keep them busy and don't achieve things is also terrible for morale.  Some project managers I've known wouldn't give a hoot about team morale.

But in my book a team with good morale will feel more valued, be more engaged with their tasks, more creative with their solutions, but confident with interactions with other teams, and more diligent in their testing.

All that said – when it comes to running … I much prefer to be cycling.  Which let's face it is cheating!

Collaboration across the nation … *

Yesterday I was a profitable day.

I've been collaborating with a colleague in Auckland.  We're both trying to study a book on test management, and have formed a study group.  Though there were originally 6 of us, we're now just down to two.  But I have to say it's been a very positive experience.  And much better than reading the book on my own!

Basically every two weeks we take a chapter and we talk around the concepts.  More importantly we ask each other questions, and bring to the table our own experience of some of the issues.

I guess together we're brainstorming.  It's interesting because it takes us places I wouldn't have thought mentally to go.  As well as helping in my own mind to reinforce the bits that seem important.

What really surprises me is it also makes me have to think about my own experience, and I'm surprised the knowledge that comes out from me when my study partner asks questions.

It reminds me very much of something I read in Michael J. Pont's book on software engineering.  It's a slightly unknown book, but to me was THE book which taught me everything I know.  I'm still using bits of it.

In a section he talked about how collaborating with our peers when we hit problems can often bring out the answers from ourselves.  It's a bit like going to see a therapist, who doesn't tell you what's bothering you, but by being a good listener will ask the right questions, and before you know it, you're telling him what's wrong.

Just ten years ago, software was a very solitary activity.  You still had kind of “cave troll” programmers who would have their own cubicle cave, which you'd have to stop by with a mighty +1 defect (this is Dungeons and Dragons speak for the non-geek).

Today projects and environments are too big and complex to be kept in one persons head.  It's a more of a team activity, and as hinted at yesterday, the best teams are the ones who communicate to each other – yes even in Rugby with a gumshield.

Likewise, I've been talking to another colleague about the importance of social media to that ability to communicate to other testers, and hear other testers stories.  It helps sometimes to know how other people solve similar problems you face.


Heck sometimes it helps to just know it's not just you feeling like you're put through the wringer!




*  That title makes me smile – it was a song someone wrote in teaching college ...

Smells like team spirit ...

I was talking with another tester last week about team ethics.  Naturally as he's Indian based, he was talking cricket.

There is no doubt about the importance of teams – I'm going to approach it from the point of view of the “other scrum” (sorry Agilistas) – the Rugby kind.

My best Rugby days are behind me – but I still keep my hand in when I can and injuries persist.  Rugby is an amazing game because it has a lot of specialist roles – and indeed there's a role somewhere for anyone regardless of size and speed.  Big and slow?  We'll have you in the Scrum thankyou.  Fast as lightening?  We need you in the backs.

To get the most out of it, it helps to have trained with the guys you play with, and know they've got your back.  It helps to understand what everyone in the team does – the forwards and trying to get possession, and give the ball to the fleet footed backs to get the points.  It helps to have some experience in every position; prop, second row, number 8.

I always trained as a forward (the scrummers) until one game where I was a substitute, and we lost a back.  I got put into place as a winger – well outside my comfort zone – I had to ask “what am I supposed to do?”.  But it was a great game, I was out of position, and learning as I went – it kind of taught me a new respect for the backs, and an understanding of what they do.

We all know as a team, if we support each other, communicate when we have the ball, have each others backs, encourage and train together, it's going to be a positive experience, and we'll always do our best, even if we don't always win.  Believe me “communicating” when you have a gum shield is not very easy – but then sometimes all you need is “I'm here” and “c'mon with me”.

However if as in some teams, we don't know each other, we fail to communicate when passing the ball, and we constantly blame each other, we'll rarely win.


As with the team on the field, so for the team in the office …

I started a new testing assignment a couple of weeks ago.  It's good to get busy after a couple of months of idleness.

But there are things that concern me.  There is so much documentation to read – this is because the test team has in some ways been brought in last it feels … or at least my bit of the test team.

There is a 150 page test plan to plough through.  For anything that we want to think about tests – we have a business requirements document, a user case, an analysis document and a coding design document.

It's interesting in a way, as coming fresh into this environment I'm feeling that in a way having too much documentation can be as bad as having none-at-all.  And in this project's case is even worse.

Why?  One of the reasons is as testers we've been told business analysts and developers are “too busy” and not to be disturbed except by email questions.  This means we're unable to get any questions answered “in real time”, with usually a 2-day turn around time.

I have concerns when I start to hear the words “too busy”.  They're actually my most hated words on projects when I hear someone talk about being “too busy”.  There's almost an office expectation that when someone goes around saying they're “too busy” that they must be adding incredible value to the company.  I actually think the reverse is true.

If a key link in a project is “too busy” it means there are going to be a lot of people on a project who get sidelined or dead ended.  This isn't good.

It also reeks of self-importance.  I feel in a way that when we're told that developers and business analysts are “too busy”, we're actually being told that testing is really of less importance, weight and priority in the scheme of things on a project.

Of course there's a flip side to this – there are people who try and get work done, but they'd get so much more done if there were less interruptions.  I know I used to work occasional Saturdays and achieve in two hours just phenomenal amounts just due to the lack of distractions.  I've also known team leaders have lunch in their car in the car park as having it at their desk, they never get a break from people.

When you dismiss someone with “I'm too busy”, you're just putting a barrier to them.  Here I think are better ways of managing this,

• stand ups/daily meetings – call them what you will, but it gives a daily forum, and set time for people to be “approachable”
• “I'm in the middle of something right now – can we meet at 11?”.  You're getting them to acknowledge that you're busy right now, but there's a time you can catch up later.  You get to finish what you're doing, and they get their issue resolved.  There's compromise of both parts – you're going to have to give up time, they're going to have to just wait a little for a response.
• “I'm off to a meeting – but James is up to speed, and should be able to help you”.  Hopefully not one person has domain knowledge, it should be spread amongst your team.  Another member of staff should be able assist your co-worker.

The difference between these statements and the “too busy” dismissal is that (a) it communicates that you're in the middle of something but crucially (b) contains a compromise to resolve the issue your co-worker brings to you.


Would be nice to consign the words “too busy” to the medieval period of software development ...

The Sirius Cybernetics “user experience”

The Hitch-Hikers Guide To The Galaxy was a science fiction radio series in the 70s … then a book series … TV series … and finally a movie.

In it, an Earthman called Arthur Dent is rescued from a demolished Earth and travels the galaxy with his alien friend Ford Prefect.

As this is science fiction, the galaxy is populated with amazing shiny technology … however as this is from the tortured mind of Douglas Adams, a lot of this technology is somewhat twisted.

And the maker of all this technology?  The Sirius Cybernetics Corperation.  They were a satire on many of the UK enterprises of the 70s who would start off with a good idea, however by the time they'd produced any finished product, the good idea was unwieldy, customer unfriendly and overall just a pain in the neck.

So peppered throughout the series were such memorable technology as,

• drinks machines which would scan your taste buds and brain waves to try and determine what would be most palatable to you  But then “something would go wrong” and what would be delivered would be almost always disgusting.
• androids with “Genuine People Personalities” to make them easier to relate to.  But this made the androids too human, with Marvin the Paranoid Android suffering from severe depression.  Ironically Marvin who drives anyone who spends too much time with him up the wall is marketed as “Your plastic pal who's fun to be with”
• intelligent lifts – who are so busy haggling with their users – telling them the floor they ought to try, rather than take them to the floor they want. *
• a space passenger craft which has kept it's passengers in suspended animation for thousands of years because it doesn't want to inconvenience them on a 2 hour flight, as the craft is out of napkins.

The drinks machine really sums up the Sirius Cybernetics user experience.  It's designed to give you what you desire, but gives you something that you find filthy and disgusting.  When you then complaint to the machine about this, it's so sure of it's programming it ascertains that you must be in error, and not tasting the drink correctly.  The automated programming and clever systems take prescidence – and so you're not able to simply ask “I would like water” or “I would like tea”.  Because the Sirius Cybernetics Corperation who programmed the machine knew better.

In software we can be guilty of this a bit.  Systems where we're trying to be clever, and lock out the user can be incredibly frustrating to use.  Of course sometimes “locking out the user” a bit is needed for security if it's about providing access to a service.  But how many times have you heard someone go “I just want to do ??? and it won't let me!!!”

Microsoft can be a bit guilty of this at times.  I get the feeling the Apple experience is even worse – you're not allowed to “fiddle” or change things, because Steve Jobs doesn't want you to worry about it.

It makes you as a user feel like a bit like Oliver asking for more.

* The TV series Red Dwarf would go one further than intelligent lifts with it's Talkie Toaster - an AI toaster, which is obviously obsessed with toasting bread.  And thus tries to steer any conversation in that direction.  It seems funny, but in the 80s we were obsessed with putting computers in everything, never really wondering "does it actually need one" - Talkie Toaster was a wake up call ...

Agile and the thorny world of DIY ...

I found reading Agile Testing by Lisa Crispin to be an unusual read.  The concepts of Agile I would agree with to a point, then feel myself wrestling with my own testing experience.  Sometimes enough was enough, and I could not help screaming "you can't do that!!!".  Thankfully I read alone.

It's the areas that produced the most violent reaction that I've tried to revisit.  In psychology Jung says anything that provokes a violent reaction might be too close to comfort.  Or in otherwords "methinks you doth protest too much".

One of the things I find most unnerving about Agile was the idea of process not being central to projects.  "B-b-but process defines everyones responsibilities within the project!"  I spluttered  "And helps to manage and measure it's progress".

Then the book DARED to suggest that testers on an Agile project might not need to log their defects in a defect tracking system.  TOO FAR!  In a huff I put the book down for a week and stomped off.

Was I right?

I had been developing and testing since the 90s.  Back then both activities were very ad-hoc - things went wrong, projects were delivered and failing in the public eye, projects ran hugely overbudget.  Strict processes were brought into add safety gates to software development.  At first they'd feel restrictive, but over time they were just the way you "did" things.


But are strict processes the only way to achieve quality?

It took a bit of home maintenance for me to re-evaluate this.  Thankfully just a piece of decorating (I hate DIY).


Okay, I thought, if I was to decide to redo my living room, how would I go about this?

Everyone has an answer to that question - we all intuitively know how to plan DIY tasks.


But – what is revamping a living room?  It's a project.  And much like any project at work, to achieve its goals it needs planning, design, work doing, and some form of “end points”.

To my surprise, by instincts on running this DIY project were not process driven with restrictive safety points, they were much more Agile in nature.

And so here is my Agile DIY project …

Well first of all I'd come up with a plan with my wife.  She's got to live there after all.  I'd want to paint the walls, and maybe do the ceiling too.  My wife has started to collect all manner of figurines, so maybe some extra shelving would be useful too.

So I'd write a list out on a post-it note, and stick it to my fridge,
Living Room Project

Paint walls

Paint Ceiling

Install shelves 

Right - off I'd go to my local hardware shop, and buy several tester pots, which I'd paint on the walls in sample spots.  I've a leather couch and dark wood furniture, so the ultramarine blue doesn’t work well, but the burnt umber I could go with.  Wife doesn't like it though, preferring the autumn sunset.

I put a paint chart on your fridge, with the shade of autumn sunset you want circled.  However there's a problem at the hardware store – autumn sunset was a limited edition, and I can only buy 10 litres, and I need at least 20.  Consulting with my wife we do the testers pots again, this time going for terracotta.

I put the first couple of coats of paint up on the walls overnight.  But come the morning, my wife realises there are parts I’ve missed.  Unfortunately I don’t have time to do them now as I'm off to work.  So I put some post-it notes on the places that are a bit bald, and put another post-it on the fridge saying,

Don’t Forget

Repaint the bald spots on living room walls! 

Sure enough that night, I see the note on the fridge, load up the roller, and using the post-it guides, cover those areas I missed.

Job done, the post-its go in the bin – I don’t need them now, as I've addressed them.

On my fridge list of things to do I can cross out the entry for painting the walls,

Living Room Project

Paint walls

Paint Ceiling

Install shelves

And heck after all that I hope there's a beer in the fridge for me.


So what have I done?

In many respects, I’ve managed the painting of my living room in an Agile manner.  It’s almost second nature isn’t it? 

At no point did I feel the need to write up a document about what I wanted to do, formally agreeing ahead of time what colours and shades I wanted before even picked up a paintbrush to do tester pots?

Did I need to put this document through several reviews before finally getting my wife to sign off?  No doubt there's many a married man who's wished they had.

No – taking on this kind of project you have a broad plan of what you want, and change things (like trying tester pots before committing to painting the rest of the room), and highlighting faults as you go along.

If I had agreed a colour in a formal plan, then at the end of painting we might not have liked the finished product, deciding to repaint the whole thing a different colour, adding time, delays and cost. 

So at the end of the day, I'm feeling quite happy that my DIY project is a good example of intuitive Agile project management.

But is it?  How can I be sure?

Well … you know those fundamentals of the Agile Manefesto – lets take another look at each one …

Individuals and interactions over processes and tools


Okay – well I didn't really follow a formal process.  Did I?  Well maybe in a way – if you sand down a wall, undercoat it, wait for the paint to dry, paint your first coat, then wait for it to dry and reapply – I guess it's kind of a process.

But the important thing was we weren't slaves to the process.  Whilst doing the tester pots we weren't saying “well we really should be applying the first coat by now”.

Also there were no safety gates in this.  If I'd have become disillusioned, I could have walked away, and left it part done for another day.  Or worse still have said it was done when there were some missed patches.

This would have left me with a very disgruntled customer – and as this customer was my wife, this would not be a good thing.

The system really relied on me finishing what I'd start, and want to do a good job.  In the office world, this is called professionalism.


Working software over comprehensive documentation


Ahem – okay so no software here.  But at the end of the day, a nicely painted living room (the product) had more value for my wife than a cunning plan from me and a lot of razzle dazzle slideshows and documents.


Customer collaboration over contract negotiation

It was easier to have my wife adding comments, correcting mistakes, and choosing preferences as I went along than waiting to the end and me saying “well this is what you asked for”.


Responding to change over following a plan

We wanted autumn sunset as a paint colour – but they didn't have it.  So we went for something as close as possible after re-evaluating our options.

So was it Agile?  In my book yessireee!


In fact I shared it with an Agile guru at work - and they loved the idea.  But not to be outdone, they had a few more ideas to make it better!


Steps to achieve even more Agile DIY!

• Get my wife to check the paint colour early on after the first coat of paint - just in case!
• Teach my wife how to paint, investing in a second roller and extra brushes. The painting will get done quicker.
• Have a retrospective and decide that painting in the dark is a bad idea. Decide to paint in daylight next time, or buy a high-powered light to provide continuous illumination.

So ... Agile

Well it's been a nice break for Christmas, but I'm making myself sit down to do a bit of writing now!  Happy 2011.

And now .... Agile!

There are lots of material out there about Agile - ironically for something which is about concentrating on the core important ideas of software development, there's a lot of waffle.  For a discipline which is about concise communication over communication in bulk, there's also a lot of 600 page books being written.

I'm new to Agile, and learning as I go along.  I'm not really an absolutely die-hard follower, but I do recognise that some of the key ideas of Agile aren't just "Agile ideas", they're good practices FULL STOP.  Even if you're classic Waterfall, what it emphasises are "the important things".

The best place to start is the Agile manefesto - which is kind of like the tablet of stone from which all practices come from.  And like any keystone of religion, there's a small bit of infighting over it's interpretation and application!

Basically the core values are,

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Nice words - so what does it mean?  Well this is my take - and there are others.

Individuals and interactions over processes and tools

We've all worked in places where the processes in place can feel like shackles.  Sometimes process has value - it can act like a safety gate - we have to formally be sure we're ready to test before testing.

But most often it feels like we're slaves on a galley ship chained to an oar.

Part of this to me is about saying, we're software professionals, and that's important.  We're not children, we're professionals.  If we act professionally we don't need safety gates to slow things down.

There's an example of this on a previous project.  In order to formally run a test it had to be issued on our version control system.  Problem was, only one person Andrea could do this.  And she left at lunch on Fridays.  This meant if we had a formal test ready to run on Friday afternoon, we couldn't run it until at least Monday - often afternoon (cos she'd have a backlog).

What's the point in having testers work full pelt if the process will actually derail them when Andrea is out on Friday, sick, on leave?

Working software over comprehensive documentation

You buy a new phone.  You get it home, unwrap it, put the SIM card in, the battery, and get playing.

Least that's how I tend to do things.  About a year later I find the instructions - and realise a few things I could do with it, but mainly the phone works, and I only really use instructions when it doesn't work.

Our documentation is like those instructions.  It only tends to be of worth when the software doesn't work.  At the end of the day, you're delivering to the customer software - they're not likely to worry too much about all the documentation you wrote.

I agree with this to a point.  And that's this - there can be a tendancy with some developers to not to comment their code but shrug and go "hey but it works".  The feeling is commenting slows it down.  However good commenting is essential to the maintainability of the code.

Some developers feel threatened by this though - I have worked as a developer, and my tendency to comment my code made me more easily replaceable than a developer who didn't and "only I understand this module".  It's kind of empire building - using knowledge as a bargaining chip.  It's not the Agile way though - where it's about US not ME.

My other concern about this is about knowledge.  If a project is documented, its possible to learn about the project, how it works, etc from that documentation.

Without it, you need a culture which will be prepared to teach and mentor new developers and testers to understand it.  Alas on projects I've been on, there has been too much of a "throw you to the wolves" approach where everyone is expected to learn the whole system themselves.

To not mentor, is to devalue the individuals in your team - and it's again, "not the Agile way".

Customer collaboration over contract negotiation

Actually I probably have less to say about this.  But it's about getting the customer onboard at all stages, showing them what you're doing, what you're going to do, rather than do a big end reveal, and when they frown go "but it's what you asked for".

There are lots of different versions of this cartoon - but it really elegantly shows the trap of many projects which use a contract.

If the customer had collaborated at all stages, they would have got what they asked, and the vendor would have not been stuck with the bad rep of giving their customer something they won't use ...

Responding to change over following a plan

Hannibal Smith in the A-Team used to say "I love it when a plan comes together".

Alas though, plans can fall apart.

Plans can be useful for mapping out the way ahead.  But when there's a iceberg ahead, you need to stop, change course, respond to it.  If you keep ploughing ahead, you're going to get struck and sink.

Things go wrong, things fall apart, people leave.  You can build in so much contingency into a plan.  But it's so much easier to manage the issues as they arise than try and have the foresight to predict every issue.

-------

Found yourself nodding along to some of that?

It's a kind of sign of solidarity "you are not alone".  We're all veterans of processes which devalue our professional input, spending long hours on documentation that's never used, unhappy customers and rigid plans we can't achieve without excessive overtime.

Want to know more?

I recommend this book - Agile Tester by Lisa Crispin and Janet Gregory,

http://www.agiletester.ca/

First 200 pages are invaluable - the next 400 less so (if you're testing you probably already know this sections).