Tag Archives: lean

Culture > Process (Paris Scrum Gathering keynote)

Posted on by

Here are the slides for my keynote “Culture > Process” at the Paris Scrum Gathering. Amazing level of enthusiasm in the room, seems like this kind of stuff was exacty what people were looking for. Happy to see the ideas take such strong hold!

read more »

Bokomslag till Riv pyramiderna igen

Posted on by

I dagarna fick jag bokomslaget till boken Riv pyramiderna igen – Agil HR ‘from the trenches’ jag håller på att skriva på Leanpub. Jag är otroligt nöjd med det. Omslaget är gjort av Lisa Zachrisson. Så här skriver hon om tankarna bakom formgivningen:

Jag tyckte att titeln skulle vara stor då det fungerar bra när det är en e-bok och omslaget ska exponeras på nätet (och även för jag tycker det är kul att jobba mycket med typografin!)

Jag började tänka på ordet pyramid och hur man kunde illustrera det. Jag tycker dock ofta att det blir lite ointressant att göra något som redan finns så tydligt i titeln, lite kaka på kaka.

Jag ville dock att det skulle kännas som man bryter ner eller frigör, därav bokstävernas utseende och himmeln bakom. Sen tänkte jag att det ändå handlar om struktur, därav det rutiga mattepappret.

Slides from Dare – “Visualization, what’s my brain got to do with it?”

Posted on by

Just got back from DARE conference in Belgium.  I don’t know how Maarten makes it happen, but I always leave with more ideas than I had when I came.

I ran a session on visualization – highlighting our brains limited capacity capture and record knowledge (and what to think of when using visualization).
An amazingly interesting subject. I also introduce five lenses to visual work which (you as coach) can choose to apply in the order the organization is capable of  learning from it Room was packed which always warms a presenters hart.

Enough talking, here are the slides!

Introducing Concepts

Posted on by

Let me introduce a tool I’ve found useful – Concepts.

Concepts  is a one page specification, in A3 format that represents a product idea of feature. It is enough to enable a prepared conversation with the engineers developing the product. Think of it as a “flexible minimum specification”.

Concept sketch

The idea

The concept owner is a person passionate about the idea, regardless of role, who works to realize the product idea all the way to happy client.

There is no handover.

Concepts

Concepts helps you

  • Treating post release challenges as part of normal design
  • Decrease friction between business and development by setting clear expectations of what should be prepared before entering into conversations with developers
  • Develop a minimum specification, flexible for your context
  • Increasing the value added time of your development team by training business people to arrived prepared with the right questions
  • Increase learning by completing the feedback loop all the way to customer use
  • Sharing the work load of a product owner onto a team
  • Lower waste:
    – preventing ideas with unclear value (hidden in big requirement documents) to enter solution design,
    – less rework  after release “bugs development should have foreseen”
    – avoiding heavy documentation in the early stages of product development when uncertainty is at it’s greatest

Companies have used concepts to:

  • Keep a single thread all the way through to working at client
  • Help product owners spend more time with real users
  • Solve product owner overload scenarios
  • Remove handovers

>> Download the full article

Here are some Concept section examples

(A shortlink: crisp.se/concepts)

Stop the line presentation at SmartBear MeetUI

Posted on by

Sisyphus, artistry, cult of quality, weaving, broken windows and all the other stuff you have to care about if you want to build high quality software. Here’s my speech on how we did it at Atex Polopoly, held at the SmartBear MeetUI user conference May 23 2013.

And here’s the slides:

Stop the line song

Posted on by

I ended my talk on the SoapUI user gathering MeetUI singing the stop the line song. Now it has ended up on youtube.

Here’s the text:

I keep a close watch on these tests of mine
I keep my Jenkins open all the time
I see a defect coming down the line
Becuse you’re mine, I stop the line

Stop the line as eBook

Posted on by

Here’s the eBook collecting my articles on building the quality in by stoping the line: Stop The Line – Why it’s crucial to include a human touch to your automated processes

Agilt ledarskap

Posted on by

