Lean Thinking

17 February 2015

The Measurement Fallacy

Written by Published in Agile

As soon as someone starts looking at the topic of metrics, the measurement fallacy pricks up its ears (I always imagine it looking somewhat rodent-like with mangy fur, evil eyes and sharp teeth) and gets ready to emerge from its hole behind the database server. When people start discussing what should be measured in order to keep track of a process, it gets ready to strike. Most people have fallen prey to it at one point or other. Mostly without ever knowing they have been bitten. The bite is painless. The only symptom is that the bitten suddenly assumes that because we can measure something, it must be important. More serious cases assume that the easier something is to measure, the more important it must be. This dreadful scourge is responsible for making Lines Of Code the primary measure of developer output for years.

It's a typical case of a severe bite - we can measure lines of code. Therefore it must be an important measurement. It's really easy to measure so it must be a really important measurement. Therefore we must measure it and use it to drive developer behaviour. Once it sets in, it's hard to shift. Despite the fact that the behaviour it drove - writing masses of wordy code to inflate your LOC counts and never, ever remove code - was completely counterproductive, the LOC (or KLOC) still hangs around to this day.

03 February 2015

I'm Writing A Book!

Written by Published in Agile

Hi Folks and Happy New Year.

At the end of last year I did kind of promise you some news when I started up again in the new year. Here it is - over the break I made a start on writing a book. It's about Enterprise Agility and how to achieve it through a set of patterns that can be applied to organisations.

In agile style, I will be writing this in small (hopefully) frequent iterations. The first iteration is up now through Leanpub as a free download (you can pay for it if you really want to but you might want to wait till I have some more written before making up your mind). https://leanpub.com/enterpriseagility

I have two hypotheses to test with this first MVP - 

  1. That I have an idea that is worth turning into a book
  2. That I can express it clearly and interestingly enough to make it into a good book.

I would love to get your feedback on the first iteration, either here on the blog or through the comments section on the book's Leanpub page.

Please have a read and leave me your comments. Help me prove (hopefully) or disprove (hopefully not) my hypotheses.

02 December 2014

Fully Aligned

Written by Published in Agile

Over the last few weeks we have been looking at the various organisational alignment patterns - top down, bottom up, etc. In each of those, the way to move forward once you have hit the limits of that particular pattern was always to extend alignment vertically and horizontally to other parts of the organisation. I made mention of a wondrous state that could be achieved where the whole organisation shares the same goals and is working together towards a common goal. Welcome to the Fully Aligned pattern.

This is the end goal for any enterprise agile adoption. This is the pattern that will really let you grow agile within the organisation and firmly embed it into the culture. This isn't just a desirable end state though. In my experience this is a necessary end state if agile is to thrive and become part of the organisational culture. Without full alignment, agile tends to wither away to a sort of agile-ish (or fragile) set of practices that are followed without really understanding why and more importantly without really delivering real business benefit. If agile is to deliver real benefits at the enterprise level, you need to achieve alignment.

Before you run screaming at the thought of getting all however-many tens of thousands of people in your organisation aligned (which sounds like an impossibly daunting task) you will be relieved to know that you don't have to get alignment across the whole organisation to be successful. The key here is that big organisations aren't really one organisation. If you look closely at them, they are a collection of multiple, smaller businesses under a common banner. Each of those separate business will have its own leadership, its own culture, its own challenges.

The trick here is that these sub units may, or may not correspond to the organisation's official organisational structure. What you need to find are the value streams. This is a concept from Lean and as a basic definition, a value stream represents all the work that needs to be done to get business value delivered from an idea - from concept to cash. In a product development shop, that might be a request for a new feature and all the work that needs to be done to get that idea into a release of the product. A typical large enterprise will contain many value streams. They may produce multiple products for multiple markets. They will have purely internal value streams representing work done on their own internal systems and processes. Anywhere where work is being done to deliver business value, you have a value stream.

These value streams may align to the org structure. In some large organisations, they are broken up into vertical markets where that organisational structure is responsible for everything to do with delivering into that market segment. More often though, value streams cut across the organisational boundaries. To deliver a product release, you may require resources from a frontline business unit that deals with customers plus resources from an IT delivery business unit and a production support business unit and so on. Organisational structures are typically organised vertically around job specialties or technical competencies while value streams tend to cut horizontally across multiple business units.

What you are aiming for is alignment across a value stream, or set of related value streams. This is the smallest subset of a large organisation where you can make a real, sustainable change. An optimisation of a value stream will make a measurable difference to the organisation's bottom line. Optimising only part of a value stream won't, or may even have a negative impact as this results in sub-optimisation - the part you optimise will run better but often at the expense of other parts of the stream which then eat up all the benefits (and often more).

So, first find your value stream. Now you need to see how its aligned. Is it all contained within one element of the org structure (in which case your life just got a lot easier), or does it cut right across (in which case your life just got harder)? As soon as you start to cut across organisational elements, you start to run into organisational politics. Take a look at the existing alignment patterns. Is the value stream alignment top down or bottom up? Is it IT or business lead? That will determine your initial engagement and how far that engagement can go. What you need to do now is start to improve the alignment until you get the whole stream aligned.

