Lean Thinking

Dave Martin  

Dave Martin

Last time we looked at how to transform large organisations by building capability internally rather than buying capability externally. There are a lot of benefits to this approach. It's faster. It's cheaper. It's more effective. But it does fundamentally change the way an organisation sees its agile transformation program.

Most of the time, a traditional coach-led transformation program is set up to minimise the disruption to staff. Apart from some training and a new way of working (and maybe a slight blurring of strict job titles), the organisation sees its staff doing pretty much exactly the same thing they were doing before the change. Developers develop, testers test, they just do it in a new, agile way. With an internally-led transformation, this is not the case. A significant number of staff will be involved in this program for a long time. This will impact their day jobs. So the first rule of internally-led transformations is - give people time.

If you work for a large organisation and you want to transform the way you work to be more agile, what's the first thing you do? Chances are it's hiring a coach or two. That's not a bad way to start. Experienced people to guide the transformation make things much easier. But what do you do once the first pilot is done, you have proven that it works and demand is growing? More and more people are wanting agility. Your current coaches can't handle the load. What do you do?

What most organisations do is here some more coaches. And some more coaches, and more coaches and more as demand continues to grow. Now, as an agile coach, this has kept me in work for many years so I may be shooting myself in the foot a little when I say that this is a really lousy way to do an agile transformation. Yes, that's right. You heard it. An agile coach says that hiring a bunch of agile coaches is not a good way to transform an organisation. Let's look at why and then look at how we can do things better.

Ever been in a standup and heard something like this - "I could complete this task but I'd like to re-factor the code one more time"? What about this one - "All the acceptance criteria are met so I could move this story to done, but I won't because there are a couple of additional cases I think it should handle as well... So I'll add a couple of extra tasks and work on them today"? What about this - "The feature is complete but we can't put it in production yet... It really needs to be bundled with that other feature to make an impact in the market" ? Or this - "The MVP is done but we have decided to hold off on releasing it to market because it's not the complete, fully featured solution our customers would expect"? Or this - "We have decided to delay the release by another couple of sprints to add in some additional features that will enhance the customer experience some more"?

One description of agile is "the art of getting things done". Done is a great thing to aim for. Done means delivering value, making a difference, achievement. Unfortunately, a lot of the time we are pretty bad at it. Done has a mortal enemy that tries to prevent us from ever reaching Done. It continually moves Done further and further away from us. We take one step towards Done and its mortal enemy moves Done two steps further away. The name of this mortal enemy? Perfection.

01 November 2016

Simplicity In Design

In my last post on architecture, I touched on the need for design simplicity. Simplicity is one of the 12 agile principles:

Simplicity – the art of maximising the amount of work not done – is essential.

So it must be important. But how do we get there? Why, when simplicity is so essential, do we keep developing complexity?  Antoine de Saint-Exupére gives us a clue -

Perfection in design is achieved not when there is nothing more to add, but when there is nothing more to take away.

When we do design, we tend to take an additive approach. We look at a problem and add features until we consider the problem solved. The problem is that we tend to get carried away and add way more features than we need. We look at the initial problem and in solving that one, we lump together a bunch of related problems and solve those as well. We also have a habit of solving a whole bunch of problems that aren't actually problems yet but might be one day, just in case.

Good design, great design, is the art of looking at a solution and paring it down the the base essentials - the minimum we need to solve the problem. Let's look at a few examples of great design. The first one has been around for a very, very long time.

I have written about agile architecture before, but since I have been working with a group of architects recently (the kind that build software, not the kind that build buildings), I figured it's time to revisit the topic. The question that kept on coming up was "how do you do proper architecture in agile?". It's a good question. Agile is all about just in time rather than up front planning and traditional architecture looks a heck of a lot like a type of upfront planning. We even have a special term for what we want in agile environments - emergent architecture. Architecture that emerges just in time from the team. The problem is that while emergent architecture works fine in some problem domains, there are others where emergent architecture just isn't enough. If you're designing banking systems, or safety critical healthcare systems, or even just regular old big complex systems, relying on emergent architecture simply doesn't cut it. You need some level of upfront thinking (or at least longer term than a sprint or two ahead) to make sure your product doesn't fall in a heap.

Some of the scaled frameworks recognise this and introduce the concept of "intentional architecture" for the upfront stuff. The amount of intentional vs emergent architecture you do is a function of the type of system you are building. That's great but it still doesn't tell us much about how to do architecture (emergent, intentional or otherwise) in an agile environment. Before we look at how to do architecture, we should start by understanding what architecture is, and more specifically, what it isn't. Let me start by saying something really important. Remember this, there will be a test later - architecture is not the same as design. Many organisations, actually all organisations that I have worked for so far, have been getting architecture wrong. In these organisations, the architects didn't actually do any architecture. They produced detailed design documents. That's design. Not architecture. Detailed design absolutely should not be done up front.

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