ingvald

Kanban - Core Concepts and Practices

2011-05-09T19:10:29Z

Kanban Core Concepts

Visualize work; items, process/ flow, policies
Limit work-in-progress (WIP), but don't be too ambitious at first

Basic Kanban is a lightweight framework for change management.
Starting with the core concepts on top of your present process should meet little resistance, at least when coupled with focus on improving quality.

Btw, I talked at a lokal meetup earlier this year (slides here), mostly on the core concepts - why they work and how to start.

A few Kanban Practices

Flow; encourage, cultivate, transform towards
Classes of Service (CoS); visualize and track different types of work, with different demands on them
Gradually limit WIP to improve flow and to uncover your next improvement opportunity
Cadence; regular rythm of things like backlog replenishment and deployment, separate from development
Metrics; to manage flow over time
Pull; instead of mostly work with deadlines
Slack, swarming - doing it consciously

There's more, but this illustrates the relation between the core concepts and a set of recommended practices.

You're likely to start with a simple version of some practices, f.ex. the work types (CoS) critical items, work with deadlines, bugs. More practices can be utilized as your organization matures, and more sofisticated use of practices, like setting different target lead times for different CoS, f.ex. 50% of bugs should be fixed within a week.

(Re-posted from notes to self.)

Extracting a Personal Kanban from an Overgrown ToDo List

2011-05-05T09:46:21Z

Last week I looked at my overgrown todo list, and preparation for a demo at work was coming up, and I have a long trip to prepare for...

So I simply had to create a personal kanban on the cupboard behind me:

I used a form of priority filter, with a generic todo column to the left, then a "soon"/today column, then the usual doing and done columns.

Collaboration on the demo preparation led to tasks on the board, and I took the most important and urgent tasks from my todo list onto the board.

It worked really well to let tasks float up and to the right in the todo columns, kind of like bubbles. I got an immediate impression of relative urgency (more to the right) and relative importance (upwards), making it very easy to decide what the next task should be when I finished a task.

These spatial relationships were not by design, btw - at one point it just suddenly dawned on me what I had been doing subconsciously...

Also, there was no sharp column separators, and the status of tasks in the area between columns was a bit fuzzy, f.ex. "almost done" or "barely started". This made the WIP for the "doing" column a bit fuzzy, too, but my brain seemed to like this analog setup, and breaking the WIP limit was never a problem.

How to Get Started with Kanban, and Why

2011-02-08T18:09:05Z

Monday February 7 I talked about Kanban at Trondheim XP & Agile Meetup.

I think it went well, even if I made a few presenter mistakes, based on feedback and the great questions and discussions.

Here's the presentation with a few adjustments, like a few additional links for further reading.

How to Get Started with Kanban, and Why

Kanban at Trondheim XP & Agile Meetup, Feb. 7

2011-02-06T20:24:25Z

On Monday, February 7, I'm talking about Kanban at Trondheim XP & Agile Meetup.

It's something I'm passionate about, so I'm excited.

Topics include:

"Kanban 101", or how to get started with simple Kanban
Agile Basics, or why Kanban works
"Kanban 201", or what's next

After the meetup I'll make slides available here.

More information about the meetup (in Norwegian):

http://www.meetup.com/trondheim-smidig/events/15739689/

Lightning Talk at Smidig 2010 on Agile Basics

2011-01-30T17:57:57Z

Last fall I had a lightning talk at the Norwegian conference Smidig 2010.

I talked about an important topic: what really works and why, in other words, Agile Basics.

It went ok, I guess, at least considering it was my first time speaking at a conference. Next time I'll try to improve a couple of things:

1. I'll be less nervous... I managed to present what I had prepared calmly and clearly, but my nervousness prevented my passion for the topic from coming through.

2. I'll follow through on subtopics. F.ex. on visualization, I ended up mentioning the banal fact that a task board is an example of visualization, when I really wanted to say something about a team and it's context. F.ex. how a task board that's visible for everyone promotes a shared mental model between people both in the team and among the stakeholders, and therefore enables much more effective thinking and communication when developing software.

Anyway, if you're curious, you can take a look at the video of the talk (in Norwegian), or just the slides.

Smidig 2010: Agile Basics

Agile Basics: Visualize More

2010-12-14T16:18:25Z

If you visualize more you get more agile.

Tom Wujec had an excellent TED talk on 3 ways the brain creates meaning.

Use images to clarify ideas
Visual shapes, physical space, colors, motion help us create mental model, more understanding
The act of engaging, being interactive enriches mental model
Augment memory by creating persistent, evolving views

Let's say you have a task board for a software development team, either a physical one or a digital one shown on a screen as a dashboard. Let's say it's visible in an office so that everyone on and outside the team sees it several times a day.

