Tag Archives: lean

Plan The Work But Don’t Work The Plan

I tweeted yesterday something that I had overheard to which a friend of mine, Toby then responded. As Toby then went on to suggest, the five tweets that I responded back with were a great analogy for why batching should be avoided (it had nothing to do with the 140 character limit, it was intentional, honestly.)

I thought that a blog post would allow me to better justify why I tweeted what I had overheard. My primary concern with the statement that was made is that in my opinion, batching all the requested items together to avoid somebody having to rework a plan multiple times slows down the delivery of the highest priority item the effect of which is to deliver value back to the person(s) that requested the work later.

Tying the team up on a larger bodies of work has further affects though. Firstly I think it means that it is less likely that a shorter feedback loop would exist which in turn, would mean that it would be easier for both the team and the person(s) requesting the work to not consider the smallest piece of functionality that could be delivered to meet the requirement. It starves the person responsible for prioritising the work of options to change, it asks for a commitment to deliver all requested items well in advance of their actual start date. Lean and Real Options would suggest deferring your commitment to the last responsible moment and as the InfoQ article I link to, I think this is at the core of being agile.

Working in very small batches isn’t without complication though; the concerns that I am suggesting in the above statements are born out of a bias towards a project based delivery mentality, the alternate to which is a product based one. In the environments that I have worked within it has always been difficult to group products in a meaningful way which in my experience has often lead to product owner groups all of whom need to compete to get their work done which has often ended up leading to frustration. From an engineering perspective, working in smaller increments also increases the need for two things: automated test suites that provide early visibility of breaking changes and also remove the strain on those people that fulfil a testing role in respect of doing the need to do full regression testing. Secondly, an automated release process is needed so that time spent doing releases is reduced.

I should be clear in all of this that I am not suggesting that planning does not add value. The value it brings though is in support of the actual delivery of the requested work. It’s biggest benefit is from a communication perspective and in that respect, it should be something that is recognised as being constantly out of date and therefore that it has a cost associated with it in keeping it up to date.

