Elephants are not giraffes and user stories are not requirements. They share some traits and you may find them in the same context, but that does not make them the same. Despite that, many believe that user stories are the new requirements because there has to be requirements for a project, right? I give that a double “no”, they are not requirements and that is not anything we really need. User stories are about being able to explore options and seize opportunities. Requirements are about deciding up front and sticking with that.

Continue reading

Daniel and Martin have been in the same team since the beginning of summer and they’ve been collaborating in an unconventional way. Yassal interviews them to understand what’s been going on.

You’ve been successfully using mob programming with your team at Expressen for the past 6 months. How did you get started?

Daniel: The project started without any tech solutions in mind. We decided as a team that mob programming was a good way to figure out what tech stack to use. We had no backlog, but we sort of knew what we needed to do

Martin: I remember proposing this as the best way to do discovery work from a tech perspective. We didn’t know what language or tech platform we were aiming for, and this way we would learn more quickly as a team and could come to a decision. 

So, what is mob programming anyway?

Daniel: I don’t really care about the formal definition, to me it’s group programming rather than pair programming. One person is at the keyboard and the others act as support, coming up with suggestions, or researching potential solutions. This helps the whole team stay on the same page, and makes sure that we’re all learning at the same pace.

Continue reading

Hej kära läsare! Mitt namn är Martin och jag är en “process-aholic”. Jag har sett processer (eller avsaknaden av dem) överallt sedan jag var barn. Jag har sett en del människor som gör saker på “fel” sätt och en del människor som gör saker på “rätt” sätt. På universitetet lärde jag mig dock att inte ens när det kommer till processer är livet svart eller vitt, men jag förstod aldrig hur jag skulle kunna särskilja en “bättre” processen från en “sämre”. 11 år senare när jag fann Scrum blev jag glad över att hitta en process med inbyggd processförbättring. Jag kunde äntligen experimentera och sedan utvärdera om det hela blev bättre eller sämre. När jag insåg att de flesta team körde Scrum utan denna del, bestämde jag mig för att försöka lära världen ämnet kontinuerlig förbättring. Detta är ett sådant försök, men det var nog uppenbart…

Vad jag har saknat när jag predikat om tillbakablickar/retrospektiv är tydliga och konsekventa mål. Att nyttja de fantastiska grundvärden som agila metoder vilar på, såsom Extreme Programmings kommunikation, återkoppling, enkelhet och mod (inklusive respekt från version 2) och Scrums öppenhet, engagemang, fokus, etc, har hjälpt mig att sikta bättre på kort sikt. Men det var inte förrän jag lärde mig om två specifika (och överlappande) mognadsmodeller, en via Torbjörn Gyllebring och en via min kollega Fredrik Lingren (tack så mycket till er båda!) som jag förstod hur jag skulle kunna tillämpa en mer fokuserad strategi för ständiga förbättringar. Detta är min strategi:

Continue reading

We have just released our short comic as a poster, free to download and print! Jennie Discovers is a comic that tells a story about working Agile and Lean. It’s a story of product discovery, the journey from first idea to continuously releasing and updating a product or service. This book is written for product

The Pirate Ship is a workshop format that will help you grow amazing teams. It is “speed boat” on steroids. I have now been using it for a couple of years, and the time have come to share this useful and productive format.

I do a lot of workshops with teams. Very often the workshops are about the teams themselves. It can be anything from getting a newly started team up and running to helping a mature and stable team find new inspiration and challenges.

Continue reading

(translations: Turkish)

I wrote this article because of two observations:

1. Many organizations use a “project model” when they shouldn’t.
2. There is a lot of confusion and debate in the agile community about projects and project leadership.

I don’t claim to have “the answer”, but I’ve thought about this a lot and also experimented on my clients (don’t tell them… sshhhh). So, here is my take on project leadership in an agile context.

Oh, and by the way, this article is a Bait & Switch. I’m trying to get you to read What is an Agile Leader. You might save time by just skipping this and going there right away 🙂

Beware of “projects”

The word “project” is controversial in agile circles. Some companies use the “project model” as some kind of universal approach to organizing work, even for product development. However, a surprising number of projects fail, some dramatically. I see more and more people (especially within the software industry) conclude that the project model itself is the culprit, that it’s kind of like rigging the game for failure.

A “project” is traditionally defined as a temporary effort with a temporary group of people and a fixed budget. Product development, on the contrary, is usually a long term effort that doesn’t “end” with the first release – successful products start iterating way before the first release, and keep iterating and releasing long after. And teams work best if kept together over the long term, not formed and disbanded with each new project. Also, the traditional approach to planning and funding projects often leads us to big-bang waterfall-style execution, and hence a huge risk of failure because of the long and slow feedback loop. The project model just doesn’t seem to fit for product development.

