I few years ago I got to hear a Toyota MD talk about frog and bike thinkers. The MD in question was an Australian that was being coached by leadership in Japan. Here’s my summary of what he said…

There are two types of thinkers in the world, frog thinkers and bike thinkers. If we are given the task of optimising the way that a bike works we can take it to pieces and investigate all of the individual components of the bike. We can improve them or rebuild them to improve their efficiency and performance. We can then rebuild the bike and there is a good chance that the overall performance of the bike will be improved. Try to do the same thing with a frog!

Frogs are more complex systems, where modifying each ‘component’ has major effects on the rest of the system. This to me is the heart of systems thinking - not all systems, in fact most systems in my experience, behave like bikes.

I find it interesting to reflect on how this relates to problem solving techniques. We’re often taught to Read the rest of this entry ?

The first ever Agile conference in Australia has just been announced: Agile Australia 2009.

The event is going to be held at the Four Seasons Hotel in Sydney on the 15th and 16th October.

If you’re looking for a good reason to come to Australia then this is it! The event promises to be great and I know the organisers are working on a great line-up for the event. Presentation submissions are being called for now; the deadline is early June so get moving. There is also the standard early bird discount.

As a frequent traveler I  should share that there are some great rates available on airfares at the moment, particularly from Europe and the US. And you can all stay at my house, so no excuses! I hope to see you there….

I just got around to watching my colleague, Ross Pettit, present on Restructuring IT. The presentation lasts about 30 mins and is worth a watch.

Ross has an interesting history as he has worked as a COO, CIO and CTO prior to becoming a consultant. In my opinion he’s one of the few people in the world that understands the application of Agile and Lean concepts at an executive management level.

In his presentation Ross makes some interesting comparisons between our current IT divisions and the industrial model of production and scale, encouraging us to think of the Detroit of today as our IT Division of the future based on it’s current trajectory.

It makes a nice prelude to a presentation that I’m working on for events later in the year, primarily JAOO in Denmark (October 4-9). I want to look at the background of our organisational structures in IT and then talk about the interesting changes I’m seeing take place. I want to split things into concepts that I’ve seen repeatedly applied and succeed, concepts that are emerging and working well and concepts that are yet to be applied but are tipped to be solutions to outstanding problems. This will give me a platform to talk about concepts like change models, systems thinking, process re-engineering and design, organisational structure, incentivisation, strategy deployment, throughput accounting amongst other ideas.

If you watch Ross’s presentation then let me know what you think…

I’ve never been a fan of offshore development. I’ve never been a fan of distributed development. I lose patience if the development team can’t see the customer, let alone live in a different building or city. I’ve had first hand experience of moving to an offshore model from both my time at British Airways and FoMoCo and I’ve never been convinced by the business case; the piece price may be cheaper but the value has always been questionable in my opinion.

I’ve changed my mind though. I’m currently running an offshore Agile project for a client, my first delivery gig in a couple of years, and I have to say I’m impressed. I’m working with the client on-site in Melbourne while the rest of the team are based in our office in Beijing.

On first instinct you’d have to guess that the distance would make an Agile process unworkable as it’s an immediate barrier to collaboration. Well, I think the art lies in project selection. You see, we’re working on the re-write of an existing application, which means the team can always use the existing application as a reference.

I’ve learned a lot about how to make offshore projects work over the last couple of years. Here’s a summary…

• Select the right projects to be off-shored.
• Plan to rotate key staff in both directions.
• Invest in collaboration tools (IM, Video Conferencing…)
• Bring the offshore leads on-site for inception.
• Have 2 stand-ups a day (One local. One with the remote team).

One of the key things that I’m learning, and my Lean experience is helping me deal with, is the fact that your buffers need to change in an offshore model. When the team is co-located it’s possible to let the stories get to very low levels as the ability to communicate quickly can always get you moving again. This is harder in an offshore model so we have to give the minimum and maximum levels of stories in each column more thought. We’re currently below our minimum and the developers are traveling so quickly we can’t get back to the right side of comfortable; we’d really like to have a dozen more stories analysed in the backlog to be in our sweet spot.

I have to say that the cost model is compelling. I’m actually for the first time quite worried about the future of on-shore development….

I strongly recommend starting any initiative to introduce new practices to an organisation with a readiness assessment. I wrote a previous post on common patterns that I come across when organisations decide to introduce Agile and Lean techniques. Many of the barriers to success can be identified and prevented with a little foresight resulting from a short, early assessment.

So, what should a good assessment include? I structure my assessments around people, process and technology. Each of these areas can pose their own barriers to change and often present their own challenges to successful adoption.

People

In this category I assess things like the current people capability, the perceived capacity for change, the staff demographics (PM, BA, QA) by roles and the organisational recruitment plans. It’s important to get early line of sight in these areas as it’s important to develop plans to improve skills and change the ratio of roles early.

I recently coached a team that had just started on the early stages of their project. I hadn’t been involved in the inception of the project and I was only there for a few weeks to help them get going. Unfortunately they had planned using their old Read the rest of this entry ?

I find the patterns that emerge from repeated tasks really interesting. When I first started coaching teams there was no way I could give the team or the organisation any predictions about what they were about to go through. A few years later I find it’s a very different story. I’ve found that no matter the industry, city, size or culture of the organisation, things always break in a common order…

(1) The People Break

