Lean Thinking

Written by Published in Agile

This post is the result of a conversation I had the other day, over a few after-work beers with Andrew Knevitt. He deserves a large part of the credit (and/or blame) for this for starting the ball rolling. Andrew was bemoaning the amount of legacy he had to deal with and I immediately started talking about code and automated testing. This wasn't what Andrew was referring to though. He was working mostly with business process and was referring to the problem of legacy business process. We all know the problems of legacy code - hard to maintain, fragile, lots of manual testing required. Legacy business processes have similar problems - clumsy, fragile, constantly out of date, lots of manual work required, and so on.

We both agreed that legacy process was a problem but neither of us could come up with a good explanation of what made a business process legacy. It's more than age - some old processes work really well but some brand new ones are out of date as soon as the ink is dry. So what makes a business process legacy? During the course of the discussion, I trotted out one of the more common definitions of legacy code - legacy code is any code written without automated tests. That was when the lightbulb went on for both of us. Legacy business process is any business process without a built-in feedback loop. But not just any feedback loop. A 2 yearly process review cycle isn't enough. It has to be fast feedback.

Written by Published in Agile

I am working with a team that has a great VMB. It's the first thing people say when they walk past and see a stand-up in progress - "what a fantastic VMB" they say. And it is indeed fantastic. It represents the team's work really well. It's clear and easy to understand. It shows obstacles and what the team is doing to overcome them. It really assists the team in their stand-ups. It facilitates discussions between the team and its stakeholders.

The next question people invariably ask is -"can we set up our board like that?" Of course they can. The VMB design isn't proprietary to the team. Anyone can use it. So they do. Copies of this fantastic board are springing up everywhere, but pretty soon they come back and say "there's something wrong. Our stand-ups don't flow as well as yours and the board just doesn't work. Have we copied something wrong?" Yes they have. They have copied the wrong thing entirely. The thing they haven't realized is that my team's fantastic board, and the fantastic stand-ups and discussions it facilitates, has nothing at all to do with the layout of the board, and everything to do with the performance of the team.

Written by Published in Agile

The responsibility trap is a very easy one to fall into. The symptoms are easy to spot - it's 11pm, you are sitting in an empty office, buried in work up to your eyeballs. Everyone else went home hours ago. Weekends are a myth. You haven't seen your family for days. The agile principle of sustainable pace applies to everyone on the team... except you. How did it happen? The trap is a really easy one to stumble into because it's insidious. You can wander in without realising you are inside, you won't notice until you are deep inside and by then it's too late. Try to leave and the trap will snap shut around you. While anyone can fall into the trap, it's particularly easy for people in expert, leadership or coaching roles to get stuck in it.

The trap is really simple, it works like this - the team needs something done. You, as "the expert" in the area, take it on and do it. The next time it needs doing, you do it again. Now, everyone just expects you to do it. Then something else comes up and, as "the expert", you step up and do it. And so on, until you are buried in a pile of work. Your intentions were good - the team needed something done, they were busy, it was urgent, you did it. What's wrong with that?

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.

Calendar

« February 2018 »
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