I have been thinking about batch sizes lately and will sum up my thoughts in this post.

Waterfall
In traditional waterfall methodology all functionality is delivered in one big bang batch. The shortcomings of this method is well known and includes complex and expensive change management, an extensive integration phase, poor customer involvement, etc.

Iterative/RUP
In iterative methods, such as spiral models, the functionality is delivered in several batches. The projects using RUP that I have experienced often have quite large iterations fixed both in time and in scope, which everyone except managers knows is impossible. The result is that the iteration is prolonged, which in practice means fixed scope, variable time. Due to the large process overhead in RUP, projects tend to choose fairly large iterations, which means the problems from the waterfall method is still in play.

Agile timebox/Scrum
Agile methods like Scrum are also iterative, but Scrum firmly suggests to have short time boxed iterations, which in practice means variable scope, fixed time. Because of the short iterations the planning horizon is also short and predictable, not making it a big problem with variable scope. I think the agile methods are a natural step to finally get away from the drawbacks of traditional development. They fulfill a need.

Lean/pipeline
According to Lean principles the ideal batch size is 1 (feature), which gives us a pipeline. If we manage the pipeline and have batches (features) of similar size we get a very efficient system low in waste. This makes timeboxing not applicable, since you deliver one feature at a time (fixed scope). Actually timeboxing is waste because you work up a stock of non-delivered value, which is waste. Optimally you should deliver as soon as it is ready. This is actually confirmed by the fact that many teams are moving from the original 4 week sprints to 2 week sprints.

The agile methods of today, with shorter iterations and smaller batches, is a natural and necessary step to get away from the heavy traditional development methods, but I’m convinced that future agile processes will fully implement a pipline with a minimum batch size. If no one does I will do it myself. I do have some ideas for implementing the pipeline with kanban buffers, but that’s a different story (and maybe a future post).

Uncategorized | 2 Comments »

I was hired as a Business Analyst in a couple of assignments a few years back. It was a good experience and I learnt a lot about the business processes of the customer, but it struck me how bad we actually performed.

A really skilled team of business developers/customer representatives were located on-site, literally besides the development team. In spite of this really great opportunity, they placed a team of BAs in between, effectively blocking the potential pipeline of feature development.

It was a really complex business scenario were we would have been helped by an agile and empirical process, getting continuous feedback. Instead the BAs were creating heavy requirements documentation upfront together with the customers. We were struggling with capturing the full requirements specifications and signing them off before handing them over to the development team.

Imagine a document driven process were all the experts are sitting in the same room! Talk about waste!

What I would like to suggest to this organisation is to get rid of the BA role to save a lot of waste, introduce an agile methodology such as Scrum and to release small releases often to get valuable feedback in the empirical process. I would also recommend to write the requirements in lighter stories instead of heavier use cases and foremost of all pair the customer with the developers instead of putting a BA filter in between. That would increase productivity for sure.

Maybe it is a good idea to let the BA and the tester roles converge, like Dave Nicolette is suggesting in Collapsing the roles of tester and business analyst? It’s not a bad idea. Testers need to know the business and BAs need to know how things are tested. Especially with the movement towards test driven development and test driven requirements (automated acceptance testing).

Uncategorized | 2 Comments »

After 6 really eventful years at Softhouse I emptied my locker, returned my stuff and said goodbye to all my friends at Softhouse today.

Tomorrow is the first day of the rest of my life! And I’m really looking forward to it. I’m embracing change!

Uncategorized | No Comments »

I did a “Lean and Agile” presentation for the management team at my present assignment and the minute after I finished, Erik entered the room starting to prepare a presentation of his own. It turns out we are working for the same customer, only he’s working a level above me as an agile mentor for top management.

It was interesting to meet Erik and hear his views on introducing agile and lean into an enterprise. Erik is an agile profile and independent consultant from southern Sweden. He is a strong XP supporter since many years.

Uncategorized | 1 Comment »