The end of passion

I'm supposed to be doing my US tax return right now, but I got distracted (what a surprise) and read this post from March 2009 by James Shore. At the end of the post James says two things that resonated strongly with me:

"If the point is to Be Agile, there's no need for Agile to actually work."

and

"Starting now, I'm reorienting my business to focus on people who want to be great."

Last night I said goodbye to me colleagues at Cogent Consulting, and one of the things that I meant to say but forgot was that for me interesting agile consulting work in Melbourne is now rare. I would have struggled to say why until I read James' post - I think it's that once-upon-a-time my consulting work was mostly with people who really wanted to be great, regardless of their current performance. It might not have been everyone in an organisation, but in each organisation it was enough people that greatness was the dominant theme. At some point those gigs dwindled - on the new gigs some people may have wanted to be great, but the team/division/company as a whole wasn't really interested. They pay lip-service to greatness, but it's the "we want to be great so long as we don't need to change too much of what we do" variety. My drive is to help people be great, and as that work has withered so has my passion. I may be willing to do work I'm passionate about for peanuts, but I think there's a thread in my mind which says if you can't give me work I'm passionate about then show me the money (and I think that makes me, well, human).

Now my soon-to-be-colleagues in Goldman Sachs may read this and shake their heads, so I need to be clear. I've always felt that enough of the people at GS wanted to be great to make working there worthwhile. It would be naive to think that it's everyone, everyday, but in my experience it's definitely enough. So I hope to have the pleasure of having my passion rekindle there as well.

I think this reinforces Cogent's recent decision on medium-term focus as well. The future of Cogent Consulting isn't to help other people with their agile transitions. The future is to blend Cogent's passion for software development with the needs of people who are passionate about their own domain, outside of software development. The result will be delivering excellent solutions that change people's lives - sometimes because no one else could do it economically, sometimes because no one else could build the partnerships that Cogent could build, and sometimes because no one else could do it at all.

Helping people transition to agile development - 10 years

Forming my own consulting company - 2.5 years

Finding outlets for my passion - a lifetime

Who Am I?

** Updated 26/3/2010 **

If you read this blog regularly then you will know that I'm about to embark on a career change. Part of this will be moving from a relatively safe environment where I have a reputation (Melbourne) to a challenging environment where I'm a relative unknown (London). When I meet new people in London (professionally) I'd like to have something I can point people to that gives them some background and helps to set their expectations. I'm personally expecting to be meeting quite a few new people, and I hope that this can accelerate the familiarisation step a bit.

First, I'm incredibly introverted. I've learned to be vocal in some situations, but sometimes that confuses things because people don't notice just how introverted I really am. How does that manifest?

• I'm pretty quiet in meetings
  
  
  Particularly if I don't know all the participants I tend to listen more than I speak. That doesn't mean that I'm not thinking about the matter, or that I'm not interested, it just means that I'm not talking :-)



• I think slowly
  
  
  Sometimes experience gives me intuitive leaps, but I'm often the person who comes back the next day and says "that thing we talked about yesterday isn't going to work, and here's why". Even when my intuition gives me the right answer quickly it can still take me a while to come up with an explanation. When this happens it's not that I'm being uncooperative and trying to work outside the meeting/collaboration, it just means it look me a while to get to where I was going



• I understand pairing gives better development results, but it doesn't come naturally to me



• I'm unlikely to join you at the pub for a beer
  
  
  It doesn't mean I don't like you, but it's not an environment that suits me.



• I'm not into public celebrations
  
  
  This can get me into trouble, especially when I'm meant to be "leading". It's not that I'm opposed to celebration, it's that it's not something that I volunteer for. If you happen to suggest my team needs one I'm likely to agree and ask you to arrange it!



• I don't deal well with conflict, particularly if it happens quickly


I'm pretty analytical, but emotions can be a bit tricky for me. I need to gear myself up for situations where there might be conflict, and if one springs upon me unexpectedly I'll usually disengage. It's nothing clinical (empathising comes fairly easily to me), but it is something I've learned about myself.