I mentioned flow specifically in one of my responses and that is point is worthy of expansion. If you imagine a magnet being passed above a bed of iron filings, a weak magnet would have less of an affect on the filings than a magnet with a stronger field would. Similarly small features individually passing through a team’s pipeline have less probability of causing a disruption. In relation to batching, Little’s Law suggests that the more items in a pipeline at any given time has the net effect of slowing (or to use the analogy, disrupting) the other items also in that pipeline. Finally, when you focus on individual features it makes it much easier in my opinion to understand where the bottlenecks are in your system Having the knowledge and then understanding why they exist is the first step in being able to focus efforts on  setting your pipeline up to work as effectively as possible with those bottlenecks.

    Advertisements
    Tagged , , , , , , , ,

    One Piece Flow, One Piece At a Time

    There’s been a lot of interesting conversation regarding the use of Kanban / Continuous Flow Development models and it’s something that I see a great deal of benefit in. I find myself struggling to understand whether it would be possible to start a team that hasn’t really used a process of any description before out with something like Kanban and for them to reap the benefits that people are discussing.

    I think the reason I’m struggling a little is that I’ve read nothing that would suggest that Kanban in particular is teaching a team the principles behind the practices and whilst I’m sure that some would disagree, from what I’ve read there isn’t too much focus in that area and given Kanban’s relative infancy, there’s little to speak of about the practices either. For example, whilst I’m sure most could easily see how something like Kanban allows a team to Eliminate Waste, might they miss the fact that the process of mapping your Value Stream allows you to See the Whole (i.e. that your kanban should represent all stages in the life cycle of a feature request)?

    At the moment and perhaps given my current circumstance, I feel a lot more comfortable that using a vanilla Scrum implementation will help the teams here at least move towards understanding the principles behind Lean so that we would then be positioned at a later date to implement a flow based model. It was Benjamin Mitchells tweet

    Good tips from @henrikkniberg on software processes: evolve the right process for your context, expand your toolkit and experiment!

    earlier that prompted me to make this post though I was also reminded of Matt Wynne and Rob Bowley’s presentation at XP Day Evolving from Scrum to Lean. Matt Wynne in particular once posted that for teams, Scrum is The Stabiliser Wheels on Your First Bike and that for organisations, it is like a bulldozer.

    Following a suggestion from Rob who attended a presentation by Jeff Sutherland at BT titled Shock Therapy and my later watching a video which is of very similar content, we’re running an experiment here with one of the teams and have got them using Scrum with 1 week iterations.

    Scrum is a collection of great tools, and the idea is that when used in this manner, they will help a team very quickly evolve to understand the problems they are facing (retrospectives come in very useful here) and the advantages of working in small batches to best be able to deliver to their definition of done every iteration. It’s easily understood (I accept that to some Kanban may also be easily understood) and some of the agile principles are baked in, it increases communication between the Product Owner(s) and the development team and its iterative nature means that the team is doing this over and over and in doing so, means that the practices and the principles that we’re talking about with them are there for them to see in action, time and time again. I should add that we’re not using Scrum alone, we’re using engineering practices such as TDD, refactoring any of the legacy code we come across and generally focussing in on quality throughout, we’re getting acceptance criteria up front which alone is proving worth the effort.

    If the ultimate goal is to move to One Piece Flow then, how specifically is our current use of Scrum helping us?

    As I suggest above, there are a number of benefits to Scrum but in respect of doing 1 week iterations, first and foremost, it’s giving both the team and their customers a much greater degree of visibility and better still, it’s happening sooner rather than later.

    From the team’s perspective, any of the issues that they are facing are immediately apparent, furthermore and small issues that we might not have caught in say a 2 or 3 week iteration cycle are raised in their importance. The team really need to remove any impediment that they come across as soon as they can to give them as much of a chance as possible of delivering the feature that they have committed to at the end of the iteration. Any problems downstream of the development work going on (e.g. testing, deployment) becomes much more apparent. Doing a retrospective at the end of each iteration and taking meaningful actions away is allowing them to tackle some of the more process based issues they face, they have started to realise too that rather than relying on key people to do repetitive small jobs that come in, they should all be capable of carrying out the task and that furthermore, there would be real advantage in writing a tool so that the job can be done by people outside of the team.

    From the business’ perspective, the team is creating a lot of data, quickly. This data includes the team’s velocity, the amount of time a feature that is requested takes to go from being requested to be being delivered and in that we’re also tracking how long that feature is in development.

    Whilst I mention above it’s worthy of note again that secondly, it’s helping the team form together as a successful unit, it’s forcing them to self organise. I’ve mentioned before Tuckman’s team development model (I’ve previously heard learning models such as Shu Ha Ri and the Dreyfus model referred to when discussing this advancement.)

    Of course, we’ve had a few problems outside of the team too, there are some people that feel that the amount of time that not only do the development team require of their customers in prioritisation sessions and in analysing requirements but that they themselves spend in meetings every week adds too much of an overhead. So far I’ve answered this by saying that the team have some clear goals to meet and once they have done so, they are free to move to whatever they deem appropriate, be that longer iterations or indeed a Continuous Flow Model. I’m also working to help people understand that software development is an inherently collaborative process and that in my opinion, you’ll never see the true efficiency gains to be had from a software team until you change the organisation to accomodate that, something that this post by James Shore alludes to.

    Anyway, I’m off to the eXtreme Tuesday Club’s inaugral Kanban Klub meeting tomorrow night so perhaps some of the things that I am struggling with about Kanban will be answered then. In the meantime, Scrum is seeing a little of a renaissance in my estimation as a tool to help development teams quickly mature in to ones that don’t just apply processes and don’t think to ask questions but ones that are questionning for themselves which process that they should be using.

    Tagged , , , ,