Februarinumret av tidskriften VD-tidningen har agilt ledarskap som trendspaning. Tidskriften är riktad till VD:ar och styrelseledamöter med en upplaga på runt 10 000. Den kallar sig själv “Varje VD:s bibel”. Inför numret blev jag intervjuad om min syn på agilt ledarskap.

Eftersom texten är lite svår att komma åt bjuder jag på ett par citat från den, som inleds med ingressen:

Kunden bestämmer. Chefen är coach och medarbetaren har makten och ansvaret. Agilt ledarskap är en filosofi som föddes bland mjukvarutvecklare och som nu sprider sig till andra kunskapsintensiva branscher. Målet? Att öka kundvärdet.

read more »

Where is that Red ‘Stop’ Button in Your Development Process?

Posted on by

If you don’t dare to stop the line, continuous integration might be waste. Here is the second part of my three-part series on building the quality in on the SmartBear blog.

In the first post of this series, I wrote about Toyoda Sakichi, the founder of the Toyota industries, who invented a loom that would automatically stop when a thread broke in the 1920. He thereby also invented the concept of “stop-the-line” to build quality in.

Incremental compile with visual feedback is a small step toward the automaticity of the Sakichi loom. Beyond that, we still have these longish feedback cycles, be it manually running unit tests or waiting on the automatic build or system tests run by our continuous integration (CI) system.

Read the rest of the blog at SmartBear.

Stop the Line – Build Quality In with Incremental Compilation

Posted on by

We in the software industry are still far behind when it comes to automated quality checks. Toyoda Sakichi for example invented the automated loom with stop the line capability almost 100 years ago. I write more about that in my first blog in a three-part series on building the quality in on the SmartBear blog.

It may seem old school, but every now and then I’ll start pristine Emacs and hack away on a piece of Java. I mainly do this for small stuff, since starting or setting up Eclipse takes a little bit too long for such minor projects. Even so, I don’t do this as often as I used to.

Why? I guess you know the answer: Nowadays, even the thought of not having instant feedback on syntactical and semantical correctness makes me shudder. It’s like coding in the dark. Incremental compilation is one of those great innovations that have increased the quality of our work.

Read the rest of the blog at SmartBear.

Agile India slides

Posted on by

Agile India 2013 in Bangalore. Wow, what an awesome conference! I was amazed by the energy level of the participants, spent hours talking to people about all kinds of really interesting challenges. Based on the fully packed rooms and incredible feedback, it seems like my talks were exactly the kind of information people were looking for. Feels great to be able to help!

I also managed to squeeze in a site visit to a local development center, and discuss their agile implementation. Always fun to jump into trenches and see what is going on out there.

Anyway here are the slides from my presentations:

Thanks for a great time everyone!

Addressing critical in deliveries from subcontractors

Posted on by

In software, one of our favorite tool to deal with uncertainty is iterations. But is it always the better option?

The last week I’ve got the question two times of how to address critical in deliveries from subcontractors. For example: hardware, preparation of land, machinery, buildings or third party platform updates.  How can these be addressed? Do iterations hold the answer? Are there better options?

Let me introduce lean flow thinking and show how it can be used to improve the outcome of critical third party in deliveries in your projects.

Project with indelivery

read more »

How to build the Right Thing

Posted on by

The software industry is going through a shift of mindset.

Agile basically solved the problem of how to deliver software. Most any company that applies an agile method and mindset can get working software out the door. Now, the biggest waste in software development seems to be building the wrong product, or the wrong features.

“There is surely nothing quite so useless as doing with great efficiency that which should not be done at all” -Peter Drucker

This insight has given rise to methods and techniques such as Lean Startup, Impact Mapping, Story Mapping, Feature Injection, etc. But is there a common denominator, a set of underlying principles?

On Feb 11, Gojko Adzic organized a full-day meetup in London with people deeply engaged in this issue, people like Jeff Patton, Mary Poppendieck, Ingrid Domingues, Chris Matts and others who have been inventing and spreading techniques for dealing with the how-to-build-the-right-stuff issue.

