Sunday, February 26, 2012

Keep Calm and Test First

(yes, I confess I found the Keep-Calm-o-matic for this and the previous article graphic Face-smile )

Post CALM-Alpha ponderings

Well, the CALM-Alpha event has come and gone, and some people have already been voicing their views on the conference. From my point of view, it was a bit of a curate's egg - good in places, not so great in others, although we simply got back what we as delegates put in. So what did I take away from the unconference?

This is only the beginning

There was a reason for it being called CALM-Alpha. This was the first attempt at pinning down common ground between complexity theory (in this case, the work being done by Cognitive Edge with the Cynefin framework). The organisers had no real idea where it would lead, and this was a 'fail safe probe' to test out the possibilities. So no wonder it was at times a little confused. We are only just starting down this path. Hell, I don't think we even know if there is a path there yet! So yes, it was a somewhat painful experience at times. Too much jungle, not enough machetes. But worth it? Definitely.

The software industry is painfully immature

One thing was painfully, embarrassingly obvious during the conference. There was depressing evidence of just how immature our industry still is. At various points throughout the conference I saw behaviour highlighting damaging splits across the agile and lean software communities. Some attendees were keen for "their" methodology to be seen as suitable for "Complex" problems, and so obviously far better than a methodology that operates well in the merely Complicated. And as for techniques that were well suited to Simple problems, well, that would be barely worth exploring because they were, well, simple! The inevitable Scrum vs kanban wars started, as well as debates around pure Scrum vs adaptations. Even more disappointing were damaging, passive-aggressive "not invented here" attitudes I saw around the rehashed, reinvented and rebranded.

As people who boast about our ability to cooperate, we have become remarkably insular. Come on guys, I am tired of this willy waving and chest beating, and I know others are too. Let's grow up and collaborate with the other grown ups.

There is something in there

I suspect there is something in complexity theory that we in the software community are slowly discovering. Maybe it's in Cynefin, maybe other models. But one thing's for sure - our industry needs to understand why certain techniques work in certain circumstances, and not in others. We need to understand when to apply which tools and techniques, rather than thrashing about in the dark as we currently do. But depressingly it would appear that the software community want to do it the hard way and rediscover these ideas themselves. Sadly the cynic in me suspects that this is at least partially driven by self interest - people want to brand it, sell books and create a certification pyramid.... 

So what next? Hopefully the organisers of CALM-Alpha will organise CALM-Beta, learning from the lessons of the original event. I also hope that people will recognise what happened during the original conference, and reflect on how we present ourselves as software professionals. We need to seriously reconsider the way we behave, and how our industry works if we are to be taken seriously. 

Saturday, February 11, 2012

The power of caring and smarts

Prog Just recently I have been thinking a lot about what really makes a good agile team member. The reason is that over the years I have seen some teams become incredibly successful in terms of delivering products, and other teams crash and burn even though they have the same superficial traits and abilities. I have also seen teams go from zeroes to heroes (and back again), while others remain at whichever end of that spectrum they started at and never change. There is obviously some "secret sauce" (as Jeff Sutherland calls it) that needs to be mixed in. 

Well, I think I have identified one piece of this particular puzzle that I had underestimated previously.

Recently, one of my tweets resonated with quite a few people:
"Realised that agile has one fatal flaw. It still requires motivated, smart people who care for it to succeed, same as its predecessors."
(actually I was fibbing slightly - I have suspected this for quite a while now. I haven't only just realised this)

I think these two are key ingredients for success, and not just "nice to have". They are the "secret sauce", not just for agile teams, but for software development in general.

You need people who are smart. By smart, I don't think I mean conventional intelligence and IQ, but something different. The best way I can describe it is a combination of problem solving ability and intuition. 

You also need people who care. Some people have a deep seated drive to do good work. To excel. To better themselves. To maintain their humanity and help others achieve too. You need people with a strong inner motivation who want to make things work.

When you combine these two, magic begins to happen. I believe that people who care and have exceptional problem solving abilities (who care about solving problems, maybe?) tend to have the right attributes for agile (and other) software development teams:

  • Able to communicate
  • Willing to learn 
  • Humility
  • Courage
  • Passionate about quality
  • Curiosity
  • Integrity
  • Initiative
  • Creativity
  • Imagination

But that is not all. I believe they will naturally obtain the basic technical skills to do their job as a side effect of the curiosity, the courage and...actually all of the above! Now imagine what an entire team of these self-motivated, capable people can achieve.

However, I should emphasise that creating a functional, high performing team is not as simple as simply hiring in the people with the Right Stuff. You also need to put them into an environment that will nurture them and allow them to grow. If you put caring, smart people into an environment that actively discourages the right behaviours and attitudes, whether by accidental cognitive dissonance or deliberate edict, then there will be trouble ahead. But getting the right people on the bus (and its corollary, getting the wrong people off the bus) is a good start to sorting out your delivery problems - "Lead them, follow them or get out of their way".

So it looks like agile has the same achilles heel that its predecessors - waterfall, DSDM, RUP etc - have. It does not do away with the need for good people working in a good environment. You cannot force anyone to do a job well if they do not want to. No matter how much you believe that agile provides a framework for building high performing teams, it cannot force people to inspect, adapt and learn if they do not want to. But it does provide one huge benefit. It fails fast. You find out if the project is progressing - or not - very quickly. The feedback it provides allows the rapid identification that something is going wrong, whether it is environment, design, policy or people. This has enormous implications for our industry in terms of how we need to handle hiring, team building and behaviours in the future. More on that soon.

Tuesday, February 07, 2012

How many holes are you falling into?

There’s A Hole In My Sidewalk– by Portia Nelson 
Chapter One
I walk down the street.
There is a deep hole in the sidewalk.
I fall in.
I am lost… I am helpless.
It isn’t my fault.
It takes forever to find a way out. 
Chapter Two
I walk down the same street.
There is a deep hole in the sidewalk.
I pretend I don’t see it.
I fall in again.
I can’t believe I am in the same place.
But it isn’t my fault.
It still takes a long time to get out. 
Chapter Three
I walk down the same street.
There is a deep hole in the sidewalk.
I see it is there.
I still fall in… it’s a habit.
My eyes are open.
I know where I am.
It is my fault… I get out immediately. 
Chapter Four
I walk down the same street.
There is a deep hole in the sidewalk.
I walk around it. 
Chapter Five
I walk down another street.

So which chapter is your team at? Be honest now.