Karl Scotland – Using Agile to Deliver Value
Archive for April, 2009
Calendar and Download Updates
Apr 24th
#notkanban
Apr 9th
Boris Gloger has written a couple of posts on Kanban. While I know Boris is a great ScrumMaster, Coach and Trainer, his interpretation of kanban is wrong in my opinion – although I may have misinterpreted his interpretation! My immediate thoughts were too wide and varied for a comment on his blog, and I was at SPA2009 so didn’t have time for an immediate response, so I made a number of tweets with the #notkanban hashtag. This post is to follow up those tweets.
Boris says, “We need to tell the development teams what they have to do and we need to make sure that all activities: specification, requirements engineering, development testing will be worked on in exactly the right order, sorry FLOW”. A kanban system does not prescribe a process (or the activities), but rather visualises the process in order to improve it.
Boris continues, “we need to make sure that all roles in the development team needs to know exactly when the owner of a role can do a piece of work. So they can really focus on their specialization.” He also says “This is definitely not SCRUM or the idea of working creatively together. It imposed specialization”. A kanban system does not insist on imposed and siloed specialisation with handovers, but rather recognises overlapping phases. This is actually closer to the Type C development style described in the New New Product Development Game than Scrum itself, which acknowledges Type C development as a primary source.
Next, Boris says “Development teams … do not need to think anymore. They do just need to work according to plan and we do not have any break in the deliver process anymore”. With a kanban system, teams do think. They should be continuously improving the process and value stream. As James Shore reminded us (on twitter), Jeffrey Liker said in The Toyota Way that “TPS experts get very impatient… [when people] focus on kanban… kanban is something you strive to get rid of, not to be proud of”.
Boris seems to think that kanban is a process when he says, “So we do have now a very clear focused PROCESS that works much better than all the Scrum Framework”. However, a kanban system is merely a tool to help visualise an existing process in order to improve it and enable work. It is not something which imposes a process and inhibits work.
Yet Boris also says, “So if we agree that it is a TOOL, that means CARD than we can not explain a way of development as KANBAN”. So yes, a kanban system is a tool, but it is not just having a taskboard with cards, but should also strive to limit work-in-progress in order to improve throughput and cycle time (via pull).
Boris also says, “The terrible danger of this approach is that we put the the thinking about the features before the development”. A kanban system is actually designed to achieve the opposite and not overly invest in features before development as this creates work-in-progress.
Finally, Boris says, “Why do we always look into processess of the manufacture world. Why does nobody tries to see the value of the work-processes that works in companies like PIXAR or IDEO. These are the companies in which creativity and coolness lifes”. A kanban system does not exclude creativity. The team is responsible for the process and the workflow and is empowered to inspect and adapt the system in whatever way it wants in order to maximise the value that it generates.
If anyone (especially Boris) wants to discuss these points (and others) more, then please join the kanbandev list. That’s where I and others are trying to find better ways of using and describing kanban systems for software development.
SPA 2009 Highlights
Apr 9th
This week I was at SPA2009. Possibly one of the best conferences I’ve been to recently. Diverse people with lots of great ideas. There are my highlights.
Coaching Self Organising Teams
This was an excellent session but Joseph Pelrine, full of useful and interesting ideas I hadn’t come across before.
- Behaviour is a function of a Person and their Environment. Thus while we can’t change a person, we can change their environment.
- Thoughts on the strengths and weaknesses of the popular Forming, Storming, Norming, Performing model
- An alternative cooking based model: Solidifying, Congealing, Stagnating, Cooking, Burning
- Understanding Flow, in terms of balancing skills and challenges
- The Cynefin ABIDE model: Attractors, Boundaries, Identities, Diversity, Environment
- Social Networking theory
In particular, the ideas around Flow (“the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity”) resonated with me. While this is different from the MMF based Flow of Value I tend to talk about, I did find some interesting other parallels for thinking about kanban systems. A topic for a future blog post.
Estimation Fallacy
This was a great goldfish bowl discussion around the value of estimation. A recurring theme was trust. Should we spend our time building trust so that we can rely less on estimation, or should we spend our time getting better estimates because we can’t achieve trust? The output of the session can be found here.
Automated Ajax Testing
This was run by a couple of guys from Caplin, who have an extremely Ajax based Rich Internet Application. They presented their experiences and learning from using Selenium as their automated testing tool. Their conclusions were that, while Selenium isn’t perfect, when used with its Custom Locator functionality, and a UCD/DSL approach to structuring tests, it can be extremely valuable. A good example of a positive, art-of-the-possible approach to automated acceptance testing.
The session also introduced me to WebDriver, which looks like it could have potential as a new emerging automated web testing tool.
Complex Adaptive Systems
Jurgen Apello ran a thought provoking session on “What’s next for Agilists”? He based his assertions on learning from Complex Adaptive Systems (CAS), so I found it a useful recap of those ideas. It also generated lots of discussion about whether Agile has already applied CAS ideas, whether there are new things we can learn, or whether the ideas don’t apply at all. The slides can be found on Slideshare.
Haskell
Probably the most popular topic at the conference was functional programming, and in particular Haskell. One keynote, two scheduled sessions, and at least three BOFs. I went to a workshop on TDD and Haskell, and we looked at an approach to testing a Java application, via the Slim framework using Haskell and Model Based Testing. While I didn’t fully understand all the Haskell concepts, and I’m probably not going to start using the approach on a day to day basis, it was hugely eye opening as a different way of approaching a problem. Another example of smart people being creative and practicing the art-of-the-possible.
Lean & Kanban
As well as running my Kanban, Flow and Cadence tutorial, I was asked to help lead a Lean & Kanban BOF which had a really good turnout. We had some interesting discussion and it was nice to see some interest in looking at being successful from a different perspective.
XTC
Finally, there as a special evening event with the Extreme Tuesday Club which involved a panel discussion with some of original XTC crowd. The main point of debate was around how optimistic people were about the future of Agile. Personally, I think there are enough new ideas emerging (e.g. kanban got a mention) and enough people doing great things (e.g. the Selenium and Haskell sessions above) to be optimistic.
