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.

Continue reading

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.

Continue reading

Here are the slides from my keynote “Real-life agile scaling” at Agile Tour Bangkok. Enjoyed hanging out with everyone!

Key points:

• Scaling hurts. Keep things as small as possible.
• Agile is a means, not a goal. Don’t go Agile Jihad. Don’t dump old practices that work.
• There is no “right” or “wrong” way. Just tradeoffs.
• There is no one-size-fits-all. But plenty of good practices.
• Build feedback loops at all levels. Gives you better products and a self-improving organization.

Here is an InfoQ article with a nice summary of the keynote.

Sample slides:

Continue reading

Just back from Lean Kanban Central Europe 2015. A great conference that keeps pushing the limits. At the conference I gave a talk together with Eik aka “Captain Agile” from LEGO. We walked through how they introduced SAFe, how they involved other departments and most important, how they experimented their way forward.  (Me and Henrik iterated as coaches

(translations: Russian, Turkish)

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:

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

Edgeware is a cool hardware and software company helping operators to build efficient video content delivery networks. Read their blog about what we have been up to since August this year: Lean and Agile at Edgeware

UPDATE Dec 2016: Wrote an article about LEGO’s agile journey, see here. Includes all of the material below, plus explanations and updates.

Here are the slides for my Lean Tribe keynote Scaling Agile @ Lego – our journey so far.

Here’s also a more detailed version from a talk that Lars Roost and I did at GOTO conference in Copenhagen: is SAFe Evil (that talk was also recorded).

This is just a brief snapshot of a journey in progress, not a journey completed 🙂

Sample slides below.

Continue reading

Otroligt kul att se hur många som fick plats i ett konceptrum i Aula Magna under våra presentationer under SAST Q20! Vi pratade först om kontinuerlig förbättring och sedan om working agreements. Slides hittar du nedan. Kontinuerlig förbättring Working Agreements På Crisp har vi en hel del gratis material och guider, bland annat en Toyota

The other week I got the idea to create simple conversation cards. Each card represents an agile practice, a conversation topic or an abstract theory. Now I’ve drawn 96 cards. I simply couldn’t stop 🙂

Continue reading

For  this year’s Stop Starting conference, we asked ourselves three questions: How do you develop awesome products? How do you bootstrap a successful mega project using Agile contracts? How do you use Agile and Lean thinking to turn a stagnant company around? We then picked the brains of people from real companies who have been

Can you develop new products from scratch in one day?

This challenge was taken on by the Medical HW manufacturer Optinova in August. Over the course of two days, we pushed the limits of “what is possible” by applying Agile in a HW environment.

Our hypothesis was that Agile would be a good fit in product development and innovation scenarios. And the result so far from the work that we have been doing with Optinova is promising.

Cross-functional teams, focus, rapid prototyping, close customer feedback and visual overview work just as well in hardware as in software. The training setup we used was as follows:

• Day 1 – Learn basic Agile practices and principles
• Day 2 – Applying them – developing three product ideas from scratch in one day, in a rapid prototyping workshop.

The result: All three participating teams managed to take an idea to working prototype in a day. One team went so far as submitting a bid to a real customer the following day based on their prototype. That’s high speed, even in software terms. But the most important thing wasn’t the result, it was the lessons learned. When we asked the participants if they wanted to continue to build products this way, the votes were unanimously in favor. If we can get it to work, this would help build a competitive and innovative company.Continue reading

Vi har byggt en sajt där med goda exempel, för att inspirera företag, myndigheter och verksamheter på väg in i en upphandling att ta steget till Agila kontrakt. Check it out – agilakontrakt.se. Eller följ oss på twitter: @agilakontrakt. Turen har kommit till att berätta om Wunderkraut, som använt Agila kontrakt sedan 2010. Det intressanta är hur de i den ombytliga

Låt oss säga det direkt: att kombinera pm³ och någon agil metod, som t ex Scrum, är en dålig idé. Varför?

Därför att du kommer inte kunna dra nytta av det agila arbetssättet. pm³ är baserat på en helt annan världsbild. pm³ bygger på årsplaner och att verksamheten beställer från en leverantör, typiskt den egna IT-avdelningen.  Agilt har som en grundläggande värdering att reagera på förändringar i stället för att följa en plan. Det agila arbetssättet drivs proaktivt genom utforskande i motsats till att vara en mottagare av beställningar.

Vi har sett flera försök att implementera pm³ och de har ofta misslyckats på grund av att pm³ bygger på tankar om att verkligheten kan förutsägas 18 månader i förväg, att användarna vet vad de vill ha och att det är viktigt att ha en skarp linje mellan verksamhet och IT. Vi hävdar (och flera med oss törs vi lova) att inget av detta är varken sant eller bra.

Continue reading

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.

Continue reading

Guess what – I’ve updated Scrum and XP from the Trenches!

Continue reading

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

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.

Continue reading

Having trouble with curled Post-its that won’t stick to the wall? Well, it could be due to bad glue or that you peel them off wrong. I would guess it’s the latter. Might feel like a silly blog post to write, but I found myself teaching people the technique of peeling Post-its quite frequently. It’s

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.

Continue reading

Du har en idé om en tjänst.
Hur kan du snabbast och enklast verifiera att någon vill använda den?
Det är vad Lean Start-up handlar om.

Continue reading

If you wonder what a Scrum Product Owner need to do, here’s the checklist (in form of a mind map) for you!

Continue reading

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

A couple of weeks ago I started a new hobby. I’ve found a way to combine teaching agile and lean with creativity, art, Lego and Star Wars. Now I love spending time slowly putting Lego blocks together to create scenes. One by one. Very meditative and creative 🙂 The scenes I build I then use

This is a guest post from veteran Agile UX coach Anders Ramsay who’ll be visiting Crisp in March.

In a traditional UX practice, there tends to be a strong focus on whole product design.  In other words, we want to integrate all the features of a product into a unified and coherent experience, before we can consider the design work to be done.

Big Design Up-Front is like growing a tree in a “wireframe nursery” before planting it in the real world of working software.

But if you are taking this approach in designing the user experience, and you’re also part of an Agile team, then that might be a major reason why you’re struggling to integrate your UX practice into an Agile model.Continue reading

Traditionally IT-systems and products are developed in a project. Once developed, it is deployed and handed off to the maintenance organisation. But the new companies that start out with an agile way of working does not have these maintenance organisations. How do they do it? Is there no Maintenance in Agile?

Continue reading

Do participants fade away in a long “zzz..”  or the perfect time to update yourself on what your friends are doing on FB? No more! Check out the Energizer bible for nifty tricks for keeping up the energy level during workshops and trainings.

What is Agile, actually?
Have you ever asked yourself the question, ”what is Agile”? Ever been asked the question and found yourself looking for the easy answer? The true answer is of course that Agile is the Agile manifesto but do you know anybody who can recite the manifesto just out of his or her head? When asking what is Agle, it’s more likely you will get the answer that Agile is about being flexible or about high efficiency. Some will say Agile is about having a Scrum Master, daily stand-up meetings and notes on a white board. I think Agile is much more than that and in this post I will tell you the answer, the short answer, I have found after many years looking.

Is it important to know what Agile actually is? Yes, of course. If you don’t know, how can you know in which direction to change your way of working when you decide to go Agile. By the way, Agile is a direction how to improve your way of working, not a place or a fixed description of how to work.

To make Agile easy to understand I will borrow a symbol from Lean, the house

Continue reading

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.

I morse höll vi (Mia och Mattias) ett lyckat föredrag för morgonpigga IT-chefer och andra som hade kommit till Crisp för att lära sig lite mer om hur man kan använda Agila kontrakt för att förbättra beställningar, relationer och leverera produkter och tjänster som skapar önskvärda effekter. Föreläsningen var ett smakprov på vad vi kommer