Lean Thinking

Don't Panic I.T. Solutions - Items filtered by date: November 2016
Published in Agile

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.

Published in Agile

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

Published in Agile

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.