Monthly Archives: February 2010

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.


    A Lesson Learnt, It’s Not Just About Creating the Right Environment

    Following a discussion with members of one of the teams that I work with this week and given a little time to reflect, I think I’ve learnt an important lesson which will help me re-focus myself going forward.

    I learnt that it’s not about creating the right environment for a team as you perceive it to be; it’s about providing that team with the necessary support so that they can create the right environment for themselves.

    I’ve used “it’s” a couple of times in that statement so firstly let me quantify; I hold the belief that my role within a team is to help them be more effective and that in actual fact I work for the team as opposed to them working for me. Since joining my current company, amongst other things I have been striving to build an environment in which the development teams can work at a sustainable pace. One in which they are afforded the ability to strive towards creating better quality software. I want the people that work within the team to be able to have some fun and also to be able to take pride in the work they’re doing. One of the key things that I’ve been selling for example is that the teams should feel comfortable in their ability to be able to take a requirement from a stakeholder and wrap up in the associated body of work any refactoring they deem necessary.

    What I’ve realised since the conversation and following a subsequent one, is that all of that has been seen to be largely hollow talk and that the team in question actually felt that they didn’t have the support, particularly given their burgeoning pipeline of work. I found the last point particularly frustrating at the time, I couldn’t understand why the team members weren’t just going ahead and operating in the manner in which I thought that I was allowing them to. I was convinced that it really was simple; I’d said that they had the capacity within themselves as a team to operate in a certain way and yet their behaviour suggested otherwise. I got to a point in fact where I felt almost depressed that all of my efforts to create something that I believed would yield wonderful results hadn’t been realised and in that respect, I’d not done as well as I could.

    Importantly to me, what I’ve realised now is that I’m not spending enough time with the people doing the work, listening to them and understanding the way in which they are working and seeking opportunities to learn from them and ultimately, gaining a better understanding of how I can help them more.

    And what of my renewed focus? I’m not going to stop doing what I was doing before. I still think there’s a need to be doing that. It’s time to compliment that with actions as well though.