I’ve updated the Kanban boards collection with examples from departements outside IT, Product portfolio and Corporate Legal.
- Download “10 kanban boards and their context” as pdf
I’ve updated the Kanban boards collection with examples from departements outside IT, Product portfolio and Corporate Legal.
Many companies have mastered getting Agile to work at the team level, but few have mastered Strategy. Ask yourself the question, “Do I have a winning strategy?”
We managed to get some of the world’s best thinkers (and doers) to come to Stockholm for Fast Feedback 2016 to speak about “Strategy and Decision Making under Uncertain Conditions”. Meet them live in Stockholm on Sept 21st-22nd. To improve interaction between participants in a friendly and easy going way, will be introducing a brand new concept this year – LEGO Serious Play.
A sneak peek at the highlights of Fast Feedback 2016:
This is a one-off event not to be missed. Be sure to sign up before June 30th to get the early bird rate!
The talk is about Spotify’s current approach to getting aligned as a company. It covers:
Holy crap how did I manage to cover all that in 10 minutes?! Guess I talked fast
Some sample slides below.
Here’s the video of our presentation “Learnings from SAFe @ LEGO” at LKCE 2015.
psst: Meet LEGO f2f at this years Fastfeedback conference 2016 (Stockholm, Sept 21-22:nd). This years focus topic is “Strategy – Turning insight to action”.
Based on the experiences with clients adopting Large-Scale Scrum, from 2007 to 2009 Bas Vodde and I wrote the first two books on LeSS:
These are a collection of experiments related to Large-Scale Scrum, organized into three major sections: experiments in thinking tools, organizational tools, and action (practice or technique) tools.
And now, almost a decade after starting our first book on scaling agile development, comes our third book: Large-Scale Scrum: More with LeSS.
Thanks everyone who attended for making this a great evening event!
OK, technically speaking, it was called a networking day. But that wouldn’t do justice to the content here.
The main thing we got out of the ACPN Agile contracting conference was the three different perspectives from lawyers, customers and providers. That gave us a unique insight into the challenges and questions from each party.
Some cool facts:
Insights and reflections from the conference:
If you want to read more about the conference and including a short video summary – check out:
The conference was organized by Crisp & Nordic River (Sweden), Best Brains (Denmark) and Codento (Finland).
In this talk I presented a simple 2D platformer written in Java/Groovy and how to use Spock to test it. I’ll make the source code available in a while.
By the way, of you’re not using Spock yet, then start!
The Spotify ‘model’ was presented in 2012 and has stired a lot of interest in the agile community and the software industry in general. In May I was asked to talk about this a the Bay Area Agile Leadership Network meetup in San Francisco (where I at that time was working as an agile coach at the Spotify office): Since 2012 Spotify has continued to grow hectically. How has agile evolved at Spotify since then? Going back in time, and following the latest structural changes makes it clear that the model was never the primary mover: instead a number of core principles and ambitions has worked as constraints on how to grow the most suitable organization for the task, with small enough structure to help but not be in the way: you could call it Minimum Viable Bureaucracy.
Here’s the slides:
I also spoke about the same subject in April, at Agila Örebro, where there is a video recording of the talk (in Swedish).
Next week on april 28th, we’re having the worlds first Nordic conference on Agile Procurement in Copenhagen!
The line up with speakers is extremely interesting. We have real cases from from Denmark, Finland and Sweden where Agile Procurement and Agile Contracts has been used with successful results. With a lot of the cases in the public sector. Also, there will be talks about the Agile contracts and time to mingle and talk to speakers after the sessions.
We are starting to see a shift here in Sweden where the public sector as well as the private are starting to procure with Agile methods, but the Agile contracts are rarely being used. This makes it difficult to get the benefit from the Agile requirements process and the Agile development. What I believe is needed to change this is to give access to real success cases within the same field, and to get the lawyers to understand and wanting to try the Agile contracts. This is what the conference is all about.
I hope to see some curious Swedish government agencies on the conference getting inspired from the many great success cases from Denmark and Finland. It can be done, and it will change the outcome of so many projects.
Join us in this great event and spread the word of successful procurement and development of big complex projects!
Last week, I got this great question from Faraz (a manager for an energetic customer support crew) who is experimenting a lot with getting more Agile. “What seemingly normal things do Agile people do?” I realized that we rarely talk about the small things that effective Agile people do. What makes a great difference is rarely the big sweeping change programs, but rather, the small everyday things we do without thinking about it.
So here’s a list of 12 seemingly normal things Agile people do which we don’t pay much attention to that can make a big difference.
Good meetings is very much about achieving deep collaboration. But collaboration is often hard. We go into meetings with different modes, intentions, and expectations. How can we make meetings both more fun and energetic? Surprisingly enough: maybe by being more formalized.
read more »
I recently did a podcast together with Dennis (CIO Nordnet) on #slowtofast. I walked into the podcast thinking it was going to be about Kanban and Enterprise Agile. Right! Dennis hit me with these simple questions..
All hard questions, and all so essential to get right. Here is the podcast:
If you are into Product managment and UX you’ll find more interesting topics in Marcus and Dennis podcast Slowtofast.
Today I held a Design Studio workshop with about 25 people at NetEnt in Stockholm. There where people joining in because they where curious, from all different departments. Perfect for innovation
It was just an hour, with a short introduction, starting with a warm up exercise to get their brains started up, and then 3 short time boxed iterations in 7 groups of 3-4 people. And then we had a 2 min presentation from each team on their combined idea in the team. Really exellent stuff!
A couple of the participants had done Design Studio before, but most of them had not. One of the participants said afterwards “When we got the mission, I had absolutely no ideas at all. But after just the first iteration I had plenty!”. Thats the way it works, you generate ideas and find solutions and see them from different angles as you work together.
The different groups came up with amazing ideas for future games on smart watches. Really innovative and cool
The Discovery Team
The more diverse your team is, the more perspectives you will see at the same time, and the better your ideas will be.
In the start of a new thing you might want to invite stakeholders, customer service, HR, marketing or others. When you do your sprints, you might pick some one outside the team to get a broader picture. read more »
Continuous discovery means an open backlog where everything is considered speculation and hypothesis. Continuous validation means that the user experience is validated for each release, rather than up front. This may sound like big budget to you, but let me give you a case study, about how a single team accomplished it on a tight budget.
A small team with a small budget has the advantage of not losing its head with big ideas from experts in different fields, be it architecture or user experience. The budget constraint sharpens your effort in a way that could be healthy even to a larger team.
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.
Candy Crush Soda releases a new version of the game on all platforms every other week, year round. I’ve written about the delivery pipeline and the challenges the team faces on King’s tech blog: https://techblog.king.com/candy-crush-soda-saga-delivery-pipeline/
I’m currently coaching a team with several stakeholders in different parts of the organization. It’s difficult to know who to talk to when decisions need to be made. The line between what the team can decide about and what the stakeholders need to be involved in is also blurry. To help create more clarity and a better collaborative environment with our stakeholders we decided to create a delegation board. The meetings we ran this week were appreciated by everybody, so I thought I would share what we did and what we learned.
The Kanban and Scrum minibook is now available with Polish translation. Great thanks to Zbigniew Zemla for the translation!
Pobierz tutaj (aka polish for “get it here” ):
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.
Att få bygga, skapa, designa och uppfinna har alltid varit något jag älskar att göra. Egentligen spelar det inte så stor roll vad det är, det roliga är att lösa problem, formulera vad jag vill, komma på vad som gör det bra, skissa och se att det växer fram något efter hand som jag inte kunde föreställa mig innan jag påbörjade arbetet.
Till vardags jobbar jag som kanske bekant för en del, med att coacha inom hur man bygger bygga digitala produkter, oftast Lean UX i Agila Team. Kanske är det därför det kliar lite extra i fingrarna i bland att göra väldigt fysiska produkter
We have translated our blog on team size and proximity to english.
If you prefer to read it in Swedish it’s called Storlek och närhet har betydelse.
The english version you’ll find at Nomad8 site, because Jimmy Janlén is currently in New Zealand.
På grund av att många försöker få med “allt” I en IT-upphandling, är det endast 40% av det som byggs som gör nytta i digitala tjänster och produkter. Lean UX hjälper oss att bara bygga de 40% i stället för allt.
Att arbeta med Lean UX är ett bra sätt att kunna identifiera vad vi behöver bygga, och prioritera rätt löpande. Men hur funkar det egentligen med Lean UX och Agila team?
Mina nästa kurser inom ämnet under våren 2016: https://crisp.se/kurser/kurstyper/product-discovery-med-lean-ux
Jeff Gothelfs kurs för managers i Lean UX som kommer under våren 2016: https://crisp.se/kurser/kurstyper/lean-ux-in-the-enterprise
Upphandling med Lean UX och Agila kontrakt för upphandling med minskad waste: https://crisp.se/kurser/kurstyper/certifierad-agil-bestallare
Vill du att jag kommer och föreläser på ditt företag, eller hos din kund? Hör av dig!
The www.crisp.se website is based on WordPress, with a custom Crisp theme.
This is the story about how we’ve developed our custom WordPress theme, how we’ve made it easy for any Crisper and external consultants to work on the theme, how we’ve setup version control, continuous delivery, staging and production environments on Amazon Web Services (AWS). And how all of this is setup with absolutely no automated tests whatsoever.
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.
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.
Process är dyrt. Större team, distansarbete, deltidsarbete samt många specialister leder till mer uppstyrd process. Kanske är detta självklart, men ju fler företag vi lär känna, desto mer upplever vi detta vara något som ignoreras.
Jobbar vi i någon form av agil process såsom Scrum, Kanban, eller Lean UX värderar vi högt samarbetet mellan olika kompetenser. Ett team av olika kompetenser som kan ta en idé från start till mål brukar kallas tvärfunktionellt.
Enklast möjliga agila process för hur dessa personer kan samarbeta ser ut så här:
read more »
I recently recorded a webinar where I walk through 5 ways to find slack (to invest in critical improvements), when a team is under high pressure.
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: