from the Crisp Consultants
(Translations: French)
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:
If you are working on an agile project, it is almost certain that you are using Stories to describe your backlog of work. It is another near-certainty that if you are using Stories, you write them down using this format:
“As a <user or stakeholder type>
I want <some software feature>
So that <some business value>”
As someone who cares about the state of agile practice, I want to offer some alternatives, so that agile teams remember that the point of the story is in the telling, not the template. The shared understanding comes from the conversation, not the card. By offering you different ways to ‘tell’ the story in its short written form, I hope you will be able to re-ignite a greater level of meaning, interest and engagement in your team’s discussions about the work they are doing to build great software that matters to people.
Here’s part 2 of the short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog). Check out part 1 first if you haven’t already seen it! 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”. Here’s the whole drawing:
Continue reading
One of my biggest surprises when I first met the squads I where going to work with at Spotify was that none of them were using User Stories. At first I observed to see their alternative. Unfortunately there was none. Instead most of the work got done as big chunks of work (what I would tend to call Epics) that was sliced into a todo-list of tasks (named that way by the developers) and also divided according different platforms.
A typical board contained one or more business cases and lanes for each developer/platform with tasks that were executed upon. These big “busses” where on the board blocking other works for weeks, which of course meant there needed to exist one or more emergency lanes for all expedite work (in the long run, most work).
This is a setup that does not foster collaboration, focus on value and art-of-the-possible. From an agile fluence point of view I would say it is a way of working that does not even reach fluence level 1 (Christian and I will describe agile fluence in more depth in a follow up blog post). From my experience focusing on User Stories is a great way of fostering the above values, and reach fluence level 1.
Crisp’s Youtube channel has made a new release – introducing Concepts. Concepts is used to let passionate people run with ideas, a different approach than that of traditional product ownership. If you do use in conjunction with a product owner, it allows that person to spend more time on the field with customers. Ps: The
Continue reading
(Download the cards & instructions as PDF or PPTX) 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
Continue reading
Here are the slides from my tech talk Agile @ Scale at Sony Mobile. Full house & very high level of engagement, I was impressed by this crowd! And thanks for the awesome recommendation on LinkedIn 🙂 Some sample pics below:
Continue reading
(this post will be in Swedish since it is a response to Swedish legislation describing how to sell and buy software. If you still are interested, Google Translate is your best friend 🙂
LOU – Lagen om offentlig upphandling är fröet till många katastrofer för statliga och kommunala mjukvaruprojekt. Tänkt som ett verktyg för att hushålla väl med statliga medel, genom att konkurrensutsätta erbjudanden bidrar LOU tyvärr till att skapa dåliga förutsättningar för att lyckas med mjukvara.
Det knasiga med LOU är de felaktiga incitamenten: Om vi antar att de funktioner som är användbara är relativt okända i ett tidigt stadium av projektet så är default practice vid användandet av LOU att funktionerna skall specas i början och sedan skall billigast leverantör väljas. Det vanligaste sättet att jämföra leverantörer är att skapa en lång lista av den sammanlagda funktionaliten i deras produkter och sedan låta dem bjuda på minsta kostnad. Inte oväntat kommer vinnande leverantör efter kontraktet’s inskrivande att snabbt flytta på senior kompetens ur projektet till fördel för junior och vips befinner både kunden och leverantören i en långsam dödsdans där kundens användare blir förlorarna.
LOU innehåller dock ett antal möjligheter som du som upphandlare kan nyttja smart.
Are you also sensing something is wrong with today´s organisations? If you have been working with Agile or Lean for a while you typically notice that the early wins and benefits on a smaller scale will very soon hit it´s limits. Maybe you have been struggling with getting expected results from your Agile and Lean transformation initiative. Or you feel it is going painfully slow. In this blog I am going to put some light on what is wrong and what to do about it. My intention for you is to better understand the friction we are sensing in today’s organisations and what is getting in the way from creating truly Agile Organisations.
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
Continue reading
As so many others I’m inspired by the book Lean Startup. The idea of experimenting with your business model and deliver just the bare stuff needed to validate (or actually try to refute) your business hypothesis is so enticing. But how do you do that when you are one of 50 or 100 teams? How do you do that when the teams are not even using User Stories? How do you do that when daily work is done on a Kanban board only showing tasks?
One part of a possible solution is to find a way of visualizing the business case. A popular approach has become setting up a business board, often called a Lean Canvas. I wanted to try something like that. But going trough all the different variants I could find, no one was good enough in itself. I wanted to get the same feeling as with User Stories: a simple formula that everyone can understand and use as soon as the formula is presented.
Last week i quit my assignment at Spotify. I was there to help and act as a stand-in for Joakim Sundén while he was on paternity leave. He’s now back in the saddle as Agile Coach in the More Than Music Tribe. I had the pleasure to work closely with the Agile Coach Christian Vikström on Spotify and together we have been coaching the Browse, Growth and Customer Support squads. A was also a member of the tribe management team, and together we did some new interesting stuff.
It’s has been fascinating and fantastic to work with such dedicated people and a product that has such a traction. Spotify is also really trying to build an awesome and agile organization and culture that can win and sustain in the long run. What is there to do at such a fantastic company? That’s a reasonable question. A lot I discovered. Spotify is shock full of super smart people, but many of them has not worked there for long, many of them has not worked long at all, teams have been newly formed and are under constant change. Simply put: even Spotify needs a lot of basic agile coaching.
When I now look back at what we did during these last 8 month I see a lot of tools and experiences that I think others also can find useful. During the next couple of month I will share them through this blog. Hope you will find them useful. Here’s the planned list:
In this series of articles, I’ll be discussing the developer profession from different angles. The common denominator is that all articles will, in one way or another, be about professionalism. This first article is about the different factors and decisions behind every single line of code.
A while ago I spoke to a friend who is pretty much a professional singer. He explained singing to me in a very passionate way, saying that singing is like solving multiple parallel equations in real time. He told me that it’s quite obvious that every singer has to follow notes. What’s less obvious is that the singer also takes a multitude of micro decisions during every second of his/hers singing. He told me about tempo, intensity, interpretation of the composer, matching the expectations of the audience, synchronization with other singers, following the Kapellmeister, and a bunch of other factors. I was quite impressed.
A second later it struck me that this goes for programming as well, and I started to list all the equations a developer must solve while writing a single line of code. Here it is!
Last week Jimmy Janlén and I held a shortened version of our course Training from the Back of the Room for our former colleagues at Spotify. Actually it is not “our” course, but Sharon Bowmans. It’s based on her books about how create a more engaging learning experience in the class room, especially when training adults.
“I really liked the whole setup of this course – a really well organised and inspiring day. Wow :-)”
Jimmy and I are certified trainers of this course. We use the techniques when we do training. But we have also experienced how useful they are in other coaching and facilitation situations, such as workshops and retrospectives. Almost any meeting can be made more engaging and with longer lasting result with the set of tools TBR provides.
We have chosen to call the shortened training Facilitating from the Back of the Room, since that is what we agile coaches do most. 16 persons from the Spotify Agile Guild showed up this beautiful day in a corner room on the 17:th floor in High Tech building with amazing views over Stockholm city. We have to admit we were a little nervous at first. Would this actually make sense to coaches? It did.
When is a so-called requirement really required? And is it the “right” requirement? The answers depend on many facets: stakeholders, value, planning horizon, and so on. This article explores using options as a means to identify high-value requirements, at the last responsible moment.
Product requirements are needs that must be satisfied to achieve a goal, solve a problem, or take advantage of an opportunity. The word “requirement” literally means something that is absolutely, positively, without question, necessary. Product requirements must be defined in sufficient detail for planning and development. But before going to that effort and expense, are you sure they are not only must-haves but also the right and relevant requirements?
Continue reading
Borde du inte programmera snabbare? Varför tar det så lång tid att mata in kraven i datan? Har du hört den frågan förut? Del 5 är i serien “TDD på svenska” handlar alltså om detta och har precis nu publicerats på vår YouTube-kanal “Crisp Agile Academy”. Du hittar som vanligt de tidigare delarna i serien
Continue reading
Jimmy och Hasse håller på att skriva en ny bok. Den är på 20 sidor och i PIXI-format. På denna blog så tar vi tacksamt emot feedback från boken. Ifall du vill ha ett förhands exemplar skicka ett mejl till crispdiscover@crisp.se. Till den mejladressen kan du även ge feedback, eller använd kommenterings på denna sida.
Continue reading
Here are the slides for my talk What is an agile tester from the Colombo Agile Conference in Sri Lanka.
Here are the slides for my keynote How do you know that your product works, from the Colombo Agile Conference in Sri Lanka.
One of the key challenges for any organization moving to a Lean flow is learning to slice bigger things to small. If you practice this long enough this becomes second nature and you stop thinking about how you do it. The good news is this skill can be taught and to show the dimensions available
Continue reading
At Agila Sverige 2014 I talked about consensus, what it is, why it is the basis for creating good and strong decisions that is often already implemented when the decision is finally made. I also talked about the hand signals we use at Crisp to manage our consensus decision process (read more about it here).
Here’s my slides, that contains more on howto facilitate consensus decision making:
Continue reading
– “All kod är en skuld!”
– “Den bästa koden är den kod man inte skriver!”
– “Snabbaste sättet att få upp testtäckningen är att ta bort död kod!”
Jag tror att alla är överens om att det är bra att hålla sin kodbas så liten och kompakt som möjligt. Byggtider hålls korta, testsviter går fort att genomföra, driftsättningar går fort, statisk kodanalys går fort, nya teammedlemmar kommer snabbt in i koden, risken för buggar och sårbarheter hålls nere och så vidare. Kort sagt, man blir mer lättrörlig!
Så alla utvecklingsteam borde ägna tid åt att inte bara skriva ny kod, utan också att faktiskt städa efter sig. Men det är lättare sagt än gjort…
Continue reading
Varje produkt börjar med en idé. Det första man behöver göra är att validera den idén och det görs bäst genom att bygga det minsta möjliga som förklarar den idén och gör idén mätbar. Låt oss kalla det den minsta mätbara förhandstitten.
När man mäter så får man data för att kunna avgöra om idén var bra eller inte. Det vi lär oss av att mäta och utvärdera idén kan vi sedan nyttja för att ta nästa steg, såsom en detalj av idén eller en ny idé baserad på den förra, som vi också behöver mäta och utvärdera. Vi vill validera problemet, målgruppen och möjliga lösningar för att vara säkra på att inget lämnas åt slumpen. Detta blir en lärandeprocess baserad på riktiga resultat.Continue reading
Had a great day at Stop Starting Start Finishing – Lean Kanban Nordic. It is cool to see how far companies have come in applying Lean in software, especially experimenting with how to tie together the full value chain. Saku Tuominen really challenged us to think make innovation actionable and not put it into a
Continue reading
I tisdags hade jag glädjen att få komma tillbaka till Lantmäteriet i Gävle och återigen hålla ett seminarie. Denna gång var titeln ”Agil Testning – Will automation replace the tester”? Lite vilseledande då ämnet jag täckte var långt mycket vidare än så. Under två timmar pratade bland annat jag om: Contexten som agil testning lever
Continue reading
I assume you are familiar with the old truth that competition spurs motivation and fear; two tremendously powerful mental states. Let me introduce my new concept that leverages both: Competivation.
It comes in two flavors, external competivation and internal competivation. They complement each other and will boost efficiency, and keep everyone on their toes at all times.
At my current assignment, I needed to get my fellow developers up to speed with Wicket. So I put together a one day course that taught them enough to join in on the work of a current application. Everything is publicly available on GitHub here: https://github.com/perty/wicket-kurs.
You get a starting plate for a complete web application with database backend accessed through Spring Data JPA. Also, there is a Power Point presentation that guides you through the exercises. Very little is spent on Wicket philosophy and concepts to the benefit of hands on coding.
Lotta Olsson and I will present Sandvik IT’s Kanban journey at the Lean Kanban Nordic 2014 conference in Stockholm (a.k.a. “Stop Starting, Start Finishing” conference). Lotta is currently managing the Operational Excellence Support (OpX) unit within Sandvik IT. The OpX is the ‘home’ of Kanban, ITIL and other processes and tools designed to improve the
Continue reading
Here are the slides for my talk “Focus” at Projektnäring. Great group, lots of energy in the room. Had lots of great conversations with people. Thanks for attending!
Sample pics:
A fundamental component for fluid operations is an organization’s ability to solve problems and make decisions. Any change or transformation cannot move faster than it’s ability to make decisions and communicate these. This is key if we realize that living with changes is the future status quo of operations.
Many years ago when I was still at University I got to meat a leader at production facility at Volvo, he asked us,
“How long time does it take from when the management team has made a decision and a worker on the shop floor grasps what this means?”
“Three years”.
Without a doubt, this is way to slow for product development and software. But it puts a finger on the starting point for a normal, traditional company, before any lean or agile transformation begins. So, in order to succeed with a transformation that will challenge existing (often plan based structures) we need a better decision & communication process.
