Tag Archives: planning

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 , , , , , , , ,

    An Agile Adoption Pattern: Wax On, Wax Off

    I know I’ve said before that I don’t believe in an Agile Adoption initiative but humour me a little here…

    As I rode home dodging in and out of traffic a couple of weeks ago, with the saddle still as low as it would go from the last descent that we did on the bike ride over the Downs that weekend, I realised that it really can be the simple things in life that are most pleasing. It was good to be sat in the saddle cruising down the road on my bike. Then, at a point where I hopped off a kerb back in to a side road and the bag on my back swung round knocking me off balance I quickly realised that it was also the simple things that can catch you out.

    Some 5 weeks ago now I set the first team up to use the processes that I want the whole department to be using in time. We did 3 1 week iterations and have recently completed one that ran for 2 weeks. As I took the team through the initial estimation exercise I was reminded of the discussion that has been taking place about whether or not estimation is waste. I agree with all of the points made and I think that once a team has realised it’s velocity it can take the decision to move away from lengthy planning exercises and indeed estimation entirely. Why then have I suggested to them that they estimate their stories? I think they have to start somewhere, the team needs to understand their velocity and in understanding your velocity they can start to look at the things that are slowing them down. One of the things that I have previously said is that it’s important for a team to gain some momentum, to get an idea of their rhythm and this is one way that I think they can do that.

    At the same time though, I was advocating keeping the Product Manager away from the team, even when they were saying that this was a hinderance to them in their retrospectives. My reasoning for this was to enable them to get started without interruption. The piece of software that they’re working on was created as a Proof of Concept previously and we’re now looking to take it through to a Private Beta and so I thought the team had enough to go on for a short time without the additional “noise” generated by having a Product Manager involved, on the assumption that whilst the initial requirement was to get a production version of the software shipped once they started seeing the software during the demos, they would then start wanting additional features and distract the team. What has actually happened though is that we’ve ended up having to wait for a few decisions to be made which ultimately have slowed us down. This could have been avoided if I had got the Product Manager involved from the outset.

    Ultimately, you have to start somewhere, doing a regular planning meeting allows the Product Manager to give the team the priorities, the stand ups allow the team to plan on a daily basis and to remove any obstacles, the retrospective allows you to inspect and adapt and the demos allow the Product Manager to seethe result of what the team have been working on, it enables them to feel part of the process and to look at how they could extend the product.

    How do you introduce new processes to teams? Do the simple things, do them regularly and learn as you go. Wax on, Wax Off.

    Tagged , , , , , ,