Continue reading

Do you, a developer, have a feeling that the user stories your product owner is but a list of ideas prioritized on gut feeling only? That the relationship between them and their purpose are vague? Impact Mapping is an agile conversational tool by Gojko Adzic that may be primarily for product owners but hey, a developer needs a purpose too!

Continue reading

When refactoring legacy code, two problems seems to repeatedly occur. One is that the code is all tangled up with interdependencies and the other is that there is no specification of what the system is supposed to do.

Still we are asked to add features or fix problems without breaking anything. Everything in there should stay there.

Continue reading

Our goal at the Crisp hack summit last weekend was to migrate our 2 year old shopping app written in Meteor to the latest version and to learn about Google’s material design. Our old app was built as a way for us to learn Meteor. The structure is less than ideal, and as we learn new things we add them to the app, but don’t revisit old parts. So we followed Dan North’s experiment rewriting the app from scratch. We also decided to use Materialize for the UI. We wanted to rewrite the app in 2 days, keeping all the functionality we currently have, but at the same time adding the UI and usability improvements that we really need.

We ended up completing the rewrite in 9 days: 2 hack days and then a couple of hours each day for the next week. Not too bad for a brand new app, but surprisingly longer than we would have guessed. Both Meteor and Materialize are pretty simple to get started with, but adding Materialize to Meteor proved to be challenging. Here are some highlights!

Continue reading

How do you decide what to build next? Who comes up with the ideas? How do you decide in what order to implement them? How do you keep track of what you’re working on, and what you want to work on?

Here’s a behind the scenes look at how the Candy Crush Soda team comes up with ideas and decides what to build next!

Continue reading

Last night our Lego Mindstorms robot “Robit” somehow managed to win the Robot Sumo competition at the GOTO conference in Copenhagen! (here’s also an article in Mälarö Tidning)

Pretty frickin’ amazing considering that this was a big software development conference with lots of super-experienced developers competing, and our robot was mostly built by two kids – David and Jenny Kniberg (11yrs and 10yrs old) – the only kids at the conference.  Their robot didn’t just win once – it outmaneuvered and outwrestled the competing robots in every match!

Here’s the final, Robit to the left:

So how could a newbie team win the competition so decisively?

Continue reading

Designed as a 30-day action plan, this book will help you understand and implement Kanban – and start seeing results – in a month.

Analyze your current situation and define your goals and wider strategic aims, and begin developing a plan to help you and your team confidently work towards achieving them. Involve your team into driving cultural change, learn how to prioritize, and organize tasks and projects to efficiently use your time and resources.

Create your own value stream map to better understand your processes and identify improvement areas, and adapt and use the features, tips, and examples to overcome challenges you may face when implementing Kanban. Pick up this book and experience the full results of this vital Agile methodology-fast.

Who this book is written for

If you want to simplify your processes, improve collaboration, and manage projects successfully, this guide to Kanban is an essential companion. Continue reading

My new Kanban case book now ships from Amazon (as hardcover or in Kindle format). Learn how we: Improved the full value chain by using Enterprise Kanban. (Find out how we improved time to market and shifted focus from Sprints to Flow to deliver customer value in a traditional company.) Boosted engagement, teamwork, and flow in

Samarbete är en svår konst. De flesta organisationer har grava underskott på samarbete. Ännu saknas på många sätt förståelse för vilka mekanismer som driver och uppmuntrar samarbete. På Agila Sverige 2015 pratade jag om samarbetets mystik och gjorde några nedslag i en längre workshop om detta. Bland annat visar jag hur man kan spela ultimatumspelet i storpublik, hur apor reagerar på orättvisor och de fyra pelarna i samarbetets mekanik.

Continue reading

You know the saying “don’t shoot the messenger”? Well, that goes both ways – “don’t praise the messenger”. Well, OK, you can shoot or praise the messenger for the quality of the delivery – but not for the message content!

I’ve spent a few years working with Spotify and published a few things that have gained a surprizing amount of attention – especially the scaling agile article and spotify engineering culture video. This has come to be known as the “Spotify Model” in the agile world, although it wasn’t actually intended to be a generic framework or “model” at all. it’s just an example of how one company works. The reason why I shared this material is because my Spotify colleagues encouraged me to, and because, well, that’s what I do – help companies improve, by learning stuff and spreading knowledge.

Continue reading

