Consumer behaviors are transforming and the speed of IT development is accellerating.  Launching new products is becoming ever easier. This means new challenges – and new opportunities – for marketing departments.  The companies that learn to master Agile marketing, in a faster changing world, stands a better chance of building long-lasting relationships with their customers.

Ever heard this conversation play out? Manager 1: “We should adopt scaling framework Y.” Manager 2: “But scaling framework Y doesn’t have a recipe for baking cookies. So we need to do X.” Manager 3: “Whut? You’re both wrong. We have Agile teams. We’re good!” In fact, each statement above can be wrong. So the

I suspect that running a session with a team to help them bootstrap a Working Agreement, is the single most common workshop I’ve been facilitating the last couple of years. And I’ve learned a lot of what works for me (and what doesn’t work). In my experience, this approach works equally well for the agile team, the department management group and the steering board team. This blog is me documenting how I ended up facilitating these sessions.

For me, a Working Agreement captures the expectations we have on each other within the team when we collaborate and communicate. I’ve seen teams call it “Code of Conduct” or “Ways of Working”. I call it Working Agreement. You call it whatever makes sense for you.

Running a Working Agreement workshop as early as possible is crucial for setting the team up for success. Preferably it’s done during the team’s two-day kick-off offsite, or at least within the first few weeks as a planned structured workshop.

Continue reading

Here are the slides from my keynote “Agile Everywhere” at Lean Forum, Gothenburg.

Great conference, great atmosphere! Very inspiring to hang out with a bunch of super-experienced practitioners. I love conferences where it’s clear that everyone is there to learn and spread knowledge. It’s funny though, in lean circles like this I’m often known as the Agile Guy, while in agile circles I’m often known as the Lean Guy 🙂

Here are some sample pics.

Continue reading

On September the 19th 2018, Joshua Kerivesky, creator of Modern Agile, gave this talk “Are you curious?” at Crisp Stockholm. This is the video recording from that evening. The seminar is 60 minutes, followed by 30 minutes of Q&A. About the talk: ARE YOU CURIOUS? Learning is key to improving. Yet without curiosity, learning stagnates.

Here is the flipchart from my talk “Confessions of a Change Agent” at Agile Rock conference in Kiev. Click for a zoomed in version.

Continue reading

Here are the slides from my agile intro at KTH last week. Hope you enjoyed it!

Some sample pics:

Continue reading

In the scaled Agile framework, one key role is the Release Train Engineer (RTE). But who should I look for to fill this role? What are the first few process improvements experienced RTE’s typically do? Yuval Yeret (AgileSparks) and Mattias Skarin (Crisp) took the time to discuss the traits of a good RTE.

What are the traits of a good RTE?

Yuval: The easy answer to this question is that you are looking for a Scrum master for a team of teams. Going beyond that, when it comes to specific traits, you are looking for someone who cares about process and improvements, someone who has the ability to orchestrate things. But at the same time, someone who also knows when to step back and let the teams organize themselves. A good RTE is a great communicator and can see and understand what is happening.

Mattias: Firstly, a good RTE should be a people person, someone you’d like to talk to and bounce ideas with. Someone who builds trust and energy with their presence. In essence, a good RTE is the Uber Scrum master across teams. Secondly, a good RTE is systematic and makes sure the process events are run and planned in advance. Thirdly, a good RTE should be a good problem solver.

Continue reading

Åland has one of the coolest visions out there – build an Agile society. They also arrange Agile Islands, a small conference but with sharp content. This year I had the pleasure to speak, so I decided to shed some light on “Decision making under uncertainty”, which is a fascinating subject. Here are the slides. Cheres

What happens when you use Agile in marketing? Zalando have been using Lean and Agile tools inside marketing for some time. That makes up an unique and interesting case study, from a company pushing the boundaries. Here’s an interview with Julia Kummel, sharing their experiences from the journey: psst: Do you want to learn how