I've managed to add a few layers to this introverted foundation. I'm a reasonable public speaker, I generally enjoy it, and I'm happy to talk about software development to any group that's interested.

I've been referred to as a "code quality freak". My attitude is that you should work on the micro-level details of programming until they've become muscle memory, so that you can free your brain up to work on the complicated stuff. This covers all the stuff you'd find in coding style guides and books like Bob Martin's Clean Code (though I have to fess up that I haven't read that yet). Even at the micro-level I like to use tools to tell me where I've let me standards slip, so I'm keen on tools like Simian, Checkstyle, Complexian and their equivalents in other languages. These days I'm also interested in visualisation of the output of these tools, though I don't have as much experience in that area.

Another metaphor I use around code quality is that it's like hygiene in a hospital - we shouldn't need to talk about it, we should just do it. If we can't maintain hygiene then everything else is going to get a lot, lot harder. Some people suggest that you can clean up your technical debt by having dedicated iterations - to me this is like suggested we let crap pile up around a hospital and clean up every couple of weeks. It doesn't work for me.

I love automation. I have a very small brain and I'd rather use it for processing than storage. Manual processes are slow, tedious and error prone - I want to get rid of them.

I don't think that software development is predominantly a technical problem, I think that in most cases it's a social problem - how to we organise the people and technology we have to delivery an effective solution as cheaply as possible. Commercial constraints demand creativity and make software development challenging.

I like agile practices and processes, but they are means to ends. I think that as humans we are all imperfect - we should accept that we make mistakes, but try to reduce the consequences of our mistakes and try not to make the same ones over and over again. We can continually improve, but to do that we need to continually reflect and continually learn. I'm very keen on the ideas emerging around expertise and deliberate practice.

I'm sure I'll think of more and extend this post, but there's a start :-)

Seven Norms of Highly Powerful Software Teams

I found this, a handwritten copy no less, while cleaning out a filing cabinet tonight. At the bottom I've written "Charlie Alfred, Education Services Manager, Object Design Inc, Object Magazine, May 1994". Apparently I've been carrying this around for almost 16 years. Since Google didn't find the article, I reproduce here for your pleasure (and so I can find it again myself).

Affinity for win/win

We strive to create an environment where the personal aspirations of each team member contribute to the goals of the team. We each are personally committed to achieving the goals of the team without sacrificing our lives outside work. We firmly believe that on the strongest teams the goals of the team agree with the goals of its members, rather than supersede them.

Common Mission

We share a common mission that is challenging, worthwhile, and clearly understood by all. This mission may be perceived by others as impossible or not worth the sacrifice. In this way, the mission helps us to identify our partners. Also, the more impossible the mission seems, the more we are forced to work together if we hope to succeed.

Quality

Quality is at the core of everything we do. If something is worth doing at all, it is worth doing right the first time.

Understanding Requirements

We strive to fully understand the requirements of the systems we plan to construct, including being acutely aware of how those requirements evolve over time. Furthermore, we actively validate our understanding of these requirements with the system's intended beneficiaries.

Interdependence

Individually, we each contribute strengths that counterbalance each other's weaknesses. Collectively we possess all of the skills, attitudes, and habits necessary for team success. Wherever an essential skill, attitude or habit is missing (or lacking), one or more of us makes it a priority to develop it, or we seek to add a new member who possesses it.

Receptivity

We are open to sources of new ideas and new ways of doing things, and use the norm to resolve conflict. We listen to each other's points of views, aware that our commitment to the same mission means that differences of opinion identify alternate paths to the same goal rather than competing paths to different goals. Also, we continually learn about and apply the latest paradigms, processes, and products in our technical, organisational and interpersonal activities.

Efficiency

Around here we work smarter, not necessarily harder. We sprint all out toward our goals when it is necessary to do so, but also know how to relax and rejuvenate. We make the 80/20 rule work for us. We take no shortcuts and cut no corners on the 20% of our tasks that produce 80% of our results. If any sacrifices must be made (in the interest of time), they always fall in the 80% of our activities that produce 20% of our results.

Thanks Charlie!