Just back from Hookedfest – a conference for product people. It’s refreshing to see and discuss product development from a market and product perspective, in contrast to the “what can we build” perspective we all to often resort to as engineers. It was interesting to see other speakers (for example the Google guy) share similar experiences on

I år hade jag äran att i anslutning till Agila Sverige (2015) släppa Riv pyramiderna igen som riktig bok med den mycket bättre titeln Tillsammans – så skapar du flyt och egenmakt med agile och lean (tack till Joakim Holm för att du övertalade mig att negativa titlar är dåliga).  Den hemliga undertiteln tycker jag

My new book – “Real World Kanban” is now available. Here’s the plot in a nutshell: What happens when Kanban is used in real projects? Kanban has few rules, but an infinite number of strategies. What seems easy in theory can become tangled in practice. So there’s nothing like learning from real world cases. Learn how

The key to product success is to discover and deliver the right product for the right customers—and to do it at the right time. That doesn’t change when you move to an agile way of working. In fact, appropriately applying the agile mindset amplifies the imperative of eliciting and specifying the right requirements. The goal is to deliver the highest value product needs (requirements) in as short a time as possible.
Continue reading

Curious about how we developed Candy Crush Soda at King? Like any project we’ve had our challenges. We developed the game on a framework that had never been tested live, while programming in two languages simultaneously to support multiple operating systems. Adding to the challenge, we started working without a prototyped game idea, within an existing Saga format that comes with a long list of features that players are used to. The project, code-named Stritz, was born in the spring of 2013. We soft launched a year later, and hard launched in the fall of 2014. This is our story. 

My GraphWiki is now in a public beta 🙂 http://www.graphwiki.com/

At Crisp we often find ourselves discussing various, sometimes though topics, in really big groups. The way we govern ourselves (no managers) and the fact that we make big decisions by consensus or concent have driven a need for us to figure out how to have efficient and effective discussions in big groups. A couple

Yesterday me and Dave (11 yrs) spoke together for the first time! We did a public talk at Spotify about how to help kids learn to program. We’ve been experimenting a lot with that in my family (4 kids to experiment with… muahahaha), and wanted to share some learnings. Worked out better than we could have hoped, considering all the risky tech demos and live coding involved 🙂

Shared the stage with teacher Frida Monsén who talked about how to get this kind of stuff into schools. Thanks Helena Hjertén for organizing this, and Spotify for hosting & sponsoring. Here’s an article in Computer Sweden about this event and our little “mod club”.

Here are the slides! They are in Swedish though. Might do an English version of this talk some day 🙂

Continue reading

My amateur research has given me the insight that the three most important things for greater effectiveness and good quality are knowledge, knowledge and knowledge. Knowledge is best acquired through a dialog but a dialog is only efficient if it includes someone with knowledge. Unfortunately, there are situations when such a person is not around.

Some things are too small for the overhead of a user story, still they must be handled during the sprint effectively. I suggest a small taxonomy to classify them and also what to do with them.

Continue reading

What makes good code? Many things but whatever the qualities are, readability is a cornerstone.  If you can’t read the code, you can’t fix it. So how do you write readable code? I’ll give you my view but it’s like books, what I find enjoyable may be different from you.

Continue reading

Three months ago I stumbled upon a question which needed an anwer: Could Lego be used for business strategy development? I just had to go to London to find out the answer.

With a group of 12 I spent the full weekend.. building Lego! When was the last time I did that? (hint: some 30 years ago..). The real interesting part is of course the stories we tell about the models. Each time we do, the team moves closer towards a shared understanding and also generate new insights. That’s cool!

Below: Team members walking through our shared model.

Continue reading

I’ve spent years experimenting with how to teach kids programming, mostly using Scratch. But now we’ve found a new favorite: LearnToMod! Kids love Minecraft, and LearnToMod is entirely based on Minecraft, so it’s a perfect match!

We now do a Mod Club every Saturday evening, my older kids (9 & 11 years old) and some of their friends. It’s basically a programming school based on LearnToMod and Minecraft programming. Reeeeaaaally fun, the kids go wild (OK, me too)! AND they learn lots while doing it. To them it’s “magic powers”, not “programming skills”.

I made a 5 minute video showing how it works:

Continue reading

En av principerna från Lean Startup handlar om att kontinuerligt utvärdera det man tar fram för att veta att det man gör är rätt. Först bygger man något, sedan mäter man det och till sist utvärderar man mätningen för att förstå och lära sig – Build, Measure, Learn.

Vissa saker kan te sig enkla att mäta, andra omöjliga. Men till skillnad från att allt inte kan torktumlas, så kan allt mätas, till och med användarens upplevelse.

Continue reading