Agile, Change, Continuous Delivery, Kanban, Lean Product Development

RapidShop Principles

It started with an experiment:

“If we can establish autonomous cross-functional, co-located teams that are aligned with direction, then we will be able to rapidly build products and services with high quality that customers want.”

Our goals were to improve flexibility for the business, reduce lead times and improve quality of the software delivered. to reduce lead time from an average of 2 months to an average of 1 week. We thought breaking down the silos between business and IT could help us in this pursuit and together we defined why we were doing this and what (in terms of measurable goals) we wanted to achieve.  4 months later we’d managed to

  • reduce lead times from a best case of 2 months to an average of around 7 days
  • release software continously, sometimes as much as 4-5 times a day (with zero downtime)
  • break down silos between IT and business, creating a collaborative environment in a team consisting of both developers and business.

It has been a truly great experience, working closely together with some really awesome people. We started from scratch, both from a software and a process perspective, and gradually evolved our process. Our key principles  have been:

  • Simplicity
  • Emergence
  • Experimentation
  • Rapid feedback

Lets look at the principle of Simplicity first

Continuous Delivery, Kanban, Lean Product Development

Towards A Learning Enterprise – Run Experiments

(This is the second post on our journey toward building a Leaner IT-organization, “Towards a Leaner Enterprise – The Beginning” is the first)

For the last 4 months I’ve been leading an experiment at my current client, a big Telecom company in Norway. The experiment is related to finding better ways of working. In a previous post, “Towards a Leaner Enterprise – The Beginning“, I have described what trigged the need for a change:  All the teams followed the same release process (one big common), releasing software simultaneously in big batches approximately every sixth week. The process had a touch of waterfall in it:

  • some people were responsible for breaking business needs into user stories
  • The stories were allocated to teams responsible for coding.
  • The acceptance testing was then handed over to someone else
  • And finally the software was deployed by Ops

Needless to say this created some problems for the organisation (long lead times, lot of errors in production systems etc.) We thought we could do better. The challenge is to make other people also see the same problems. We decided to propose an experiment to test out a new way of working

Defining a Hypothesis
The advantage with defining something as an experiment is that is more easily accepted by the organization, the word seems to make it less dangerous for people who would otherwise feel threatened by change. Thus, we avoided some organisational friction and reduced the risk of being “shot down”.  We proposed the following hypothesis:

“If we get a skilled, crossfunctional autonomous team working together with Digital channels (business), then we think Digital channels can deliver new features to the web shop faster and with better quality. The result will be added gross sales.”

But it’s no point delivering faster if we deliver the wrong things. So we used a substantial amount of time defining a direction that was aligned with the company’s direction. To be able to verify or dispute our hypothesis, we defined some targets that we wanted to reach:

  • Reduce lead time from an average of 2 months to < 1 week
  • Increase conversion rate by 10 % – leading to a gross add of 16,7 Mill NOK per year
  • Increase gross add of 2700 customers per year

The length of the experiment was 4 months (February 1st – 31st of May) and the team were given some boundaries to operate within. The following picture shows how we defined what, why, measures and boundaries for the team (inspired by Stephen Bungay’s Art of Action)

Screen Shot 2015-06-27 at 19.51.53

How did we do

The cumulative flow diagram shows how we did in terms of delivering features to the users.


We reduced lead time from a best case of 2 months to an avaerage of around 7 days. Our historical data shows that 95 % of our stories can be delivered between 7.3 and 9.4 days. The conversion rate is up by almost 30 % as we speak. Top management has seen that colocated skilled developers that sit together with business people, deliver quality software with faster time to market than developers that follow a common and more command & control based delivery process. As a result of this, the organisation is establishing a new way of working, where autonomous cross-functional teams with a strong product focus are responsible for both building, shipping and run their own products and services. As Werner Vogels, Amazon CTO, once said:

You build it. You run it!

How we did it

That will be the topic of my next posts. As a teaser I can say that our method was based on emergence, simplicity and a goal to do continuous delivery. But more important than anything: Hire passionate and skilled people!

Conferences, Kanban, Uncategorized

Kanban Leadership Retreat 2012

This year’s Kanban Leadership Retreat, #klrat, was an inspiring event with lots of great food and drinks in warm and beautiful Mayrhofen, Austria. Long breaks, fantastic people, great conversations and an exciting un-conference program created a perfect arena for learning. As last year, it was arranged and organized by David J. Anderson & Associates. Thanks for putting this excellent event together!

Amongst the many interesting topics were:

Kanban Katas, Visualization, Systemic Flow, Lean Startup, Portfolio Kanban, Change and Crossing the Chasm.

I will elaborate on some of these in what follows….

Continue reading

Agile, Kanban

Kanban Training Class With David J. Anderson

On February 1-2 2012, David J. Anderson will host his official Kanban Traning Class in Oslo. The first course David held in Oslo, got excellent feedback from the 20 participants. David is constantly evolving his material so I’m pretty sure that the participants at this course will get insights into some material not yet written down anywhere.

You can find the course details here:

Kanban Training Class with David J. Anderson

Feel free to contact me if you have any questions about this upcoming course.

Agile, Kanban

Does It Matter What You Call It?

Imagine that the company you work for has decided that they want to be more agile. Great, right way to go. So they start a project to ease the transition. Not a bad idea really, make sure people use more or less the same terminology, help out with training and similar. To further ease the transition, management decides that all teams should use Scrum. Not a good idea!
With experience from both Scrum and Kanban, you know that it is not really about one method being better than the other. Rather, it is about choosing the right method for the environment you work in and being able to continuously improve.
Continue reading

Kanban, Play framework

Lean Web Development With Play Framework and Kanban

Late March this year I hosted David J Anderson’s first official Kanban Traning Class in Norway. Having David over to teach one of his classes was definitely both exiting and a great learning experience for me personally. I’ve been using Kanban for a while now and really come to appreciate the evolutionary way of pursuing continuous improvement and learning.

Now, if you’re going to arrange a course you need some way for people to register, so I decided to create a small web application for this purpose. I did not have much time and I had to do the work during evenings, after getting the kids to bed. In other words, I was in need for some rapid web development. If you want to deliver quickly I think the following is very important:

Continue reading