By working along value streams, you get alignment more easily than working within regular organisational structures. The reason is that most business units do multiple things - the IT business unit will have teams servicing dozens of different parts of the business, all with different goals. Aligning that will be a huge mess. A value stream though is already aligned around getting stuff done. That gives you an existing common focus to work with. Everything can be pitched around improving progress towards their goal. The difficulty of course is that most organisations don't recognise what their value streams are, so they will need to be educated. You will also run into a lot of empire protecting - if a team is now seen as part of a value stream, and is managed as part of a value stream, it may loosen a manager's hold over that part of their corporate empire, so be prepared to deal with that resistance.

Once you have aligned one value stream, build out to the adjoining ones. Build off the initial success and align the whole organisation stream by stream. You will find that different value streams have different alignments for example, your first stream may have been aligned bottom up but your success with that one gets noticed by senior leaders in other streams which results in a top down pattern in the next one.

You won't be able to do this on your own. Big enterprises are a lot of work. You will need a team to help you. In each value stream you will need to build a team of champions to take some of the load and make sure things keep running when you are elsewhere.

18 November 2014

Business Lead

Written by Published in Agile

Last time we looked at one horizontal alignment direction - IT lead; today we'll look at the other - Business lead. This is much less common than IT lead. Agile has its origins in software development and the IT side of an organisation is usually much more aware of agile and agility as a concept than the business side so it is natural that the drive for agile would come from there. Business lead does happen though. The problem is that when it's business driving agility, it's either because the business is really advanced and is actively seeking out ways to transform itself (great but not likely) or they have issues with their IT department and have heard of this thing called Agile which apparently makes IT departments deliver stuff.

Yes, if the push is from business, it's usually because there are delivery issues and someone in business has seen agile and sees it as a way to make the IT guys deliver faster, or better, or cheaper, or some combination of all three. Even when business is asking for agile, it is still (most of the time) seen very much as an IT thing. The brief is usually "go make our IT teams agile". Of course the IT teams just love business folks telling them how to write software don't they? If your business is in the "really advanced and looking for ways to transform itself" category then it's likely your IT department is as well and your life just got a whole lot easier. But that's a different pattern.

04 November 2014

Horizontal Alignment

Written by Published in Agile

So far we have looked at the vertical component of organisational alignment - which level of the business is pushing for change. Today we will look at the other dimension. Most businesses are split vertically into different layers of management and also horizontally into different operational units. Every enterprise does this a bit differently but in most of them the main split is usually between "business" and "IT".

Business groups connect directly with customers and come up with new products and features. IT groups tend to sit in the background and do... geek stuff. Now, those who have been doing agile for a while will know that one of the things agile does is to break down this artificial split and align IT teams directly with the business. For an organisation right at the start of its agile journey though, you are more likely to see this structure than not. When planning the transformation, one of the keys is finding where the drive for agile is coming from. Is it Business? Or is it IT? Both situations have different challenges.

Written by Published in Agile

We have been looking at organisational alignment patterns over the last few posts. We have covered the two common ones - bottom up and top down. Today I'll look at a far less common one - Middle Out. As the name implies, this pattern occurs when change is being pushed by the middle of the organisation - middle management.

Actually uncommon is an understatement, middle out is so rare that I have never seen it in the wild. It's still worth looking at though, as winning over middle management is key to the success of the top down and bottom up patterns we looked at previously. By looking at why middle out is so uncommon, it can help us to understand what prevents change from occurring at this level in large organisations, and to see what we can do to change that. What we are talking about here is the phenomenon of the frozen middle.

Written by Published in Agile

Last time we looked at the bottom up pattern. Today we'll look at its inverse - the top down pattern. In this case, the top levels of the organisation want agile but the levels below them are resisting (again, if they aren't... great, but that's a different pattern). This can be a tricky pattern as senior execs may want agile but often don't know much about what it is and what it means for their organisation. With most agile adoptions, you need to spend a lot of time educating your detractors, with this pattern you may need to spend as much time educating your supporters as well.

They probably see agile as a delivery methodology and expect it to be implemented that way. They don't see it as a major cultural change at all levels (including theirs). Tread carefully. Don't lose them. It's very easy to go in too hard, making it seem like too big a change too quickly. Senior managers got where they are by successfully managing risk. They tend to be quite risk averse. They will want to see a strategy that manages organisational risk during the transition.

Written by Published in Agile

Today I'll start looking at organisational alignment patterns. The first thing I should do is explain what the heck I mean by that. In this context, organisational alignment is which parts of the organisation are supporting an agile adoption. This is a really key thing to know because where the support for agile is coming from will seriously affect how agile can be introduced, how far it can go before it meets resistance, the type of resistance it can meet and so on. Having worked as a coach in a number of companies, I have found that organisations tend to align around agile in a number of fairly standard ways. I call these standard ways alignment patterns. There are two dimensions to an alignment pattern - vertical (which layers of the business are aligned) and horizontal (which parts of the business are aligned).

If you can pick which alignment pattern you are dealing with, that gives you some insight into the sorts of issues you will experience when managing an agile transition. Knowing your alignment pattern lets you pick the right adoption pattern to get the best success. Essentially, different alignment patterns work well with certain adoption patterns while blocking others. Pick the adoption pattern that matches your alignment pattern and things will go smoother than picking one that is incompatible. Or if you want to use a particular adoption pattern but it's incompatible with the current alignment pattern, then you may need to change the organisational alignment before proceeding. Anyway. I'll talk more about this mixing of patterns later. First I'll start by describing the basic alignment patterns, starting with the most common - the bottom up pattern.

Calendar

« November 2017 »
Mon Tue Wed Thu Fri Sat Sun
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30