Lean Thinking

Written by Published in Agile

In the agile community we love fast. Fast feedback, fast delivery. Fast is good. Slow is bad. Why then is the most common complaint I get about agile - "All this team stuff distracts me from writing code. We can't deliver fast if I can't write code". That's a good point. We are taking our devs away from coding to some extent. In an agile team they can’t just sit down in a corner with their headphones on and just cut code solidly for a week. There's a lot of team interaction that has to go on to make the team run smoothly.

So are we, by doing agile, slowing down delivery of code? Quite possibly yes. But what about fast delivery? How can we say we are about delivering fast but slow down the people who are actually delivering the code? The thing is, we don't actually deliver code. If we just delivered code we would go out of business. What we deliver is working, tested, fit for purpose code. More fundamentally than that, what we deliver is business value, not code. Agile is all about speeding the delivery of value, not the delivery of code.

Written by Published in Agile

Faster, Better, Cheaper. That's the way agile is usually sold. Faster delivery, with better quality and lower cost. That's the pitch I hear over and over from people trying to get organisations on board with agile. It's an attractive pitch too. Who wouldn't want something faster, better and cheaper? The only problem with the pitch is that it's not really true. Not initially anyway. Agility will eventually get an organisation delivering faster, better and cheaper but, at least initially, it will be slower and more expensive (it will usually be better quality though). It may well stay slower and more expensive for a long time if the organisation has to overcome a lot of legacy (not just code but culture and processes as well).

So when the organisation goes to measure its new agile initiative and finds that it's not getting what it was sold, questions get asked. And well they should. The first is usually "Why?", to which the standard answer is "cultural change is hard....", the next is usually "When?", to which the answer is usually a shrug and some more about how hard cultural change is. This is often the point where the senior leaders that were really keen on agile, suddenly stop being keen on agile and organisational support vanishes. Given the length of time it takes a big organisation to get to faster, better, cheaper with agile, we really do ourselves no favours by using that as our selling point. What we need is something we can have an immediate (or at least relatively quick) impact on, that is also going to have a positive impact on the business. Fortunately it exists - risk. Agility should be sold as a means of reducing risk.

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.

Calendar

« April 2019 »
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