The Agile Manifesto has been around since 2001, and agile ways of working have existed long before that. So what is this thing called Modern Agile? Is the manifesto outdated and needs to be replaced? All good questions, but let’s start with taking a look on what Modern Agile is.

Continue reading

Racing is essentially product development on steroids. For a number of years I’ve been following the development of a promising young racing driver – Linus Lundqvist.  Anyone with a little bit of knowledge about racing,knows that there are many components that need to work together, in order to forge success.  Talant – yes. Resources –

So you have a LARGE backlog and you have decided that you need to estimate it.

Not on board? Still undecided? Go read my previous post on the tradeoffs between estimating and not estimating large backlogs.

Still reading? Ok, let’s get to it!

You can do larger scale estimation in MANY ways. What I will share with you here is just one way I have found to do it effectively, with enough accuracy at a reasonable cost. It requires some pre-conditions, such as having a team with an established way of working and some way of estimating on the team level, so it may not fit your situation. But if it does it is probably worth your time to check out.

Continue reading

Estimation seems to have gotten a bit of a bad reputation lately.

One misconception I sometimes see is that estimation beyond just a few weeks is “not agile”. Another trend is that some people advocate against doing estimation at all mostly because they view it as a beginner tool, so by not estimating we are no longer beginners.

To me doing estimation or not does not really say much about “how agile you are”. The way I look at it is that we should estimate when the reasons to do so outweigh the reasons not to do so. That simple.

In some scenarios this also includes doing estimation of large backlogs.

So in this article I want to share what I see as some of the reasons FOR and AGAINST doing estimation of a larger backlog. You can then decide for yourself if your situation justifies doing it or not.

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

Continue reading

Continue reading

The role or function of an agile coach can be be a bit of a challenge to wrap your head around if it is new to you. Depending on your situation and on agreements with people in your organization, an agile coach could work with a wide range of responsibilities. It could be working closely

Not every company starts from a green field. Many carry legacy. So how do you kickstart Agile and get traction in an organisation with scale?  We can learn lessons from SimCorp,  a successful provider for asset management solutions, who runs 500 developers across 4 sites and went from 0 to 8 release trains in 14 months.  Here’s

In modern software development there are three development practices that everyone should strive to apply:

• Automated testing
• Pair or mob programming
• TDD, test driven development

After many years of using and researching these practices in the development community there is no longer any question whether these engineering practices bring value or not – they do. It’s not a matter of opinion, it’s a matter of fact. We know that now.

Continue reading

So your organisation is going ”agile” and talking about ”collaborations” between teams? You, as the big boss, are starting to feel powerless and not in control of the efficiency of YOUR teams? Let me give some tips on how to turn that around so all progress can be traced back to you. I mean, as their mighty leader, you do deserve all the credit for their work.

Continue reading

Here are my slides from today’s talk “Scaling Agile @ LEGO and Spotify” at EA träff in Stockholm (EA = enterprise architecture). Fun to hang out with enterprise architects and learn what that’s all about 🙂

Some sample slides from my talk:

Continue reading

How do you leapfrog a successful waterfall company into Scaled Agile? How do you transition into Agile when you have legacy? When your company is already successful in what it does and when it carries legacy, transitioning into Agile is a more complex challenge than starting off Agile in a green field environment. After all,

Here are the slides for my talk “Agile, where are we at?” from USI conference in Paris (USI = “unexpected sources of inspiration”) in June. One of the coolest conferences I’ve ever attended!

My talk was an attempt to take a step back and look at the big picture, and also speculate about the future of agile. I was also interviewed a couple of times, and the talk was also recorded. Here are links:

• Interview “Agile is about taming complexity”
• Interview “Etre agile, c’est savoir dompter la complexité“
• Interview “L’évolution de la culture agile en entreprise“
• Video recording of the talk

2 of my kids tagged along on the trip, we took the train to make it extra adventurous (and also to mind the climate). It’s a long way (24 hours each way), but we made good use of the time!

