Att organisera flera Scrum team görs på en hel del olika sätt. Här beskriver vi likheter och skillnader mellan några av de ramverk som vi har stött på hos våra kunder och utbildare, LeSS, SAFe och Scrum@Scale.

Gemensamt för LeSS, SAFe och Scrum@Scale

I alla tre ramverken utgår man från att man i botten har vanliga Scrum-team som är tvärfunktionella och självorganiserande.

Man utgår också från att vi alltid försöker bryta ner kraven vertikalt, så att varje inkrement blir så litet som möjligt men ändå kan driftsättas separat.

Underförstått är även att man kör kontinuerlig integration och automatiserad regressionstestning, och  att man efter varje sprint har en produkt som går att driftsätta ifall man så väljer.

Continue reading

Last month, we had the pleasure of bringing Stephen Bungay to Crisp in Stockholm to share with us his wisdom and insights on how to use Strategy under uncertain conditions. I find this topic interesting, since the interative nature of Agile can trick management into believing either that they do not need to have a

The Agile ambition at Åland (a group of Islands between Sweden and Finland) is quite astonishing.  Besides being home to a bunch of cutting edge tech companies (who have been using Agile at Scale for 8+ years), they are also experimenting with using Agile in their society. Hm, Sweden suddenly feels sooo 90’s.. I had the privilege to keynote at their first Agile conference

Here are the slides from my Agile Africa keynote Alignment at Scale (or How to Not become Totally Unagile when you have Lots of Teams). Thanks for a great conference!

And thanks everyone for the Emma greeting, that sure made an 8 year girl very happy 🙂

(Emma was supposed to join me on this trip, but couldn’t make it because I had missed some required paperwork for travelling with minors to South Africa).

Continue reading

During extraordinary situations and crises, some people stand out and shine. One of these was Lottie Knutson. Lottie led the Crisis team at Fritidsresor during the Tsunami disaster in 2004. While governments were struggling to figure out what had happened, Lottie’s team was already hitting the ground running. Lottie will be speaking at Fast Feedback

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:

1. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
2. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum

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.

Continue reading

Here are the slides from our evening event Agile at scale that took place at Crisp on May 11th. Thanks everyone who attended for making this a great evening event!

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.

Whiteboard problem solving

Continue reading

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.
Continue reading

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. 🙂  

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:
Continue reading

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

(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

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