Clinton Keith gave an insightful session around designing and configuration a Kanban system for leveled video game production.

Clinton described Scrum and Kanban coexisting peacefully. They used cross-functional Scrum teams to drive collaborative creative work at the outset of the project where team members would swarm stories. Aside from creating the game concept and playability, one of the outputs was to design and implement a Kanban system for producing game levels.

Game level construction requires different highly-specialized skillsets cannot help each other out – the audio engineer doesn’t know anything about graphic design. So Kanban is perfect. A system with fixed takt time was constructed and staffed appropriately to have a steady creation of game levels. Even the levels were broken up into zones to reduce batch size and improve flow.

Some team members continued to run 2 week sprints on solving challenging problems that came up during level construction and playability. For this environment it seems like Scrum and Kanban are both appropriate. This is a huge take-away for me – a better understanding of where Scrum makes sense and where Kanban makes sense.

Another interesting story was to Time Box Art to balance customer value with cost/time when developing artwork (see graph below). Artwork can go on very a very long time and it is difficult to define done. One solution to this is to create a timebox to focus work at the point of diminishing returns. Another benefit is that a timebox can drive creative energy. The example given was that for a high-speed car chase through Paris, you don’t need high-resolution buildings.

If you are interested in learning more, his book Agile Video Game Production is coming out May 2010. Video and slides of the session is on InfoQ.

Arlo Belshee and Jim Shore had an interesting pair presentation on titled “Single Piece Flow in Kanban” at LSSC10. A more accurate (although inflammatory) name for the talk is “Enough Kanban! Use XP for Single-piece flow”. It is worth mentioning that the context of the discussion is new product development.  Not sure about team size – seemed manageable. So this may be suitable for this context.

The basic arguement is that we should consider the flow of customer value. This is real flow. Moving Kanban cards representing tasks may be motion and not actual flow of value. The solution is not something new but something we already know: eXtremeProgramming (XP).

One challenge that Taiichi Ohno encountered decades ago when introducing Single Piece Flow at Toyota is that there is often resistance from specialists. They are more comfortable just knowing one piece of equipment.

The same challenge exists today when we ask developers, testers and domain experts to work together to deliver value. If your environment can work this way (and some can’t very easily) there can be a big cycle time and business value win.

What’s wrong with some Kanban implementations? Some have too many hand-offs and WIP due to queues. So, if you are using Kanban, this is something to watch out for.

Arlo and Jim describe the software work-cell as a collocated, cross-functional team that swarm work to minimize WIP and handoffs.

Gone is the release plan and the product backlog (see diagram). Instead a vision (which was a mindmap) drives the just-in-time generation of MMF (minimum marketable features) that are queued in the “on-deck” area. MMF is generalized to mean anything of business value. It could be a product feature. It could be a demo for a tradeshow.

For in-progress work, the notion of a Detective’s Blackboard was introduced as a dynamic unstructured area where tasks and task generators could be added and removed organically depending on the nature of the MMF. The idea is that tasks will grow as work gets started and then start to collapse as progress is made and new tasks stop appearing. (Maybe around when the MMF is ~2/3 complete.) In the example provided, the team was large enough to support 2 MMFs. The video and slides are available on InfoQ.

What looks like an earlier version of this is on Jim’s blog. See also Arlo’s video on Naked Planning. A video with session slides + Audio are on Jim’s blog.

Very cool stuff.

This fall, I had an opportunity to hear J.B. Rainsberger give an interesting, entertaining and educational talk – Introduction to Agile via Theory of Constraints.  (The same talk was given at Agile Tour Toronto, but my notes are based on an earlier talk at a client site.)

If we think about our software group as the system under study (photo – top left), then the primary measure of productivity is running tested features. (i.e. in production). The key question is how can we maximize our throughput while holding steady or minimizing inventory and operating expense. The theory of constraints is largely about the hunt for the bottleneck in the system. In J.B.’s opinion, learning is the biggest bottleneck. (I usually say communication is the bottleneck but this seems roughly equivalent).

How do we subordinate learning as a bottleneck? Some practices (photo – right) that help are working in pairs, sitting together, using estimates as budgets.

I can’t remember where this fit in, but J.B. had a great example of managing scope that he referred to as dimensional planning (photo – bottom right).  It involved looking at different versions of a car that could be delivered: Lada, Toyota, Lexus. The point is to do a quality job with whatever you do, but you may not do all the features to get a top of the line solution.

A big part of the talk was about using queuing theory to explain TDD, BDD (photo – left). J.B. has a write-up that covers part of the talk on his website. It is a nice explanation although it does stretch a bit thin from my understanding of queuing theory.

BTW, one of the best parts of the talk is watching J.B. at work with his tablet laptop which he uses like a gigantic whiteboard.  It’s a way more dynamic than slideware.

I just blogged about Daniel Pink’s case around intrinsic and extrinsic motivation.  This is a good lead-in for why SMART goals may be damaging to your organization.

SMART stands for:

• Specific
• Measurable
• Achievable
• Relevant
• Time-bound

It is common management practice to tie employee ratings and annual bonus to the achievement of SMART objectives.  In light of the impact extrinsic motivators have on creativity, we must ask if this is really a good idea.  Bonuses or job progression that are linked to SMART objectives are extrinsic motivators, so we are going to end up killing creativity.  Oops.

I will go one step farther, and say that SMART objectives may be directly damaging to the organization since it provides unaligned goals for different individuals.

In the best case these are competing. I am working towards my goal and you towards yours.  Why would I want to help you since that will help you succeed and take away from my effort.  This been seen repeatedly in Agile teams where requirements for individual achievement undermine the team’s ability to function.

In the worst case actually conflicting.  For example, my goal is contrary to what is best for the company.  At that point I face the hard choice to do what is right and what is good for me.  I have seen this situation lots of times.  Managers in the company are provided specific goals that are not 100% in alignment with overall objectives.  That’s really the root of the problem.  Unless you can guarantee that goals (SMART or otherwise) are 100% in alignment with company goals you will run into this problem.  And even if goals are in alignment when they are created, what invariably happens is that there is drift in alignment as new information arrives.  Lean avoids this problem by focusing everyone on the top level company goal: profitability.  Anything else and your company will be wasting effort.

The last thing I’d like to touch on is what it means to be achievable. In IT, there is a lot of uncertainty about delivering software.  I have seen too many projects badly harmed by goals that have board level visibility.  With Agile projects there is some hope: work can be prioritized.  With more traditional projects, the common result is rushed work that leads to low quality and let’s of extra work and delay due to rework.  It can lead to compromised design, bad architecture, and a project that takes much longer than expected.

So watch out for SMART goals – they may not be.

Here is the Visual Note (see earlier blog) of Alistair Cockburn’ Keynote talk at Agile 2009.  His main intent is that as Agile is becoming mainstream we need to look at some of the larger issues of software development such as large teams, distributed, etc.

Alistair followed on Last Years Key note speaker Bob Martin in talking about Craftsmanship as a key approach in considering all the different skills needed in software development.  He also spoke of developmental learning levels Shu-Ha-Ri that are key to a mentoring approach.  This is also very relevant for coaching.

I strongly encourage you to watch the video or check out the slides.