Category: SW dev

Case Study on Lean-Kanban in BBC

David Joyce and Dr Peter Middleton have studied the application of (what I call) Lean-Kanban in BBC.

From the abstract:

The evidence shows that over the 12-month period, lead time to deliver software improved by 37%, consistency of delivery rose by 47%, and defects reported by customers fell 24%.

The significance of this work is showing that the use of lean methods including visual management, team-based problem solving, smaller batch sizes, and statistical process control can improve software development.
….

The faster delivery with a focus on creating the highest value to the customer also reduced both technical and market risks.

There’s more info on David’s blog, and you can also read the case study itself prior to publication from there.

Update: The case study was published in 2012.

What’s In a Kanban Standup?

First and foremost:

Focus on work items, not people.

Then:

Finishing is more important than starting.

Practical tip: start to the right/ at the end of your board, and identify impediments to finishing tasks as you go upstream on the board.

Only two questions are really necessary in the actual standup if the team’s real process is reflected on the board:

 The team will be asked if the board accurately reflects what is being worked upon. The team will be asked if there is anything that is slowing down or stopping throughput. After these two questions are answered by the team, the stand-up is over.

(Karl Scotland via @dpjoyce.)

Update: a few more reading tips.

Agile Version Control

The goal is to enable you to be more agile, i.e., to improve your ability to change and adjust.

Here’s what I think:

Mainline and CI

Branches and merging
  • Beware of feature branches, and kill them as soon as you can if you do use them. (One tip: feature toggle)
  • Branches: Merge from mainline every day if you have them.
  • Good naming goes for build code and infrastructure, too, so I’d prefer branch names like mainline, release, featureA, fixB
  • Limit branches agressively – they represent more work in progress (and you want less work in progress) including risk of big merges
  • Agile version control for multiple teams
    Illustration from Henrik's article

    Merging: merge down, copy up – always accept stabilizing changes, never impose destabilizing changes.

Inspiration:

Martin Fowler: articles on continuous integration

Henrik Kniberg: Agile version control with multiple teams

Kanban – Core Concepts and Practices

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.

Update after “conversation” with @pawelbrodzinski:

Buy-in from management and whole organization is preferable, but team buy-in is enough and necessary, in my opinion.

I think it’s important to just get started, improving step by step, and team buy-in and the Core Concepts are enough to do that.

How to Get Started with Kanban, and Why

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

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):

Lightning Talk at Smidig 2010 on Agile Basics

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.

 

Agile Basics: Visualize More

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 better the more they visualize the work.

How can you visualize more to gain advantages like that?  Here’s a few examples:
  • Let workflow on task board be closer to reality
  • Show different types of work differently
  • Let a status screen display a virtual 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.
  • Show more policies like DoDs, increase transparency
  • Are you doing CI or continuous builds? Create alerts or alarms for failures, include status on status screens.
  • Show problems and impediments clearly
  • 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

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.

agile leopard http://www.flickr.com/photos/42429527@N03/5063150948/

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 increase your ability to adapt – 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.  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

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”…