My recent post about Agile raised a few question and comments. Two people suggested Lean software development as something for us to look at, and there were a few suggestions and thoughts around my ideas. So I thought I’d go over Lean, how we currently work, and also clarify the points in my last post in a little more detail.

Should We Switch To Lean?

We’re actually already doing Lean software development to an extent. Our story boards are still Scrum based, but we have process flows defined , work in progress limits, an “empowered” team, a reduction in downtime/unnecessary features/etc… (waste) and delivering value is our highest priority.

We still work in typical 2 week iterations, doing “Scrumban” as people like to call it. I still like to think of it as an Agile mash-up though as our process is made up of a number of process tools. For example Scrum and Lean software development are both lacking in technical practices. This is where XP comes into the picture, providing us with TDD, Pair Programming and Continuous Integration. Here’s a simplistic comparison chart comparing some of the agile methodolgies.

Scrum Didn’t Work?

From reading blogs and seeing the buzz around Agile processes in the past, such as XP and Scrum, they are easily done wrongly. And after a less than agreeable experience many people look for another methodology in search of the Holy Grail that is the perfect development process.

In the case of Scrum it often fails because of trying to fit an existing and inefficient company structure to it, rather than changing the structure to suit Scrum. Scrum also details little about how to control a team during development. This is especially apparent in larger organisations. We have a development team of around 14 so haven’t run into such issues with Scrum, and it works quite well at pulling together our 2/3 sub teams.

If you’re getting into Agile consider using a consultant (if you don’t have a point man at work), and read as many books and blogs as possible. It’s best to follow them to the word until you’re set up, then once you’ve got going ensure you begin to mould the process to suit your needs (this is an important thing to do).

Constantly Change And Adapt

Anyone familiar with The Book Of Five Rings by Miyamoto Musashi may remember the quote:

Do not develop an attachment to any one weapon or any one school of fighting

The same principle applies with Agile.

  1. Sticking to one process, done by the book, means you won’t ever improve, (you won’t without trying new things and learning).
  2. There’s the danger of becoming “comfortable”. A comfortable team is never a truly competitive one.
  3. You can become stale, and your developers will be challenged less. This can affect output.

As mentioned, there is no one perfect development process. The perfect process is an ever changing one, defined purely for your needs. It is also a mixed process, take what you need from each methodology.

If you’re into such books I’d also recommend Hagakure, The Art of War, and even Tao Of Jeet Kune Do, as they all contain similar combat quotes that you can in some way apply to Agile. Often very obvious, but sometimes that’s what you need.

Cost Per Point

As mentioned in my previous article I think it’s important, from a product and business perspective, to have a concept of cost. How much will it cost to develop story ‘x’?

  1. It helps work out the value of a feature in relation to its rough cost.
  2. It can be used to see if there are serious problems in the development team (in terms of output, are they hitting their commitment? are their commitments too low? do they cost too much?).

From a development team perspective, it’s not something you need to monitor, but should still be trying to reduce. After all the cheaper a business can produce something (not at the loss of quality) the more profitable it is likely to be. I’m sure all companies/product owners would be grateful for more output, and cheaper overall cost (but with no loss of quality).

What Is Value?

Value can be defined in two ways:

  1. Customer Value
  2. Business Value

Both are important, but at the core of it is value to your business and this is why the above “Cost per point” is an important concept. We’d all like to offer features that purely provide value to the customers, but in the case of Twitter you may never make a penny. It always come down to money (directly or indirectly) unless you’re an edge case (like open source development). Your company needs to make money and a profit in order to survive. It can develop something, but at a cost. So development needs to be prioritised and valued.

We could for example build an iPhone app for Huddle at a cost… let’s say £1,000. If only 10 people were predicted to use it though, the value would be relatively low. However, it would be good PR (which costs too), so that has to be taken into consideration. Does the iPhone app need to be maintained? What would be the lifetime cost of building it? This makes defining your backlog a difficult thing to do. It’s all common sense, but amazing how some companies (again larger ones typically) can get lost in what they’re doing and not realise the costs outway the benefits.

In Lean you can increase value by decreasing cost, and one way of doing that is by decreasing waste. There are effectively two concepts of “waste”, development and planning.

As developers we’re told what to work on, so it’s our job to do so efficiently and in a way that delivers quality at as low a cost as possible in order to maximise value. The Product Owner and business also have to reduce waste in terms of choosing the right stories to develop, reducing wasteful development. It’s no good having a lean software development team if the stories being pulled in aren’t thought out, wrongly chosen, or in the end don’t actually offer value.

Adding Value