People in and around the team gain a shared mental model, a shared understanding.
People interact with the board as things change, including upstream and downstream stakeholders. A visible task board creates more engaged stakeholders.
A task board is persistent and evolving, and becomes a new visual, domain-specific language of sorts, where the domain is the reality of the development team.
This language is a more abstract, high-level language, and enables much more effective thinking, communication, and collaboration.

A software development team communicate and collaborate much more effectively with a visible task board.

Do you use a virtual task board? Let a screen display the task board permanently.

Are you working in a traditional waterfall project? Regularly print the latest version of the project plan (and progress) and put it on the wall.

Are you using a CI server? Create alerts or alarms of some kind for failures.

Do you share status on sales, bugs, product upgrades, project progress, project backlog etc in monthly or weekly meetings? Make status visible for everyone at anytime via screen or paper.

Being Agile

2010-11-10T20:15:46Z

Agility is about balance and speed, and being able to change and adapt to change.

It's not a binary state, something you are or not, but a question of degree. You, or your team or company, are more or less agile.

From the dictionary:

- ability to move with quick easy grace

- having an adaptable character

- synonyms: light-footed, nimble

- related words: flexible, limber, dexterous

- near antonyms: inflexible, stiff

In my opinion, being agile is not the same as using a specific method, tool, or process, or following a specific philosophy.

Agile does not equal Scrum, even if Scrum is an agile process.

Agile software development is not defined by the agile manifesto, even if I agree with most of it.

Getting more agile "simply" means to inspect more and be more able to adapt - or getting real feedback more often, and improving your ability to change and adjust.

Enterprise agility is the ability to respond quickly to unfolding events or opportunities, according to David Anderson in the webinar Scaling Agile in the Enterprise with Kanban. Getting more agile in the enterprise involves, among other things, increasing trust and minimizing resistance to change (i.e., improvements).

(This blogpost is subject to updates...)

JavaScript Unit Testing with Hudson and JasmineBDD

2010-10-18T18:29:14Z

Ingredients:

JasmineBDD, a JavaScript BDD/ TDD framework
The JUnitXmlReporter from Jasmine Reporters
Envjs (embedded with the Jasmine Reporters download)
~~Hudson~~ Jenkins (continuous integration server) on a Linux slave

Recipe:

let Hudson execute a (Java) shell command
let Java run Envjs
let Envjs run a simple JavaScript which loads an HTML file (your JasmineBDD test runner)

Voila!

The Java command:

java -cp lib/envjs/js.jar:lib/envjs/jline.jar org.mozilla.javascript.tools.shell.Main -opt -1 -f lib/envjs/envjs.bootstrap.js -f test.js

(The libs and the bootstrap file came with Envjs in the Jasmine Reporters download.)

The test.js content:
window.location = 'SpecRunner.html';
(I.e., opening the JasmineBDD spec runner.)

Simple Unit Testing Only

So far, this only works for simple unit testing for me. F.ex., it won't play nice with prototype (which is really integration testing, but still).

It's probably got something to do with Envjs' limitations compared to a full web browser.

But hey, headless automatic JavaScript unit testing ain't bad :)

Update:
@ingesol got Hudson to run Jasmine using JsTestDriver and Jasmine JsTestDriver Adapter. (See guide to Hudson and JSTD.)

It's not headless - requires running JSTD server and browsers, but it will handle prototype et al.

Update 2:
Headless testing as described above is not only for simple unit testing - jQuery works fine, too. There's advantages to running a JsTestDriver server, especially catching browser quirks, but for much of the BDD/ TDD effect (testable code, design, executable requirements, etc) you can run headless testing continuously in Hudson without any "external help"...

Want to Try the Pomodoro Technique with Online Tools?

2010-09-10T16:37:40Z

The Pomodoro Technique is a timeboxing method where you can use a timer to help you focus on only one thing for a short period of time, typically 25 minutes.

You can also do this onscreen and online. A simple, interesting experiment is the Tomato Timer.

For me, pomodoro works better if I keep my goal visible, too. You could do this by using the following web-based tools:

Google Chrome - timer "platform"
Chrome extension: Frame two pages - to keep both goal and timer visible
NowDoThis.com - very simple todo-list, letting you see one goal at a time
Online Stopwatch or Tomato Timer as "the tomato"

Simple recipe:

Open NowDoThis in a tab in Chrome
Open Online Stopwatch or Tomato Timer in a new tab
click the Frame two pages extension button
set the next to-do item to focus on
set the timer
go!

Kanban is Agile Jazz

2010-06-09T04:14:30Z

