Tag Archives: lean

Lean and Lego @ AgilePeterborough

I’ve been asked to present at the Agile Peterborough meetup this Wednesday, 20th March.

I’m really pleased that the organisers have asked me and that we have had so many folks register for the event. There is a growing software development and craftsmanship community centered on companies based in and around Peterborough and I’m delighted to support the group.

The talk is one of my favourites, Lean and Lego – Building the Millenium Falcon. I’ve given this previously for both clients and at Agile on the Beach and it’s always a fun topic.

With measurement comes control

In my last post on Why your organisation won’t be Agile I made the following assertion.

If your organisation is based on the traditional command and control management model and you cherry pick a set of project management techniques from one of the flavours of agile you will get visibility but not much else.

I promised to look at some of the root causes of the golf-course-agile movement and so here is the first.

Firms design for efficiency

John Roberts in his 2004 book The Modern Firm defines two main types of activities that make up an organisation. The first type are around the value chain – the set of routines and processes that are executed in order to fulfil an organisation’s strategy. The second are the supporting activities without which a firm wouldn’t function. Think HR, payroll and finance etc.

The optimal design of your value chain activites should enable you to execute your strategy as effectively as possible. Many large traditional organisations are designed around the idea of cost-control and efficiency. Make your processes as efficient and as cost-effective as possible as a mechanism for sustaining and, hopefully growing, your profitability.

In this world, decision making responsibility typically lies with middle managers whose direct reports are the people responsible for the value adding activities and who themselves report to either C-level executives or more senior managers. Decision making at this level brings some benefits from coordination of activities across different business units or groups within an organisation. An example would be a massive conglomerate where a middle manager is responsible for all the Software Engineering groups and who is accountable for results across those groups.

Strong incentives require measurement

The key word in that last paragraph is accountable. It is reasonable to expect that this accountability is tied in some way to increased rewards or incentives for generating better results and in order to qualify for those increased rewards the Manager must be able to demonstrate these better results.

Thus, the adoption of Agile project management practices makes complete sense in this context. Especially if it is linked to toolsets that offer Management Dashboards or other automated ways to interrogate the progress of the work in your business unit/division. Indeed, not only will your Manager’s Manager have access to the information she needs to demonstrate progress against her key metrics, she can use the new knowledge to increase performance further by concentrating on the (for a given value of) under-performing teams in the business unit. This gives the manager increased information on which to base their decisions presumably allowing them to make better ones.

Innovation retardation

This centralisation of decision-making comes at a cost. The information produced for individual teams must be standardised to a common format that enables the sort of aggregated and comparative reporting required by this model. This means standardisation of processes across teams within the business unit. And that standardisation comes at the cost of effectiveness. Designing or adopting a process, then locking it down and requiring all teams to implement it may be efficient, but it will ensure that each of the teams operate at a level of effectiveness below their optimal. Mandating the adoption of process is a guaranteed way to stop your teams innovating and changing their process as they find better ways of working.

Remember this?

The best architectures, requirements and designs emerge from self-organising teams

It’s from the Agile Manifesto and effectively states you get more maintainable, robust software if you delegate the responsibility of decision making to your teams. In my opinion you can add processes to that list .

What about this one:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Deliberately reflect on how you can deliver more effectively. The assumption is that you will change your processes over time as new information becomes available to you; as you learn. If you don’t do this, then you are an idiot.

Woah there dude! Are you saying that visibility is a bad thing?!? Surely you *do* get visibility with Agile?

Of course. And there in lies the rub. You do get tremendous visibility. Having hard data on whether you are going to hit your release date 1/3 of the way through a project enables you to have far more productive conversations with your business sponsors and even pull the plug if necessary. Code coverage metrics let the team feel safe enough to refactor the codebase, fix broken windows and deploy automatically on a regular basis. Big Visible Build Monitors allow the team to be confident that their software is always deployable and that they are a revert away from working code. The point of surfacing all this information is to allow the team to make decisions based on the feedback loops that provide it.

The first candidate cause of golf-course-agile is…

Here’s the problem then. The idea of a centrally mandated process designed by middle management or process mavens for the purposes of increasing visibility reinforces centralised decision making. If adoption is driven by a need to measure or increase visibility of the work being done because strong incentives require strong measures, you will end up missing a key part of the very thing that drives the huge increase in effectiveness you get by trusting your teams.

Without the devolution of decision making to the teams that are delivering the software; without the ability to make changes to the processes they use as they find new and better ways of working; you will get visibility but little of the increases in effectiveness that come from the ability to influence your own environment, to reflect and to adapt. In my opinion you won’t be agile. Whatever it means.

Next up, Ivory Tower Process Mavens, and the systemic reasons they fail

Why your organisation won’t be agile – Part I

I’ve been peddling a talk around the place recently. Ostensibly it’s on “Why your Agile roll-out is failing”. Though Dan North got the name first. So I called mine Agile Adoption Anti-patterns. meh.

The behaviours I describe are based on my experiences over the last several years as a developer and coach. They seem to indicate a number of systemic problems that organisations face when looking to go agile.

One conclusion I reach in that talk is that you will fail unless you are prepared for systematic change in the organisational architecture, the people, the culture and routines that define your organisation.

Ok, that’s pretty strong. let me rephrase that.

If your organisation is based on the traditional command and control management model and you cherry pick a set of project management techniques from one of the flavours of agile you will get visibility but not much else.

Golf course agile

“We want to be ‘Agile'”

“Really? You want to learn how to value and trust your people? Be courageous? Build the right software at the right time? That stuff? Cool! I can help with that!”

“Umm, no. We want predictability and metrics. I want to know our velocity so that I know how lazy my developers are.”

“Oh, ok. Rename all your Six Sigma black-belts to Scrum Masters*. See how that works out for you and call us in 12 months when it doesn’t. Then we’ll chat about the rest of it. Failing that, can you just leave my card on your desk for the next CIO that comes through? Thanks.”

I used to find it was the developers who were into the idea of working in a more agile way. I think there are two reasons for this, the first is that undeniably there are shiny new tools and techniques out there that are associated with Agile. BDD, CI, Pairing etc all appeal to developers looking for ways to manage complexity in their code.

The second was that contrary to the popular image of a developer as some crusty old bearded dude (and it’s always a dude), sitting in a darkened room, only caring about copy-on-write semantics for lists, most are unbelievable passionate about their jobs and Doing The Right Thing. And incredibly intolerant of the wasteful processes they have imposed on them. Some even actually care about getting the right software out in front of their users so it can be used.

So for some of these reasons and almost certainly for a bunch I haven’t thought about, developers started getting the Agile bug years ago. It describes my reasons anyway. Plus I’m a hippy. Shrug.

Fortunately, the golfing class has now caught up. That’s a good thing right? Agile is going mainstream. Everyone and their dog is doing it. It’ll fix all our problems! Everything will be visible.

Management iz in ur progekt, wotchin ur progrez

Except I don’t really see Agile becoming mainstream. I see iterative development becoming mainstream, visibility becoming mainstream.

In fact, what I see most is that Agile is being used as another mechanism by which executives exert more control over their staff. Visibility onto a project should not mean you know who to fire when it fails. I haven’t seen much in the way of courage becoming mainstream.

In part II of this post I will talk a bit about the root causes of some of this behaviour. Stay tuned…

* Disclaimer: I’m not saying that Scrum is any more guilty of this than any other methodology, just that it is very popular. No-one ever got fired for choosing Scrum.