Artikelen over lean, lean software development en lean management


Craig Larman – Een Introductie tot Scrum op schaal

In deze lezing introduceert Craig Larman: Large Scale Scrum of LeSS



Not Just Code Monkeys

Martin Fowler talks about user stories and the why you cannot hide behind a Product Owner anymore.





Scott Hanselman – Scaling yourself

The next big thing after Scrum: Kanban? beware!

Just finished Henrik Kniberg’s Blogprint book about Scrum vs Kanban and after starting reading I immediately found something many software teams can relate to. It’s the trouble of planning iterations when important customers demand immediate attention. This is against the general principle of Scrum. In Scrum you, the team, commit to a set of work for a fixed set of time N. This is very unfortunate because big customer runs the risk of waiting N days before work on his/her item starts. An alternative is to plan overhead into each sprint but this can be unwanted if the disturbance is infrequent but large. Some teams really need constant re-planning.

Kanban suggests solving this problem using lean software development and by being a smaller scrum: Scrum without sprints essentially. Then there is a team or department-based visual representation of the different states of selected packets of work, just like a scrum board but with more columns (states). Then the trick is to limit for each column the amount of work in that state. This is essential to Kanban and logically called “limiting the Work In Progress”. When implemented this guarantees a more constant flow which is essential to predicting the lead time for an individual packet of work. Constant flow gives you better productivity and you can start estimating lead times to the packets of work, based on the items already done.

The second pillar is more difficult to implement: this is a cultural thing, going from a push based process to a pull based method. This is also essential when implementing scrum or other agile methodologies. What this means is empowering people or teams to pull from a central queue rather than pushing work into them until they say stop (which some people forget to do). Thing to take into account is the accountability. The implementation of this shift is a key step when moving towards a more agile development process.

An easy pitfall for Kanban is in its size: it’s very small. This seems to suggest that implementing it is done at the push of a button but it is not. Kanban shares this shortcoming with Scrum, also a very small process/ritual description. To make it work effectively you must borrow from the older and fatter process descriptions like XP (pair programming / review), RUP (UseCases) and even from scrum (daily stand-up, retrospective) to tune the process. What is Kanban then? It’s an essence of a software development process, not necessarily _the_ essence but a very good choice when you have a team that can re-plan on a daily basis and still be agile. Next for me is reading David J. Anderson’s book Kanban and learning from implementing it at a support and maintenance team. Kanban for software team is a very interesting development that I will keep researching!

Why is “Enterprise” software terrible?

The term “enterprise software” mostly covers software designed for use within large companies. This type of software often has many users and complex calculations for calculating pension statements or bank information. I have some experience with these types of systems. The quality of this type of software ranges from abominable to lean and mean. The quality is unfortunately most of the time more of the abominable type than the latter. Why is that? Are we an industry for the larger part completely incompetent? Are we not able to deliver a working piece of software that matches all functional and non-functional requirements? I do not think that this is the case. I’ve seen too many very good coders write utter junk because of time pressure.  I noticed while browsing the following post, in short: “The buyers are not the users”. I think this make perfect sense. Add to the fact that when buying software we try to spend as less as possible and you have the perfect recipe for a useless piece of software. The future? Much more reuse of common components using Open-Source Software. But were not there yet unfortunately.