XP2010 had a banquet including a jazz keynote by a couple of seasoned, Norwegian jazz musicians, Jon Pål Inderberg (sax, vocals, body percussion) and Bjørn Alterhaug (double bass). They performed for us, and talked about improvisation and things like structure, freedom, trust, etc. It was food for thought and a great experience.

I've seen other metaphors for software development, such as gardening, cleaning a kitchen, making a film, technical debt, construction, and martial arts. Last week I was inspired by the jazz keynote and by @agilemanager to think about musical performance as a metaphor.

Plan, Flexibility

What to play in a concert is decided in advance - for a classical concert well in advance, and in detail. A jazz band, however, often finalizes the playlist just before the concert, even modifying the playlist as the concert goes on.

The plan for the performance of a single jazz tune is often subject to variation and "planned uncertainty". For example, the band knows where an improvisation part starts, and knows on what cue to move to the next part, but they don't know in advance what happens in between or how long the part is going to be.

The adaptive nature of a jazz concert or a song enables an agile response to change. There is focus on flow towards delivering value to the customer (and each other), instead of doing a certain amount of ordered work. Circumstances can be taken into account, like the mood of the audience, interruptions, etc.

Errors, Learning

Mistakes will be made.

If you trust your fellow musicians and the structure permits it, you might even take greater risks, either gaining greater value or learning valuable lessons from failures.

From the jazz keynote: Embracing Errors as a Source of Learning

A successful jazz concert produces an amount of music that's never been played before, while a successfull classical concert should vary only in subtle interpretation details. F.ex., it was unusual for Miles Davis to practice with his band; he wanted to hear something new in each concert, and said to them that they were being paid to rehearse on stage.

Whatever type of music, a good musician spends time learning her craft, both practicing by themself and doing music with others.

Collaboration, WIP Limits

Have you noticed that during a drum improvisation the rest of the band dials back, sometimes all the way back? Some instruments playing less makes more room for others, there's imitation and learning from each other, and there's collaboration and conversation going on.

Sometimes a composer (of any kind of music) or a jazz performer impose restrictions in order to foster creativity. Those limits can be rhythmical, tonal, or on any degree of freedom. (Cue "One No te Samba"...) Such limits increase throughput of ideas, and give more room for important information that the composer or musician might want to accentuate.

Instead of everybody doing "their own thing", a jazz musician can be quiet, listen, and then contribute to what the others are doing. Slack, i.e., doing nothing and listening, makes room for others and opens you up for creativity. You can be ready and agile, and then contribute where the song is going.

Kanban is Agile Jazz

Don't get me wrong: I love lots of classical music, and I think there's room for various agile tools in a software development toolbox.

Kanban is one of the most adaptive tools, however, with focus on flow, WIP limits, starting with the existing process and continuously improving step by step.

Quality First Drives Behavior

2010-03-11T20:42:18Z

If quality is first, it drives a certain set of behaviors. If market share is the goal, it drives a different set of behaviours...

Even as Toyota was catching up to No.1, their reputation was slipping...

(Emphasis mine)

The parable of Toyota may be that the tortoise became the hare. Over decades, Toyota built its reputation and market share in tiny increments through its renowned "continuous improvement" method. In the Toyota mantra, quality was always first, because it led to lower costs, which would eventually lead to higher market share. Eventually.

But in the '90s, Toyota set out to become the world's top auto company. Being the best and being the biggest created a tension that Toyota couldn't resolve, says MIT operations expert Steven Spear: "If quality is first, it drives a certain set of behaviors. If market share is the goal, it drives a different set of behaviors."
....
the "Toyota way" ... was diluted by the demands of production. "Even in the late '90s, people in Toyota would say, 'This is going to bite us in the ass,' " says Spear. "They just didn't know when."

Now they do. .... Toyota will fix its manufacturing problem. Restoring its reputation is going to take a lot longer.

Toyota's Flawed Focus on Quantity Over Quality - TIME

Lean: Development is not Manufacturing

2010-02-21T19:01:38Z

The Conclusions of lean manufacturing theories are not necessarily valid in the domain of (software) product development.

There's good reasons why it's so difficult to fix time, budget, and feature scope all at once in a software development project.

I've been listening to a talk by Don Reinertsen, and one of his points, although not the main point, is about variability: if you could reduce variability in the workflow by 10%, or you could reduce capacity utilization by 10%, by far you would prefer to reduce capacity utilization. That's where the economic payoff is.

The reason is that increased capacity utilization increases queue size and lead time exponentially. In other words, if you try to keep all your resources busy all the time, everything takes forever to finish. This goes for both manufacturing and development. Variability in workflow, however, is bad in manufacturing, but can't be avoided in product development, and might even be exploited.

