Thinking and Working Agile in an Unbending World

Yeah - that was the title of the session I presented at Agile Testing Days in Potsdam.  

My presentation at Agile Testing Days went through a several changes.  The last major one was the time slot.  When I saw the slot I was assigned, the last track session on the last day, I was concerned about the path I had taken.  I realized that a heavy presentation when most folks would be already tired would probably not be ready for one more intense session.

Then Unicorns took over the conference.

No, really.  They were everywhere.  So, I made one more set of revisions - and added Unicorns to mine.  (Why not?)  This also gave me another idea I had been trying to get out - and unicorns helped me.  So, I ran with it.  Hey!  Its part of being flexible, no?

Sigurdur Birgisson was kind enough to use MindMeister to record my presentation as a live blog.  Its kinda cool.  Thanks Sigge!  Find it here.

Right -

The cool cats all do Agile.  Agile rocks.  But if the company does not "do Agile" then, what happens to the talented people working there?  Are they doomed to being Not Cool?  Can they move from the "Real" World to Unicorn Land of Agile?

There are flavours of the idea of what is Agile that, I believe, leads to its own problems.  We all know about the terms laid out in the Agile Manifesto.  We know how it is phrased.  We know the ideas around...

Individuals & Interactions over Processes & Tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiation

Responding to Change over Following a Plan

Fine.  So what does the word agile mean?  Well, being an American, I looked up the definition in Webster's Dictionary.  Here's what I found:

1. Marked by ready ability to move with quick easy grace
2. Having a quick resourceful and adaptable character

The question I have is that if this Agile... Stuff works, what makes it work?  Does it work better than, say, the non-Agile stuff?  Like, Waterfall?

Consider these questions - 

• Why is it that some teams are successful and some are not, no matter the approach they use?
• Why is it that some teams are successful using strong command and control models?
• Why is it that some teams are successful using agile methodologies?
• Are Agile Methodologies always, well, flexible?  Do they always make things better? 

From what I can see, this depends a great deal is meant by "Agile."  Now, the Agile Methodologies tend to have their own baggage and... stuff.  How can this be?  If we're Agile we're supposed to be "agile," right?

Alas, I fear I'm getting ahead of myself.

Consider this - the Lightweight Models and Methodologies (that became "Agile") were a response to the heavier, more formal models in place.  These were considered slow and unable to respond to change.  They bogged down the development of software and generally, based on some versions of the story, kept people from doing good work.

The thing is, no process model in place was ever put there, from what I have been able to discover, was put in place to do those things.  No model was ever put in place to crush the creativity out of the talented people doing the work.

Why Are Things the Way They Are?

Rather than rail against the horrible, crushing, models - which is what I did when I was younger, less experienced and generally less aware than I am now.  Well, maybe less understanding than I am now.

Try these questions instead:

• Why are these process models in place? 
• What happened that made this seem like a good solution? 
• Have things changed since then? 
• Have the problems resurfaced since then?

Those "horrible, crushing models" were an attempt to address something.  Those questions may help you find out what that something was.  Learning that may help you approach the great question of "Are these process models still needed?"

This is a slightly difference question, and I find often times less painful question, than "Are these process models still relevant?"

Both are important.  The answer to the first can inform your phrasing for the second.

Oftentimes people will fall into the trap of ritual when it comes to software.  "We had this problem and we did this ever since and that problem never came back."  Very good!  Now, did the problem never coming back have anything at all to do with the change you made in the model?  Have you encountered other problems?  Has the model gotten more convoluted as you make changes to handle problems?

At what point does your house of cards topple?

Do the steps added or changed to the process model still add value?  Are they worth the expense of executing them or have they become boxes to check-off?

Considering the questions presented, and the answers received from them, can help you take a step toward agile that I find terribly important.  The odd thing is, when I present it as my "definition" of what makes Agile, well, agile, I get nods of agreement, scowls (and sometimes proclamations) of "you're wrong!" and everything in between.

Here is how I look at Agile in an agile way.  Ready?

Doing what needs to be done to deliver the best possible quality and
high-value software product in a timely and cost effective manner.

Is something needed, really?  Or are you checking a box that someone says must be checked?  Does the information exist elsewhere?  If so, why are you repeating it? 

Now, all the Agile folks are saying "Yeah, we know this.  Waterfall is bad."

Consider how many times have you heard (maybe said?) "If you are doing <blah> you are not Agile."  Now, how many times have folks said "If you are not doing <blah2> you are not Agile."

Rubbish.

If what someone is doing really adds value and makes sense for the context of the organization, and they are delivering good software, how is that wrong?  How is that less-than desirable?

Consider these questions about your own software: 

• Do your customers have a choice about using your product?  
• If they purchased it, are they installing the upgrades/patches when you ship them?
• Are they letting them linger?

When I asked the set of questions about customers with a choice and installing the upgrades at Agile Testing Days, a number of the very confident faces changed from "We're Agile, We're Good." to somewhere between "Deer in the headlights" and "Oh, oh.  How did he know?"

If the software we are making does not do what people, like our customers, need it to do, does it really matter what hoops we jump through to make it?

Consider this paraphrase of Jerry Weinberg's definition of Quality (with the Bach/Bolton Addendum) and think about all the stuff we talk about with Agile and ... yeah.

Quality is value to someone (who matters.)

If your software product does not fit that definition, does it matter how you make it?

Do stuff that makes sense to do and don't do stuff that doesn't make sense to do.