What should a struggling software development team do in a world of seemingly infinite improvement options?Continue reading
Tired of the same old boring and ineffective daily meetings with your team? Try this new Awesome Team Focus daily routine! It will help your team use a swarming technique to laser-focus on the stuff that really matters and get it done. As a bonus it will help you start limiting Work In Process withoutContinue reading
You may have read about this elsewhere, but a recent event led me to write this. I feel that the working agreements concept is not given the attention it deserves. Working agreements are about making your culture explicit. It is desirable to have them visualised on your Scrum board as a constant reminder. Question is, when do we remove them from the board so that they don’t cover the whole board? My answer is, when the third state is reached, “internalised”.
Adapting to accelerating change
In a world where the speed of change seems to accelerate almost exponentially, it is only natural that an organization’s way of working must be constantly challenged and improved – especially in the highly competitive media business.
This text, which was inspired by winning an award (we will return to that), is the outcome of a joint effort between Michael Göthe, Agile Coach at Crisp, and Jens Abrahamsson, Agile Coach at Telia Company’s TV & Media Backend department. In it, we describe parts of the always-ongoing journey towards a more lean and agile way of working at the Telia TV team.
As always when looking back at a complex change process it is not possible to copy what we did but our intention is to share useful learnings, practices, and tools that can inspire you on your change journey, in your context.
Help your team improve by visualizing their way working with the fluent@agile game. With the game you can help a team find out where it is on its agile journey and help it find new ways of both fine tuning and make leaps in their daily agile practices.
Me and Christian Vikström made the game together at Spotify during the spring 2014 when we were coaching and helping team to improve their agile skill sets and processes.
At Spotify the teams owns their own way of working. A team is basically only accountable to itself. We therefore needed an coaching tool that could help team take ownership of their self image and improvement strategy.
We also wanted the tool to be opinionated. It should be normative, tell what’s good and not, what kind of practices and behaviour that’s expected and not. But at the same time it should be open to new ideas, new practices and the teams local conditions.
For more than a year now, I’ve been working with clients that have agile scaling problems. But not the kind of scaling problem everybody is talking about – one product and lots of teams. No, I’ve been busy trying to sort out what to do when you have one team supporting a multitude of products with different architectures, stakeholders, technology stacks and whatnot. This is what I’ve learnt, so far.
Should the Scrum Master role be full time or part time? What if there is not enough Scrum Master work to do? Can the Scrum Master also do other work in the team? Can the Scrum Master be Scrum Master for several teams?
There was a debate about this and Scrum Alliance created the Scrum Master Manifesto in 2011.
Even though this has been debated by many minds before, I still get asked what my views are on this topic.
I’ve done all kinds of variations on this role. I’ve been a dedicated Scrum Master for a single team. I have done the SM role and a developer role at the same time. I’ve been a Scrum Master for several teams at the same time. These alternatives have their own advantages and challenges. In this post I intend to describe my view and recommendations.
Update: The book has since the publication of this blog been
made available for purchase at LeanPub.
A couple of weeks ago I published my new book ”Toolbox for the Agile Coach – Visualization Examples (How great teams visualize their work)” even though it’s still very much a work in progress.
I’ve made it public, thanks to persuasion from my colleague Hans Brattberg. I decided to try out Google Slides to make it easily accessible and to provide a simple way to give feedback. That turned out to be a great decision. The response has been overwhelming. There are at any given point 5-15 people reading the book, many of which provide great feedback, point out spelling correction and provides generous suggestion for more examples.
I’ve met very few teams that successfully found a valuable and useful way to update and use a Sprint Burndown. The Sprint Burndown can be tedious to update (if done manually), and doesn’t seem to trigger the discussions in the Scrum team it is designed for. Even to agree on a unit causes confusion (hours, tasks, finished User Stories?).
But don’t despair; let me introduce you to Confidence Smileys. Confidence Smileys provide a simple, honest, transparent and overview-friendly tool for the team to visualize how confident a team is that they will be able to finish each User Story by the end of the sprint. The can replace the need for a Sprint Brundown (or Sprint Burnup), or function as a complement.
A decade of agile boils down to theses simple fundamentals and steps for me. A. Ask: do you need to improve as an organization? Only go forward if your sincere answer is yes. Ask everyone: Do you want to improve? Same procedure. Make sure you will fail (and win) regularly by commitment (plan/hypotheses) and checkpoints.Continue reading
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: RecentlyContinue reading
Agile facilitators, be aware, now you are about to be replaced – by a cube. Just kidding. But have you ever felt that your meetings are not on track? Or that you have a hard time doing the elevator pitch for that backlog grooming meeting you would like your team to have? Or do you meeting often ends in thin air? Comes your rescue: The Agile Meeting Cube.
The Agile Meeting Cubes gives you purpose, expected outcome and a suggested checklist and possible tools to use for six classical Agile or Scrum Meetings:
- Release Planning
- Backlog grooming
- Sprint Planning
- Daily Standup
- Sprint Review
- Sprint Retrospective
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 IContinue reading
One of the best exercises I know of on how to learn and practice User Story slicing techniques is the so called Elephant Carpaccio exercise. At Spotify it is something of a staple as it it is (often) used when introducing new employees (now a days). Facilitating the Elephant carpaccio exercise from Peter Antman TheContinue 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.
Squad focus on technical tasks
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.
- ToDo has a flow. It knows about cycle times and about being DONE. Trello does not.
- ToDo has Planning Poker Estimates. Trello does not have any estimates.
- ToDo has automatic burn up charts. Trello does not.
- ToDo has swim lanes which groups cards by your dimensions. Trello does not.
- ToDo has Work-In-Progress limits. Trello does not.
- ToDo has upgrade possibilities to the full tool set of Projectplace. Trello has a bunch of plugins from different vendors of various quality.
Already convinced? Sign up for ToDo by Projectplace! Want to know more? Read on.
Sometimes it’s hard for a team to know if they get tighter and better as a team over time. This is a tool that allows a team to learn just that.
Team barometer (self-evaluation tool) in a nutshell
The barometer is executed as a survey in a workshop. The survey consists of 16 team characteristics, packaged as a deck of cards. Team members vote green, yellow or red for each card in the meeting (or before the meeting as an anonymous survey). Once all cards have been run through, the team reflects and discusses the results. You can, if you want to, run through the exercise in thirty minutes, but I recommend to set aside an hour.
In this episode of our YouTube channel Crisp Agile Academy I talk about Sprint Burndowns. I discuss the value of having one and that it is a tool for the team, not anyone else. I also give examples of different kind of burndowns: Remaining Hours, Remaining Story Points, Remaining Tasks, Things in progress, and Confidence level. I wrap up the episode with a little quiz.
At my current project we use a Google spreadsheet to manage our backlogs. This works really well for storing and sharing the backlog, but it’s not very good for visualizing it. So we print out the stories on cards by copying and pasting each row into a document table cell and reformatting, adding extra labels, and manually inserting priority. Well, that’s what we did the first couple of times, until I found David Vujic’s fantastic Index Card Generator for Google spreadsheets (http://davidvujic.blogspot.se/2011/06/visa-vad-du-gor-eller-dude-wheres-my.html).
Except, we have multiple backlogs in one sheet, our column names aren’t the same, and we use a different layout for the cards. Here’s how we customized David’s script!Continue reading
Återigen har ni diskussionen om “working software over comprehensive documentation” verkligen betyder att man inte behöver dokumentera någonting alls. Eller diskussionen om det är ok att förlänga sprinten med några dagar för att hinna klart den sista fixen på den där storyn. Eller diskussionen om vad det egentligen innebär att vara “lean”. Känner du igen dig? Kan det vara så att alla har nytta av att ha samma grundförståelse av centrala begrepp i och runt “agile”? Läs vidare för ett enkelt sätt att skaffa den kunskapen!Continue reading
På ett bräde blev boken Riv pyramiderna igen dubbelt så tjock (222 sidor) med det nya kapitlet “En organisation utan huvud – en agil odyssé“. I den gör vi en historisk, praktiskt och teoretisk resa från apache-indianerna, över Ford, Toyota, Lean, Scrum, Agile, flödeseffektivitet, Hegel, Kant, hur det påverkade oss och mycket mer. Slutstation:en massivContinue reading
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!
This is MIKE, The Daily Meeting Microphone. MIKE is a concept. An idea. Captured on a poster. If you like it; Click the image below (or click here to download the powerpoint). Print it on A3 format. Put it on the wall next to your team wall or in the office corridor. Done 🙂 IfContinue reading
During the conference Agila Sverige 2013, I – the Evil Coach – made my first public appearance. I gave a lightning talk on how to maximize the team’s performance. The room was filled to the brim. The talk ended with standing ovations which were immediately followed by an early termination of the conference since no one could possiblyContinue reading
Improvement Theme is a tool in the form of a poster that works as a conveyor belt for continuous improvements once the Retrospective is over.
I’ve been reading a little bit about Toyota Kata and seen great presentations on the concept. In order to make it practical and useful for me I found myself tweaking it and packaging it in a concept I’ve come to call Improvement Theme. I’ve tried this concept a couple of times now and found it to be a good tool to extend improvements beyond the Retrospective and bringing it into the daily work. In this article I describe how to create the poster and how to use it as a tool for continuous improvements.
The Improvement Theme is a poster. I’ve been using magic charts since they are easily moved between the room in which the retrospective is held and the teams wall.
The charter consists of five areas.
1. Name of the Improvement Theme
2. Now/Problem – Description of the current situation
3. Definition of Awesome – How would we like it to be?
4. Next Target Condition – X weeks from now, what has changed?
5. First Steps – 3 slots for three post-its that describe the first (next) actions we will take?
It’s a living document, preferable put up next to the scrum/kanban wall. Once or twice a week the team reviews the theme and agrees upon new actions as they get completed.
When X weeks has passed the team does a review of the theme itself. If they want to continue on the same theme they identify a new “Next target condition”. Otherwise they create a new Improvement Theme poster.
Here follows an extensive description of how I’ve been using the concept as a tool for improvement and a more in-depth description of the different aspects of the poster.
Agile People is a network for people interested in applying agile principles and values to HR started by the superblogger Calle Blomberg. We recently hosted one of the networks meeting at Crisp. Petter Weiderholm talked about Peoples Operations at Spotify. We featured Jimmy Janlén with his fantastic spaghetti exercise. I talked about Agile HR fromContinue reading
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.