So what else is different about development compared to manufacturing?

	Manufacturing	Development

Tasks are....	repetitive	non-repetitive
Tasks are...	predictable	unpredictable
Requirements are...	a constraint	a degree of freedom

Requirements are...	fixed	evolving
Cost of delay is...	homogeneous	non-homogeneous
Task durations are...	homogeneous	non-homogeneous

Variability is...	always waste	not always waste
Inventory is...	physical objects	information
Inventory is...	visible	invisible

Source:
A talk by Don Reinertsen,
Second Generation Lean Product Development: From Cargo Cult to Science

the purpose of education should be to make us more effective at life

2010-01-03T17:15:39Z

The time has come to stop quietly accepting the mistaken - yet popular - notion that education is primarly about getting jobs. The purpose of education is to make us better at using the collective knowledge of the human race in all areas of life. Yes, this includes our jobs, but it also includes raising our children, being informed citizens, managing our households, enjoying our leisure time, and just being good neighbors. Education should be to make us more effective at life. And as a powerful, new and poorly understood technology, computer education should be central to our learning experience
....
*Everyone* needs to learn the fundamentals [of how to use computer technology], right in the core curriculum along with math, science, reading and history.

Thoughts On ...: Teaching Magic

Jakob Nielsen, too, advocates teaching life-long computer skills, like search strategies and basic debugging.

agile adoption fails in a "fixed project situation"

2009-11-13T21:42:30Z

i saw an interesting article on infoq.com.

the term "fixed bid" is used in the article, but this article applies to another "fixed project situation", too, i.e., where the resources are fixed, and there's a specified, promised feature scope and a specified, promised delivery date.

(btw, it isn't really possible to control all of resources, delivery date, and scope and quality of features at the same time...)

In an agile software team you don't estimate your work till right before you begin. And you only estimate, in the case of Scrum, the next iterations work. So how do you know how long it will take? You don't. Furthermore, you really don't care. You'll continue to deliver functionality every iteration. As soon as product management and QA say you have a good enough product; it'll be released as a production version. You might have a guess, but until the team estimates it....you really don't know long it will take.
In a fixed bid situation....your estimation needs to take place up front.
....
In the 2^nd scenario, if I told the team, ... “we're using Scrum”: they'd estimate the work the next iteration. They would assume their estimates would be taken seriously and you'd give them time to complete the work as it unfolds regardless of whether their estimates fit your original project funding or not. That's only fair.

alternatively: they would assume they'd get the "time to complete the work with high quality regardless of whether their updated estimates fit your original project plan and delivery date or not".

[this leads to failure]....at managing the project and therefore.......”this agile thing doesn't work”.

The mistake was to assume the company's leadership ... was organizationally committed to ... agile principles. The mere fact that they are asking you to estimate the funding you'll need to complete the project tells us otherwise.

alternatively: the fact that they are asking you to commit to a fixed feature set and a fixed delivery date tells us otherwise.

this isn't bad, per se, it just isn't agile.

[the real problem]
Agile is often assumed ... to be a development process with no impact on budgeting. This is not the case.
Development teams assume leadership understands the implications of adopting agile at the budgetary level.
Developers and development teams often have zero visibility into budgeting so they are unaware of how their agile efforts are being accounted for in monetary terms. .... Likewise, management is often ignorant of development and specifically agile development practices. Agile adoption requires education to ease the clash and misunderstanding of these two worlds.

So what are some of the consequences of attempting to adopt agile practices on a fixed bid project...essentially laying an agile façade over the waterfall project?

....
Agile does away with the need for a project manager. .... organizing and managing the development effort are more centered on technical leadership, task and risk management. Timelines and budgets go out the door.
....
if you're in a non-agile situation ... then traditional PM practices are ... essential

....
Doing iteration planning in a fixed bid situation will almost certainly result in confusion, budget variances, and/or loss of functionality.
....
In fixed bid scenarios the question is not ... how much functionality the team is doing per time period. It really doesn't matter. They need to get all the functionality done ...

So using ... iterations in a fixed bid project sends the wrong signal to the team and your customers.

using iterations in a fixed project situation sends the wrong signal to the team.

you can still visualize workflow, f.ex. with kanban, reduce work in process, do stand up meetings (very short, impediments only), etc.

but in general you should try to get out of a fixed project situation before trying to go agile.

Edit: About that last part... I think there's a few basic, agile tools you can utilize whatever you're doing: visualize how you work; get faster feedback; limit the amount of work in progress.

multitasking

2009-10-14T16:00:17Z

try the multitasking game..

"Use this game to study the effects of multitasking on productivity and cycle times."
The Multitasking Maze, ProChain Solutions

(the point: multitasking is bad for you...)