I debug, refactor, and optimize IT companies. And jam alot too.
I debug, refactor, and optimize IT companies. And jam alot too.
Here are the slides for our talk Agile @ Lego at Passion for Projects in Uppsala. Enjoyed discussing this stuff with project managers and the like from all sorts of industries. A common theme from the conference was the power of self-organization, and the role of leadership in creating the right context for self-organization to happen. Our talk provided a real-life large scale example of this.
A couple of years ago I drew this picture and started using it in various presentations about agile and lean development:
Since then the drawing has gone viral! Shows up all over the place, in articles and presentations, even in a book (Jeff Patton’s “User Story Mapping” – an excellent read by the way). Many tell me the drawing really captures the essence of iterative & incremental development, lean startup, MVP (minimum viable product), and what not. However, some misinterpret it, which is quite natural when you take a picture out of it’s original context. Some criticize it for oversimplifying things, which is true. The picture is a metaphor. It is not about actual car development, it is about product development in general, using a car as a metaphor.
Anyway, with all this buzz, I figured it’s time to explain the thinking behind it.
Here is an InfoQ article with a nice summary of the keynote.
Agile product development has become the norm in many industries (especially software). That means products are developed by small, self-organizing, cross-functional teams, and delivered in small increments and continuously improved based on real customer feedback. Pretty much as described in the Agile Manifesto – but replace the word “software” with “product” (because it really isn’t software-specific).
That’s all fine and dandy. However when things get bigger, with dozens of teams collaborating over organizational boundaries, things obviously get more complex and painful. Even if the entire organization is neatly organized into scrum teams, you can still end up with an unaligned mess! Here’s a picture that might feel familiar:
I wrote this article because of two observations:
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
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.
This is just a brief snapshot of a journey in progress, not a journey completed
Sample slides below.
Last night our Lego Mindstorms robot “Robit” somehow managed to win the Robot Sumo competition at the GOTO conference in Copenhagen!
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?
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.
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
I’ve finally gotten around to porting the A3 template to Google Doc. Who wants to send around MS Word docs and PDFs? Bah. Put the doc in the cloud instead, where everyone can see and edit together. Or print the template and do it by hand.
Curious about A3 problem solving? See the FAQ.
Here’s a direct link to the template.
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:
We get a lot of questions about how Crisp works and why, especially from other consultants looking to create something similar. After many years of experimenting we’ve converged on a model that works well, basically the sweet spot between being an independent consultant and being an employee. So we decided to open source it.
In January 2015, at Crisp Hack Summit 10, Mats Henricsson, Henrik Kniberg and Max Wenzin huddled up and created the first version of the open-sourced Crisp DNA. It is published at http://dna.crisp.se/
The Crisp DNA is version controlled using Git and both Crisp DNA repository and Crisp DNA web site is hosted at GitHub using GitHub Pages. The web site is a bunch of static web pages and images that is generated from Markdown and Textile files using Jekyll. This is the same setup that GitHub themselves use.
By using open, version-control friendly formats such as Markdown and Textile, we hope to benefit from the open source community which can fork our model, make changes and perhaps suggest improvements. This can actually change how Crisp works!
Here are the slides from my keynote “Focus” at BrewingAgile Gotheburg. It was about how to achieve more by working less.
Feel free to reuse
PS – here is a video of the entire talk.
Strangely, in most companies people are considered perfectly healthy until they suddenly burn out. While in reality, it seems that a large number of people are somewhere between those two states, and could use some help to get more focused and less stressed.
We had a guy, Mattis Erngren, visit us at Crisp and do a session on focus training and meditation. Very pragmatic, interesting, and useful session. Highly recommended. Mattis and his company Lightly are on a mission to make focus training a standard offering at all companies, just like other health benifits like gym and such things. The brain is a muscle and it needs training too, to stay in shape.
So go ahead and contact the guys at http://lightly.io and bring them over. They offer free trial sessions so it’s really a no-brainer.
Incidentally, Jeff Sutherland was at the session at Crisp, and revealed that he used to be an avid meditator, and that Scrum was actually conceived during a meditation session. As in, the idea behind Scrum popped into his head right after a session. Interesting! When you clear your mind from all the noise, you make room for the really powerful stuff.
I travelled with Emma (6 yrs), she’s been wanting to travel with me (alone, without her 3 siblings…) for a long time, so she’s really happy! Thanks Mary & Tom Poppendieck for being her bonus grandparents during the whole trip
Some sample slides & pics below.
I was deeply moved by this letter. I’ve seen how Scrum and similar pull-based approaches not only improve productivity, but reduce stress and improve quality of life for people, and this is a powerful example. I asked the sender if I may share it with the world, and thankfully he agreed. Here it is:
Recently I picked up a version of your free online edition of “Scrum and XP from the Trenches, How we do Scrum” and I have to say it changed my personal and professional life.
I have been and software developer on interactive voice response systems for close to 20 years now.
A few months ago I was speaking with a colleague and mentor of mine about his efforts to become a certified Scrum master. Up until this point I had never really been exposed to Agile and Scrum in detail and only knew some of the jargon. My colleague suggested that I research and learn more about the Agile philosophy and in particular Scrum. Since I have been suffering from a poor work life balance almost my whole career I decided to pay it some attention.
I read your paper on a Saturday night and decided that Sunday that I would implement Scrum start on Monday morning. So I quickly pulled together a spread sheet with what I had that night and formalized the excel sheet that was our product backlog. That Monday I held my normal morning meeting with my development team and the rest is history.
The short of it is that my team is finishing up its 3rd sprint next week and we all love it. A lot of the stress that was keeping me up at night has completely gone away. I feel in complete control when I come to the end of my work day. In the past two months I have even hung out with my family on Saturdays and Sundays. I have begun to add more of a balance back to my life.
I really wanted to thank you for writing this paper and putting it out in the world for free. The tips that your paper offered have literally saved my marriage and probably my life.
Thank you again for you effort.
Wow, it’s been a crazy period. Sydney, Trondheim, Oslo, 10 talks in 2 weeks! Didn’t really plan to do that much, but one thing led to another. Fun, but exhausting!
Here’s a high-quality video recording of the Smidig 2014 keynote (on Spotify engineering culture). The conference organizers say it’s the highest-rated talk they’ve ever had! Cool :o)
Here’s a shorter version with much the same content, in the form of a two-part animated video series, for the impatient.
Here are the slides for my talk “What is Scrum?” at KTH (Royal Institute of Technology). It was a guest talk at a course called Projektstyrning. Hoping to inspire young entrepreneurs to plant agile DNA in their companies from the very beginning. Last time I spoke at KTH was 6.5 years ago, that’s when I met the first Spotify team, and I’m really happy to have been able to influence and participate in their journey!
Here are some sample slides from the talk:
Many common organizational problems can be traced down to management of Priorities and WIP (work in progress). Doing this well at all levels in an organization can make a huge difference! I’ve experimented quite a lot with this, here are some practical guidelines:
This is a journey in progress, not a journey completed, so the video is somewhere between “How Things Are Today” and “How We Want Things To Be”.
At Spotify we’ve been experimenting a lot with various ways of visualizing the “health” of a squad, in order to help them improve and find systemic patterns across a tribe. Since a lot of people have been asking me about this, I wrote up an article about it together with coach-colleague Kristian Lindwall.
Read it on the Spotify labs blog: Squad Health Check model – visualizing what to improve.
Some sample pics below:
Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work out well because of the great X, or despite the lousy X? You’ll never know, unless you could rewind the clock and play out the same scenario without X. Correlation doesn’t imply causation.
So people like me who work with organizational change, we are in the business of pseudo-science. We get customer feedback and anecdotal evidence, but we can’t actually prove that we are doing any good, it’s just opinions and observations and guesswork. I think that’s fine, but let’s be honest about it
This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears to be mostly true for most squads most of the time :o)
Here’s the whole drawing:
Here’s Part 2.
So, now I’ve spent 2 days with 600 projects managers at a PMI conference. Totally different from the usual crowds I hang out with. Fascinating to hear stories about project management successes and failures in all kinds of industries – from warzone reconstruction projects to eurovision song contest.
2010-2011 gjorde RPS en bra grej. De byggde ett system (Pust Java) som gjorde polisen mer effektiv. Poliserna fick datorer i sina bilar och kunde direkt registrera brott. Därmed behövde de inte åka in till stationen för att avrapportera lika ofta som med gamla systemet. Systemet var skräddarsytt för att ge hög användarnytta, och projektet blev en framgång. Pust Java blev finalist i CIO awards “project of the year 2011” och DN skrev en helsida “Polisen rapporterar betydligt snabbare med ny metod“. Systemet var inte perfekt, men en bra start. Poliserna sa att det var bättre än vad de hade innan, och folk var optimistiska inför systemets framtid.
Sedan hände något tragiskt. Istället för att vidareutveckla och kontinuerligt förbättra systemet, så valde ledningen att skapa ett nytt system från grunden (Pust Siebel) med undermålig teknik. Det blev ett fiasko. Ursinniga poliser klagade på att en avrapportering kunde ta flera timmar – “Pust Siebel gör en helt frustrerad och på gränsen till vansinnig!” – och saknade det gamla systemet. RPS hamnade i ett mediadrev. En poliskälla uppskattade samhällskostnaden till 10 miljarder kr!
Efter massiv kritik från både media, poliser, skyddsombudsmän och oberoende aktörer med insyn i projektet, beslutade RPS att lägga ner Pust Siebel. Nu är det allt fler som förespråkar att Pust Java återinförs
Varför spenderar en myndighet hundratals miljoner på att bygga något bra, för att sedan spendera ytterligare hundratals miljoner på att byta ut det mot något dåligt? Ännu värre: varför gör man detta trots att hela IT-avdelningen visste, och högljutt påpekade från början, att det nya systemet skulle bli sämre?
Syftet med denna artikel är att belysa och sprida lärdomarna, så andra företag och myndigheter slipper göra om liknande dyra misstag.