The power of caring and smarts

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.

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.

Infamy! Infamy!

...they've all got it in for me!

Excruciating Carry On pun aside, here's the long overdue link to the talk I gave to the Limited WIP Society way back in March 2010 (my fault for not posting it here - it's been up on the SkillsMatter website for ages).

(Sorry, this is just a link. I can't work out how to embed this directly into the blog page - any ideas, anyone?)

Software development is not an assembly line

Analogies are useful to a point. They allow people to relate new ideas back to something they are familiar with, giving them a safe framework from which to explore new territory. However they can also be immensely damaging and misleading. I was recently reminded of one  particularly well worn example of the latter type that needs to be laid to rest once and for all:

Building software is not the same as building a car. Developing a software product is definitely not a simple assembly line process.

When building a car on an assembly line, you make the individual components - wheels, engine, chassis, seats etc - and then construct the finished item from these. Each component has already been designed in its own right, and they have all been proven to fit together many times previously. There is absolutely no creativity involved in the construction process. There are limited opportunities for different combinations of components (and those that are possible are well tested).

Software development is a fundamentally different problem. You don't have a set of predefined components. But you do have close to an infinite number of ways to build the final product. Individual components making up the final product need to be built, and so have not been proven to work together. The whole construction process requires a huge degree of creativity to produce a final, working deliverable. The nearest you can get to a car manufacturing analogy is to think of building software as attempting to build a car from raw lumps of metal, with no existing, pre-proven designs for the components. Trying to emulate an assembly line by believing that you can build component after component and expect them to immediately bolt together without problems will inevitably lead to tears before bedtime. Yet many teams still fall into this trap.

If it can be related at all to this analogy, software development has more similarities to car research and development than manufacture.

Consider this. A new car design is first prototyped as a collection of conceptual drawings that are iterated towards a final design. Then these are fleshed out to various models and mock-ups which would never make it to the forecourt, but which are used to invite more feedback. Then working prototypes are produced, and again, more feedback obtained, and designs iterated (or the design is shelved or binned). Finally, after many, many iterations, there is a new model of car available to purchase. Sounds familiar? Iterative software development creates a simple demonstrator of the system, then keeps on adding to it, refining both the functionality and the design until it is good enough to release to users.

This is where software development fits. It has more in common with pre-manufacture prototyping than assembly lines. But this doesn't stop us from stealing relevant, useful ideas from the assembly line. Kanban, anyone? 

Misquote

Anyone who reads my articles will already be familiar with the quote I use at the top of each page - "It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change.". For me, this cuts to the very heart of agile and lean techniques. Being successful is not about being powerful, or even knowledgeable in the traditional sense, but about being adaptable and smart.

Way back in June an anonymous poster pointed out that the quote was misattributed to Charles Darwin. To my shame, I sat on the comment until I had the time and patience to research the correct answer.

I can now confirm that you were absolutely correct, Mr Anonymous. It was misattributed. The quote most likely comes from the writings of Leon C. Megginson, Professor of Management and Marketing at Louisiana State University at Baton Rouge. The quote is a paraphrasing of Darwin.

I won't bore everyone with details, but here are links to the corroborating articles.

One thing Darwin didn't say: the source for a misquotation
Survival of the Pithiest

Quiet here, isn't it?

I've been fairly quiet recently for various reasons, but rumours of my online demise have been grossly exaggerated. The brief hiatus has given me time to think about several new articles that are now in the pipeline, so watch this space.

Blogger Profile Change

All change!

I am in the process of migrating this blog to another account. For anyone following via my Blogger profile, I am now over here.