At last years Agile Australia conference, an Australian branch of the Agile Alliance was proposed and created. Local branch meetings of the Agile Alliance Australia (AAA*) have been organised over the next few weeks. If you’d like to attend (all are welcome) you’ll need to register at the respective meetup events for Melbourne and Sydney. I believe events are also being organised on a regular basis in Perth and Brisbane. I’ll post the details as I get them. Hope to see some of you there….
* Not to be confused with AA Australia. That’s something completely different, although you’re likely to see some of the same people at both 😉
I’m in Aarhus, Denmark at the moment for this years JAOO conference. I got here on Tuesday after 36 hours travel from Melbourne. Urgh. The conference has been great; there are some amazing speakers here (Mary Poppendieck, Dave Thomas, Michael Feathers, Linda Rising, Martin Fowler, Bob Martin) and the whole place has an amazing buzz to it – I’d strongly recommend this conference.
I’ve been nervous about my presentation at JAOO for a while, mainly because the audience is filled with hard-core programmers and I tend to talk about more of the management aspects of IT. It turns out that the there is definitely an audience for my work here though; from the feedback I’m guessing somewhere around 150 people attended my talk and the response has been very positive so far.
My talk is brand new and has the title ‘The IT Division. Refactored’. I’ve just uploaded it the the presentations page of the site. The theme of the talk is built around IT divisions having a systemic problem – if we look at the numbers it’s clear that we can change the people, the country, the industry, the market etc. and still get the same repeatably poor results. I then start to introduce systems management theory and talk about how that can be used to rebuild IT divisions to work in fundamentally different ways. I look at organisational structure, processes, culture and people capabilities and walk through the approaches I’m taking to move towards more systems based operating models for IT. If you take a look at the deck then let me know your thoughts…
Recently I’ve been doing a number of assignments that involve a significant amount of organisational design. I think that the conventional thinking in this space is completely broken and only a view that breaks the existing convention will help.The work I’m doing seems to start from this problem statement: “I’m a CIO and I believe that Agile is a better way to work. I’m ready to re-shape more than just my software delivery teams to improve productivity. What do I do?”.
Here’s where I become a heretic. I’ve read most of the material on ‘Enterprise Agility’ and I think it’s fundamentally wrong. The reason I think it’s wrong is that it takes the existing paradigm and tries to tweak it to make it ‘Agile’, however the paradigm is inherently un-Agile. I think we have to be increasingly radical in our approach to solving this problem.
Here’s a graphical representation of what I’m trying to get at…
In the diagram the X-axis represents the choices of organisational architecture available to us (structure & process). The Y-axis represents the performance resulting from the selected organisational architecture. Of course in the real world this is a multi-dimensional problem; I’m not including people capabilities and culture in the model.
If we start at point X then we can use continuos improvement (Kaizen) to get to point A in the model, which is the local optimisation for the selected architecture. However, if there is another, higher performing optimisation out there (B) – and I believe there is – we won’t find it from point X using continuous improvement. If we move to the right we will detect that process performance is worsening and move back to the left, towards point A. To get to point B requires read more…
Command and Control Management
Managers create the system and set the targets for the workers. The initial focus of failure is on the people. Managers manage the people.
Systems Management Theory
Managers and the people in the process create the system and define the system performance measures. The initial focus of failure is the system. Managers manage the process.
I’m spending a lot of time at the moment working with governance groups, steering committee’s and PMO’s to introduce Lean ideas. There’s a common challenge that I keep coming across. First up, size matters. I was going through the 2009 Standish CHAOS report today to gather some data for a presentation. Here’s what they have to say about project size and it’s relationship to success…
- 61% of all successful projects are under US$750,000.
- 80% of all successful projects are under US$3M.
- Projects over US$10M have less than a 2% chance of success.
So, we need to keep things small, breaking projects apart where possible to deliver in small chunks to increase our chances of success.
The tension is that governance groups often prefer to manage one $10M project than lot’s of small ones. This is generally a pattern in large corporates rather than on-line product companies, who have understood this for years, often moving away from project models and towards product models where key products are slowly evolved over time, using the returns they generate to reinvest.
Keep it small. Keep it simple. Software by numbers.
It made me think about when I first came across a kanban process in the manufacturing plants and has inspired me to write down the story. As it’s quite a few years ago now some of the details are a little hazy but I’m sure some of my old FoMoCo colleagues will jump in and correct my inaccuracies.
It all started for me when I started a new role in FoMoCo’s Plant Floor Systems team. The team that I joined was called Synchronous Material Flow, which from what I could gather was an incredibly complicated way of saying ‘the team that helps plan and co-ordinate the movement of materials around the plants’.
This team had spent a number of years trying to solve a problem: how to manage the flow of parts from the supplier deliveries to the correct points on the production line as effectively as possible. Being a smart bunch of people the team had modeled the process, looked at the available technology and come up with a solution. Here’s how the system worked… read more…
I just made Jurgen Appelo’s list of ‘Top 200 Blogs for Developers’. I’m sneaking in there at number 198, apparently down from 150 when Jurgen last published the list. It’s my own fault for not blogging for almost three months!
There are some great blogs in the list that I’m already aware of and a heap more that I’m going to trawl my way through. Let me know if you come across any that are worth a look…
Oh, and the irony of being a non-developer appearing in the list isn’t lost on me either!
A few weeks ago I flew to Canada to deliver presentations in Calgary and Toronto. This time it was for joint presentations with Kraig Parkinson, who works out of our Canada office. The nice folk at InfoQ were at the Toronto presentation to record it. You’ll find the video here: Lean Software Development Presentation.
If you watch it then I’d love to get your feedback…
Andy asked the audience to put their hands in the air if they had ever read an e-mail from a manager within their business praising the success of a project. 100% of the hands in the audience went into the air. Andy then asked the audience to raise their hands if they had ever received a similar e-mail that was congratulating someone that had tried something bold and risky and had failed. No hands went into the air.
Today I had a conversation with an expert on innovation. He walked me through a very interesting model that he has developed that helps frame the dynamic of innovation within an organisation. He has three dimensions that he walks through, one of them being leadership. He argues that it’s the role of leaders to create a culture that accepts a degree of controlled failure, as it’s these activities that move the organisation forward.
Are we encouraging the right behaviours?…