This year’s Kanban Leadership Retreat, #klrat, was an inspiring event with lots of great food and drinks in warm and beautiful Mayrhofen, Austria. Long breaks, fantastic people, great conversations and an exciting un-conference program created a perfect arena for learning. As last year, it was arranged and organized by David J. Anderson & Associates. Thanks for putting this excellent event together!
Amongst the many interesting topics were:
Kanban Katas, Visualization, Systemic Flow, Lean Startup, Portfolio Kanban, Change and Crossing the Chasm.
I will elaborate on some of these in what follows….
I’m proud to announce that David Anderson will visit Norway late March to hold his first official Kanban Training Class in Norway. The event will take place in Oslo on March 28-29 at Hotel Bristol
This intensive 2-day Kanban training class provides an introduction to Lean, Pull Systems and Kanban and will explain how established industrial engineering theory can apply to software development process. The training class is a great opportunity to learn how to do successful evolutionary change from the “Father of Kanban-style software development”
The class is limited to 20 participants. If your interested in learning Kanban from the best you can register here.
A couple of weeks ago I was discussing Kanban with one of the managers at the client I work for. He was curious about the method and wanted to learn more about it. Having talked about the power of making work visible and limiting work in progress, I argued that perhaps the single most important aspect of Kanban is its ability to drive evolutionary change: One small change will leave the way open for other changes. The response I got was that it sounded like too much of a sales pitch. He wanted to know if I had any experience from projects where this had happened. Fortunately I had…
Posted in Agile, Kanban
Tagged Agile, Kanban
Year 2000 marked the beginning of the first Galácticos era in Real Madrid. In an attempt to build the best fotball team in the world, President Florentino Perez´ambitious goal was to buy at least one new Galáctico each season. The Galacticos of Real Madrid could celebrate some initial successes, winning the Champions League in 2002. But the success would not continue. As more and more star player were brought to the spanish capital the performance of the team started declining, allowing Barcelona to overtake them as the No 1 club in Spain and Europe. The first Galácticos era ended in 2007.
What the leaders of Real Madrid failed to understand was that it takes more than world class players to produce a great team. The individuals must be able to work and function together as a team.
The same is true for any other team, software development teams included. Building a team takes time, and simply allocating the “best” people is a poor strategy.
Agile software development is not about whether you do Scrum, XP or Kanban. It is about finding a process that works in the environment you’re in. Finding this can be hard, and doing so certainly require reflection about what you are doing, how you’re doing it and why. One thing’s for sure, if you are doing something and it doesn’t work: Stop doing it!
I think writing functional tests in a given-when-then style manner is a great idea. Tests tend to be clearer and more precise when written this way. There are quite a few tools too choose from. Cucumber by Aslak Hellesøy seems to have a lot of momentum these days and is an acceptance testing framework definitely worth considering.
However, the customer I work with has been using Fitnesse for a number of years now, which means people are familiar with this framework. So going for the new Fitnesse Slim framework seemed like a step in the right direction.
The software industry has embraced agile methods. A rising number of teams is now trying to deliver value incrementally in small iterations. This is of course a good thing. Customers get new functionality more frequently out into the market, an increasingly important factor in a competitive global economy.
The innovators and early adopters of agile methodologies were able to deliver great results using agile methodologies like Scrum and XP. But these early adopters were software craftsmen, proud developers of well-crafted software with lots of enthusiasm in addition to good communication skills. These early agile teams would probably succeed using less agile methods than Scrum and XP. Now the agile train has really started rolling, the majority has “seen the light” and even the laggards are starting to think that this might be worth looking into. Should we be happy? Or is it time to get just a little bit worried?
Posted in Agile, Kanban
Tagged Agile, Kanban
I’ve been using EasyMock for 3 years now, and have been quite happy with the way it has helped me to test drive development. Sometimes though, I’ve felt that my tests have become hard to read. Hard to read tests is often a test smell and a sign that the code is poorly factored so I should be careful blaming this all on EasyMock. Seriously, EasyMock has been a good friend and I wasn’t really looking for a replacement. But then I stumbled across the Mockito mocking framework
I believe that running fitnesse from inside of eclipse is a good idea. When Fitnesse is using my eclipse classpath I can modify my code without having to restart fitnesse. This gives me nice, short cycles and is major efficiency boost. A good colleague of mine, Morten Udnæs, had created a small start up class for Fitnesse in Eclipse. But when upgrading to the latest stable release of fitnesse (20090709) I found that I had to modify this class a bit – Uncle Bob has done quite a few refactorings over the last couple of releases.
The vacation is over and a new project is just around the corner. As an iteration zero we have working on setting up the technical infrastructure and tried to carve out a test strategy for the development. In this project we really want to practice a test first strategy, not only for unit tests but also test driving the requirements. This means that before development of a feature can start, a set of acceptance tests should be written in a form that makes it executable. We’ve been using fitnesse (old style) for this for most of our previous projects. But it turns out that neither developers nor testers are particularty satisfied with the current solution. Developers thinks it is tedious and time consuming to develop and maintain tests investment. Testers too find it hard to use (for other reasons than developers, but that’s another story) and we find they often skip the regression tests suites because it is to hard to use. If it is hard to use then people will avoid it.
Posted in Agile, Test
Tagged Agile, Test