It was a very inspiring day! We compared our different approaches and experiences, extracted the core principles, and (to our surprise) managed to condense it into this shared message:

Great results happen when:
1. People know why they are doing their work.
2. Organizations focus on outcomes and impacts rather than features.
3. Teams decide what to do next based on immediate and direct feedback from the use of their work.
4. Everyone cares.

There. So now just go do it! 🙂
Actually, if you want a more detailed description of each point see Gojko’s post.

Posts from the other participants:

Full participant list (in no particular order): Gojko Adzic, Mary Poppendieck, Gabrielle Benefield, Tom Poppendieck, Gordon Weir, Henrik Kniberg, Jeff Patton, Ingrid Domingues, Karl Scotland, Russ Miles, Christian Hassa, Dulce Goncalves, Aaron Sanders, Shadi Almviken, Chris Matts, Olaf Lewitz and Matthias Edinger.

read more »

Lean Mindset with Mary Poppendieck, Feb 7-8

Posted on by

On Feb 7-8 Tom & Mary Poppendieck will be in Stockholm, we are running a workshop called “Lean Mindset“. Mary and Tom are only here 1-2 times per year, so this a good opportunity!

The workshop emphasizes research, case studies and exercises. You will learn what a lean mindset is, how other companies have exposed and resolved paradoxes, and how this has helped them compete more effectively in today’s fast moving marketplace.

There are still a few spots left, more info and registration here.

Join us!

How Spotify builds products

Posted on by

Product development isn’t easy. In fact, most product development efforts fail, and the most common reason for failure is building the wrong product.

Spotify is a Swedish lean startup with an awesome track record of product delivery. The products are designed to be easy, personal, and fun. Even Metallica, long known as die-hard opponents to music streaming services, now say that Spotify is “by far the best streaming service” and are “stunned by the ease of it”.

Here’s the paradox though: Successful companies like Spotify only want to deliver products that people love. But they don’t know if people love it until they’ve delivered it. So how do they do it?

Check out the article “How Spotify Builds Products

read more »

Using continuous improvement in product development

Posted on by

If you prefer this as an article – you can download it here.

What is continuous improvement?

Continuous improvement always starts by observing previous results. That is our baseline for improvements forward on. We strive to improve steadily, a little at a time – 10% is great! But first step is always to accept the facts, regardless if we would have liked it to be better.  It is way too easy to sweep failed projects under the carpet rather than used as a baseline for improvements forward on. A mistake easily made is to base improvements on dream targets rather than previous results, it is hard to learn something from failure to meet those targets.

read more »

Lean from the Trenches @ Øredev

Posted on by

Here are the slides for my talk “Lean from the Trenches” at Øredev, Malmö. And here is the book/ebook, in case you want more details. There may also be some copies left at the conference bookstore.

Thanks for attending!

Agile Product Ownership in a nutshell

Posted on by

This is basically a 1 day product ownership course compressed into a 15 minute animated presentation.

Some call it “The best 15 minutes on the Internet” 🙂

There’s obviously more to product ownership than this, so see this is a high level summary.

Special thanks to Alistair Cockburn, Tom & Mary Poppendieck, Jeff Patton, Ron Jeffries, Jeff Sutherland, and Michael Dubakov for providing many of the models, metaphors, and ideas that I use in this presentation.

Translations: (see also the translation guide by Cédric Chevalerias)

Below is a full transcript in english. But I recommend watching the video instead of reading the transcript. The video is 100% visual, the transcript is 0% visual…

read more »

Slides from Lean & Kanban Central Europe 2012

Posted on by

Hi!

Just back from a great conference – LKCE 2012 –  and a great town – Vienna. A really cool thing was the illustrator who worked around the clock to visualize how he interpreted the difference presentations. He did a great job (see below).

Learning from charts LKCE 2012

What would you do – learning from charts

I challenge the audience to figure out “what should happen next” and then tell the story what really happened.

Improving flow from marketing to production

A case story of how we used kanban to tie together a full value stream across four functions. It might be interesting to notice that we used component teams + we don’t use product owners or project managers. While we are still learning,  I do think we have some interesting findings so far.