This topic caused a fair amount of discussion, possibly through lack of examples of my behalf. I think many teams often get fixated on delivering the highest priority stories, even when circumstances change or problems arise. Or there can be too much focus on value purely from a customer perspective, rather than a business perspective. When circumstances change, the team needs to change/adapt too. Reactive development is a term thrown around. You should always be looking to provide maximum value. In some cases that can mean not delivering all of the highest priority stories. Let me explain.

  • Choosing Work To Suit The Team – my point here was getting the most from your team, or organising the work in such a way that they can get through it more efficiently while still providing value to the customer. This comes down to careful planning and small compromises, and questioning situations. For example:
    • If there’s little UI work for example, team commitments may be reduced as you’re putting team members into non specialised roles. Do you accept a lower commitment per iteration, and get some of the highest value stories done, or a higher commitment, and more stories done, but not necessarily all of the highest priority stories?
    • Keeping team members out of position, not only compromises output, but can affect morale. As much as I respect testers, it’s not my sort of thing, and I’d quickly get bored/frustrated if always having to test possibly causing me to work even less efficiently. How do you balance keeping your team happy so that the amount of value delivered doesn’t drop?
    • Keep in mind the cost of keeping people out of their normal role, and how this may affect the value of a story. The more a story costs to develop, typically the lower its value will become. In many cases the work can be allocated in such a way that utilises your team to the their fullest while still providing high value. I don’t mind doing the odd bit of point-and-click testing, but as a Senior Developer I’d be a fairly expensive point-and-click tester if I was doing it on a regular basis.
    • It’s good to utilise your team keeping everyone in their specialist area, but do try to swap roles occasionally, and pair program frequently as a way of swapping skills between team members. This needs to be done, as usual in good balance and moderation.
  • Output Can Equal Value– my point here is adding more value and output at little cost just through simple efficiency. Just to go over the example.
    • I’m working on a 5 point story. I notice an overlooked 1 point bug in the same area. As it’s in a similar area of the code, I can actually do the 1 point bug for 0.25 points (as we’ll already be testing that same stuff). I let the product owner know, who makes a decision whether to include it or not. Typically he will if the bug is something we’re going be working on in the short term future as it saves duplicating work (and hence reduces cost). The customers gets a better product and the business cuts 0.75 worth of work out of the backlog. Identifying and linking related work is very important if you want to increase efficiency and lower development costs.
    • Also as mentioned in the above point, you can have a higher output and more value in some cases. Say circumstances change and a problem arises. You can either have stories 1 & 2 (higher priority, less output) delivered, or 1, 3 & 4 (lower priority, more output) delivered. Let’s say we have two free UI developers. We could get them testing, and get 1 & 2 delivered. Or, move them onto slightly lower priority UI stories, and get 1, 3 & 4 delivered (a simplistic example I known there are issues around risk of delivering and workflows). Which is of more value?

As with all of the above points, they aren’t rules, but examples of when a team may need to adapt/change and reactto provide the highest amount of value. It’s all contextual, but you should be trying to identify such problems and work around them. It’s difficult to give guidelines how to achieve this. It comes down to a team and business that communicate well together and are flexible in what they do. The examples are used as a way to make people think.

Opportunity Cost

The danger of providing additional work (linked work) is the opportunity cost. As mentioned in the above example, a 1 point bug could become a 0.25 bug if linked with a certain story. The only problem then is, could we be doing something of even greater value for that 0.25 worth of work? And how do you justify this? Unfortunately this becomes very difficult, as it can often be hard to value certain pieces of work, especially smaller pieces.

Everything becomes less black and white and a bit more grey, and really comes down to good decision making. At Huddle we’re lucky enough to have plenty of work to do, and a stack of ideas all waiting. So in most cases, if the additional work is picked from high up in the backlog it will offer high value, and it’s probably not worth the time arguing or searching for an alternative. Especially in the case of the example when it’s only a 0.25 point piece of work. I’m not saying don’t discuss doing the additional work, always discuss, but don’t spend too much time looking for better opportunity. Make a quick and efficient decision with your team whether or not to pull it in. It’s easy to start applying the rules and over discussing things in Agile, at which point you’ve wasted the potential time and lost the chance to add 1 point worth of value for 0.25 point. The larger the additional story though, the more you should discuss it.

Taking Lean A Step Further

The Poppendieck’s mention doing iterations within Lean software development, and we currently do this. Shorter iterations can help deliver work more quickly to the customer. Your releases are still contained by the length of an iteration though. Say for example we can do 20 points in an iteration, and we have a feature that is 22 points. Does that mean we have to wait two iterations for it to be delivered to the customer?

One concept would be to keep the trunk in an always releasable state. That way you can be more flexible with regards to when you choose to do a release. You could release at any point of an iteration ie (after the 22 points have been completed), rather than typically releasing at the end of an iteration. But how do you do this?

Branching per feature. Create a branch per feature, develop on that branch, test the feature, and when it’s complete, merge it back into the trunk. A simple and fairly commonly used technique.

There are obviously complication around setting this up. Moving away from Subversion (to something like Git maybe) is one, and merging complications. But such a set up will stop the build breaking cross team, and also mean you don’t have to rollback work if it doesn’t make it in time for a release (saves dev time and cost). Vertical partitioning aside, it’s a lot more flexible and takes advantage of source control a lot more. Especially when compared to the usual process of everyone working from the trunk.

Another idea would be to let the work define the length of the iteration, rather than fitting the work to a preset length so that you can deliver work as soon as possible. I’m not sure I like this though as you lose the sense of rhythm in terms of development as iterations would be constantly changing in size. It’s something worth considering though, but for now I’m sold on the idea of branching per feature which is the topic of my next post, in which I’ll try to cover problems with Continuous Integration, multiple

environments and merging.

Colin Grossman


Request a Demo

© 2006 - 2019. All Rights Reserved.