Silver Stripe Blog

Self Organizing Teams at GE/Durham

siddharta — Fri, 03 Jul 2009 07:35:30 +0000

I just came across this fascinating article on how teams are organized at GE’s Durham plant. This plant is used to manufacture GE’s high powered jet engines for long haul commercial flights. The surprise? Teams at this plant are completely self-organized. There are 170 people here, with a single plant manager (more like a facilitator than a supervisor).

It’s a long article. Here are some quotes.

(more…)

An Introduction to Kanban with Silver Catalyst

siddharta — Fri, 03 Jul 2009 03:11:40 +0000

This 15 minute video shows how to implement a Kanban process using Silver Catalyst. In the process, we’ll see various practices of Kanban illustrated such as:

How to customize the workflow to map to the value stream
How to track custom data (like class of service) for each work item
How to setup work in progress limits
How to pull work items through the value stream
How to block work items and stop the line
How to use card colour to identify work item type
How to track cycle time and lead time for each work item
How to use the throughput and work item breakdown reports and link it with a continuous improvement process

You’ll also see how Silver Catalyst can help with the four basic Kanban principles:

Pull value through the value stream
Limit work in progress
Make it visible
Establish a cadence

(more…)

What is story point estimation?

siddharta — Mon, 29 Jun 2009 10:50:14 +0000

This post is the first in a series of two posts. In this post, I’ll explain what story point estimation is about. In the next post, we’ll see why Agile teams prefer story point estimation over the traditional method of estimating in hours.

What are story points?

In simple terms, a story point is a measure of complexity. This is to differentiate it with hourly estimates, which are a measure of effort.

The second idea is that story points are a relative measure. That means we choose one user story and keep it as the reference and assign it a value of 1 point. We then measure every other story relative to this one. So if the second story is twice as complex, we give it a value of 2 points. Thrice as complex and it gets 3 points and so on. Go through the entire backlog this way.

Thats all there is to it!

The difference between complexity and effort
Lets take an example to highlight the difference between complexity and effort.

Assume I have a rock that weighs 10 Kg. This weight is a property of the rock itself. Now if I ask how long will it take to carry the rock over 100 meters. This depends on many factors: The weight of the rock, who is going to carry the rock, how strong they are, how fast they are and so on. The answer to the second question depends both on the rock, and the person doing the carrying.

In a similar way, complexity is a property of the story, whereas effort depends both on the story as well as the person implementing it.

Choose to be pragmatic, not dogmatic

siddharta — Sun, 21 Jun 2009 07:55:27 +0000

Jon Kern:

For me, I chose to be pragmatic, NOT dogmatic. I chose to use my brain to do what makes the most sense in every circumstance, not a blind allegiance to a process for process’ sake. If barging forward and doing “design and coding” works best for you and your team to flesh out ideas, go for it. Just be sure to go back in and “do the right things” once you commit to an approach that is going to stay in the code base.

Defining feature types in Silver Catalyst

siddharta — Sat, 20 Jun 2009 05:16:51 +0000

We released a new feature last week - the ability to define the type of each feature.

(more…)

Making prioritisation decisions with the “Iceberg List”

siddharta — Thu, 18 Jun 2009 18:01:33 +0000

Sometimes its pretty hard to prioritise. You can move features up and down the backlog, but you never really get a clear idea about the impact thats going to have. What does it mean if I put a feature at position 10 instead of 8? Will it make a difference?

Usually not. Except for one case - When position 8 would fit the feature into capacity for the next iteration, but position 10 just misses out on the next iteration. In this case, it could be very important indeed!

As Mike Cohn says, more interesting than what is in the next iteration is the knowledge of what is likely to fall just outside.

It is with this idea that Alistair Cockburn’s Iceberg List has been implemented in Silver Catalyst.

That’s a rather fancy name for a pretty simple concept.

(more…)

What does a Work In Progress Limit mean?

siddharta — Wed, 17 Jun 2009 17:02:43 +0000

One of the goals of Agile is to limit the amount of work in process. This means that they strive to complete features to a “done” state before starting out on another feature. Agile teams minimize the work in progress by working in small batches in each iteration, and moving each feature through to completion by the end of the iteration. Thus, the work in progress never exceeds the size of the iteration backlog.

Some teams go a step further and limit the work in progress for each state in the workflow. For example, they might say that only two items can be in development at a time. If the queue is full, then the previous step in the workflow waits until a development slot is empty, at which point they pull a card from the previous stage. The idea behind doing this is to ensure that the input doesn’t exceed capacity, for example by pushing more stories into development than there is capacity to complete them.

We blogged about this kind of development way back in 2007. Read it here. For more details, do read the original article on Kanban in Action.

Setting WIP limits in Silver Catalyst

(more…)

Custom Taskboards in Silver Catalyst

siddharta — Thu, 11 Jun 2009 15:28:35 +0000

Here is a video showing how you can customize the columns on your Silver Catalyst taskboard. Now you can take your existing workflow and visualize it on the taskboard to identify flow and bottleneck issues.

Next up: Configuring work in progress limits to implement a pull flow Stay tuned.

(more…)

Silver Catalyst integration with Jira

siddharta — Mon, 01 Jun 2009 20:40:55 +0000

A new integration video is up. This one is with Jira. The workflow is similar to the Trac video that was uploaded earlier. Check it out below:
(more…)

Agile PM Tools: Per-user pricing considered harmful

siddharta — Mon, 01 Jun 2009 08:44:01 +0000

If you look around the agile project management tools landscape - and it is now a rather big landscape - you’ll notice something strikingly odd. What I’m talking about is the pricing model for most of these tools. Almost all the tools follow a per-user pricing model. In other words, if you add more users into the system, the cost goes up.

Why is this odd? Because the primary purpose of an agile or scrum project management tool is to increase visibility through the organisation. But per-user pricing actually does the opposite - it encourages companies to reduce the number of users who have accounts in the tool.

Companies know that they need to pay for every single person that gets added in. The natural response is to figure out the absolute minimum number of people who need to be involved in the tool. Everyone else gets information outside the tool through emails or meetings.

At the extreme end, you could have a situation where a few users proxy the entire team - one account for all stakeholders to use, one for all the testers and so on - all to reduce the number of live accounts in the system.

I understand the need for agile tool vendors to scale the pricing as usage increases. After all, we are an agile tool company too. But the per-user model is actively harmful for agile teams.

There are other ways to scale pricing.

A per-project pricing model is one of them. That’s what we decided to use for Silver Catalyst. We wanted a situation where teams could add users to the system without thinking twice about it

Another model is to charge extra for additional features. Many of the larger vendors do this too in the form of different editions aimed at small teams and large enterprises. We do this through hosted and on-site versions.

These and many other models are fine for agile teams. But per-user pricing can cause side effects that are especially bad for agile teams.