The first thing that starts to hurt are the people. A big ‘orrible coach comes in and starts to introduce crazy ideas and people naturally push-back. They will make a lot of noise, some will adapt, others won’t, but the people within the organisation will be the first barrier to change. I’ve never worked on an engagement where we haven’t been able to get through this first challenge. Applying models like the Dreyfus model (of skill acquisition) and other change management approaches improves our chances of being successful at this stage. We have to stick with it - this stage will pass.

(2) The Tools Break

Once the people have settled into the new model, they often start to prefer the improved levels of control and collaboration. The next thing to start to hurt Read the rest of this entry ?

Owen Berkeley-Hill sent me this clip of an interview with Japan Airline’s CEO, Haruka Nishimatsu. I think it’s a great insight into Japanese management thinking; I love Nishimatsu’s response to the interviewers comment on US executives earning tens of millions of dollars. Priceless.

Enjoy.

…XP from the bottom.

It’s been an age since I’ve posted. I’ve been distracted by a hectic few months of work, a big chunk of leave and the new Led Zeppelin biography (which is awesome!). From now on I should be getting back into my regular posting pattern of at least a post a week.

I thought I’d start the new year by stealing something from someone else and relabeling it as my own work; I’ve made a career of it until this point so I see no good reason to stop now!

So what have I stolen? Well, I’ve come up with a new phrase that at some point in the future Dan North may claim was his first (he’d be completely correct). “Lean from the top, XP from the bottom”. I really like this turn of phrase because it nails my thinking around the best organisational patterns for IT in 2009.

I think XP is great. It’s values and principles are closely aligned to that of Lean and it has the technical smarts and discipline that I feel are missing from other Agile methodologies. It’s a great starting place at the bottom of the organisation for project delivery; XP is now a proven model that has been successful at an enterprise level for a number of years. Of course we can apply our Lean knowledge to help us optimise the approach we use to introduce XP to the organisation and apply our Lean techniques to ensure that we’re continuously improving our new process.

But what about the rest of the organisation? Those that have tried to introduce XP (or another Agile methodology) at an enterprise scale will know that this alone doesn’t complete the picture. How do we restructure our IT organisation to be more customer and process focussed? What about our friends in IT Operations & Support? How do we change incentive policies to encourage the right behaviours? How do we change our financial controls and governance processes to support our new working level philosophies? The Agile methodologies themselves are largely silent in this space leaving a large gap with enterprise adoption. Thankfully Lean, as well as being useful at a project level, can help us in this space too with concrete tools and countless large-scale examples. Hence “Lean from the top, XP from the bottom.”.

I think this will be particularly important in 2009. With the current economic conditions pressure is going to increase on IT divisions to do more with less. Cost controls alone can’t do this; we can squeeze our people to get more out of them but there is a limit - it’s fundamental economics. To get beyond that point we have to change our underlying models and thinking.

NOTE :: Thanks to Jonathan for pointing out that the time stamping on my blog posts seems to be screwed. For the life of me I can’t work out what’s wrong with it. The investigations continue.

Most organisations that I come across that introduce Agile techniques focus on a set of tools and practices that are applied at a working level only - test driven development, continuous integration, stand-ups, user stories etc. Even the best organisations that I get to work with only focus on the next level up and start to change governance processes, business engagement models, financial controls and other surrounding process infrastructure. I’ve only had the pleasure of working with one organisation where they changed the IT organisation from the top down as well as the bottom up. Guess which model was the most successful?

If we think of our IT divisions as socio-technical systems that our managers and leaders control, it becomes more apparent why any change has to encompass the whole organisation. Here’s an example of what I mean…

An Agile team have been happily working together for a number of weeks and are approaching a release of the application. In the final build the tester notices a few defects that have been missed until this point and highlights them to the developers and the customer. The developers decide that there is about one weeks work required to fix them and that the release would need to be delayed. The customer doesn’t feel that fixing the defects is worth one weeks wait so asks the team to deploy the application. Unfortunately the tester has an incentive that hasn’t surfaced until this point Read the rest of this entry ?

A few weeks ago I was lucky enough to spend a week in Toronto at the Agile 2008 conference. Here’s my summary of proceedings…

Agile 2008 Summary

• Something like 62% of the attendee’s were new to Agile.
• The race is on to monetise Agile! Oh dear.
• The Agile community is growing both in terms of expertise and adoption.
• There were a huge number of presentations on Lean and related topics - it’s a growth area.

Two areas of focus seem to be emerging beyond applying tools and techniques at a team level. The first is the development of models to introduce Agile processes to the enterprise in a structured way. The second is scaling Agile processes to an enterprise level - there seems to be a growing recognition that only introducing change at a team level is not going to cut it in the long term.

One gem of information came courtesy of Sue McKinney, a VP in the product division of IBM. Sue and her team started to introduce Lean concepts in 2005 across a number of teams (including Lotus Notes & CICS) with some help from the Poppendiecks. Sue stated that to date their efforts have saved them $90.6M (USD)!

The Wisdom of Crowds - James Surowiecki (Keynote)

James delivered a really interesting keynote that seemed to be a one hour summary of his book The Wisdom of Crowds. James explained that under the right circumstances the collective opinion of a crowd can be far superior to any individual expert within it. The story he told began with a chap called Sir Francis Galton who developed a social philosophy called Eugenics. Apparently Galton was a big believer in the ‘individual expert’ until an experience changed his mind. One day he was at a village fete and observed a competition where folk were guessing the weight of a cow - the closest guess got to take the cow home. Galton somehow got his hands on all of the entries following the competition and found that the average of the entries was better than any individual guess. He repeated the experiment and continued to get the same results.

James went on to explain that this is a consistent phenomenon, however some criteria are required to make it work Read the rest of this entry ?