Lean from the Trenches keynote @ AgileEE, Kiev

Posted on by

Here are the slides for my keynote “Lean from the Trenches” at Agile Eastern Europe, Kiev. And here is the book/ebook, in case you want more details. Thanks for attending!

Everybody wants Change – but nobody likes to Be Changed

Posted on by

Here are the slides from my Ale2012 keynote: Everybody wants Change – but nobody likes to Be Changed.

Thanks for coming!

read more »

Light-weight problem solving template

Posted on by

Here’s my default approach to problem solving and organizational change. Basically a light-weight version of the A3 problem solving approach and Toyota Kata.

(BTW my keynote at ALE2012 next week is on a similar topic: “Everybody wants Change, but nobody likes to Be Changed”)

read more »

Lean from the Trenches @ Agile2012, Dallas

Posted on by

Here are the slides for my talk “Lean from the Trenches” at Agile2012. And here is the book/ebook, in case you want more details (unfortunately sold out in the conference bookstore). Thanks for attending!

R3 – den agila formeln

Posted on by

För ett halvt decennium sedan när jag skulle börja som utvecklingschef på Polopoly kände jag att jag behövde ett verktyg som hjälpte mig att sammanfatta andemeningen och de praktiska konsekvenserna av Agile, Scrum, XP och Lean. Var och en av dessa innehåller en rad – i viss mån överlappande – begrep, som är tydliga och om man kan dem inte så svåra att förklara – om man har många timmar på sig. Men hur minns man hela denna komplexa väv? Hur kan man uttrycka den enkelt, snabbt och koncist?

read more »

Self-organizing a 50 person party

Posted on by

Sunshine. Over 35 adults and 15 kids milling about, playing and socializing. Some down by the beach eating snacks and windsurfing. Work going on in the background: Pototoes being boiled, tables being set, drinks brought out, BBQ lit. Nobody is giving orders, things are just happening. Looks rather chaotic.

But then at 16:30, precisely on schedule, everything miraculously comes together!

Here’s an article about How to self-organize a 50 person party using agile techniques such as story-papping, taskboards, and pair-based self-organization 🙂

Slides from SDC2012 – Modern product development principles

Posted on by

Speaking at sdc logo  Just finished my session at SDC 2012 where I’m arguing for less hierarchy and economically aligned decision rules that  enables local teams to do tradeoffs.  Mary Poppendieck commented it as “traditional product management”.  Maybe that’s where we are heading 🙂

Anyway, here are the slides

Make it possible; change your statement into a question

Posted on by

Not long ago I met with a manager who during a discussion ruled out the possibility of success of a solution. I was a bit surprised and afterwards asked why that was not doable. It turned out one of the reasons was the managers fear the team would kick off with unrealistic expectations and leave  disappointed. I pointed out that we won’t ever get there unless we try.

There is an easy way of getting both: change your statement into a question. This will trigger an intellectual challenge and proof that people have a viable idea. In short: It enables more options.

Turn:
“It can’t be done” – into – “why is that hard”?

The solutions we have are only limited by the questions we are asking.

Tokyo Scrum Gathering keynote: Everybody wants Change, but nobody likes to Be Changed

Posted on by

Here are the slides for my Tokyo Scrum Gathering keynote “Everybody wants Change, but nobody likes to be changed“. Thanks for attending!

Sample slides:

Slides from Devcon11

Posted on by

Hi!

Devcon11

Just back from Devcon11 where I presented on techniques to improve flow.
There is plenty to say here so had to limit the material in some way. Hope to come back to this subject again in the future.

Anyway, here are the slides

How you know you are a Lean organisation

Posted on by

You can embrace lean in different ways. You can make use of Lean tools, you can attend lean courses and you can embrace Lean values  (Toyota production system “TPS”  to be correct).

But how do you know you are a Lean organisation?

  1. You define value from the eyes of the end customer
  2. You have a value stream/process to deliver this
  3. Management is continuously decreasing the Lead time across that value stream

read more »