Continue reading

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.

Continue reading

Note: Access to Google Docs and Feedback has been disabled.

Back in 2013 I created a deck of cards with questions for the agile team, called “Jimmy Cards”. The questions on the cards were designed to ignite exciting discussion for teams to get to know each other and grow as a team.

I’ve received so much great feedback and appreciation over the years since. This feedback inspired me to create two more decks, the Black Deck and the Blue Deck. The Black Deck is for mature agile teams. The Blue Deck for leadership teams.

These have been in the working for over a year now but now I feel it’s time I wrap up my work and print them. I’m however not confident on the level of quality just yet, so this blog is a plead for help.

Continue reading

Testing is a topic covered with mysteries and misunderstandings. Some people believe that testing is simply a verification of a specification. Others rely on a false assumption that everything can be automated and there is no need involving test engineer into anything else than writing automated scripts. Many think that quality is a responsibility of only a few folks in the company and should not bother the rest.

My views are different to the ones stated above, as my expectations on testing are alike to other engineering disciplines, for example, programming.

On high level I am following 3 main principles:

1. Testing is a creative activity.
2. What can be automated should be automated.
3. Quality is everyone’s responsibility.

Continue reading

Agile development with short release cycles have been here for a while now. Most of us want fast feedback loops and many even Continuous Delivery with changes in production software everyday. However, most of us also want secure software and the question is: Can security engineering keep up the pace? A fast feedback that your production website has been hacked is not so nice.

Security is a quality attribute of your software, just like performance. If you don’t want to be surprised by bad performance in production, what do you do? You test and design for it of course and you preferably do so continuously from the start.

In my experience, the same however cannot be said of security. It is very often relegated to a once a year penetration-test activity. Not really an agile way of working is it? Not a secure one either since untested software is released as often as everyday. There must be a better way of working which allows us to both work in an agile way and to verify security on the way.

In the security field people like Gary McGraw have long been advocating ways of “Building Security In”. The Microsoft MVP Troy Hunt also proposes that you should “Hack yourself first”, instead of just waiting for the pentesters. Shouldn’t it be possible to weave these security activities into the process the same way as it is possible with normal testing activities using TDD? Indeed I, as well others believe it is so. Let’s look at how small extensions to an agile process can work in this direction.

Extending Sprint planning to deal with security

To start off you must first know what the requirements are. In a normal agile project this is done by eliciting User Stories from the customer or the Product Owner.

Let’s take an example of an online e-Commerce site. A User Story might be “As a customer I want to be able to add a review of a product so that information about products can be shared between customers”.

This works very well for traditional functional requirements, but for non-functional requirements a little extra thought is needed. In the case of security requirements it is often useful to state a requirement in a scenario that should NOT happen. In our case we shall call these scenarios “Abuser Stories”. These stories are non-technical descriptions of bad things you want to make sure you avoid. An Abuser story for this site might be:

“An attacker uses the Review Product-function to spread malicious Javascript”. Another might be: “An attacker abuses the Review Product-function to gain unlimited access to the database”.
A Product Owner might not be able to come up with these stories himself, but might need the help of a security engineer to help him with finding these threat scenarios.

Continue reading

There will always be a productivity dip for the team when a new member joins. The question is not if it is going to happen, but how much will productivity dip and for how long. Imagine if you could onboard new team members with a minimum of productivity loss.

Continue reading

Today I met a crowd I do not bump in to all that often; project managers. I decided to share insights from Agile projects, stretching from Hospitals to Digitilization, how they simplified and speeded up their pre-studies. Learning how to do so well, helps avoiding the “we have to speed up implementation, to make up

Our article about Scaled Scrum has been published on InfoQ. In the article we describe the basics of LeSS, SAFe, and  Scrum@Scale and show the similarities and differences between them You find the article about Scaled Scrum at InfoQ. Enjoy!