How to prepare and align as a leadership team for a major change in your organization

You are a senior leader in your organization, and you are facing some challenges. You have had that slow hunch for some time now that there are plenty of things that are just not right. Things beyond just individual isolated problems. People in your organization often bring up small things that should be looked at because they seem to be connected to plenty of recurring friction points in several places that hold people back.

You have also come to realize that there are a few big things we have to change to really tap into our potential. If we don’t, our goals may never come within reach. Maybe even worse, we may risk losing ground.

You feel you share this view with some of your colleagues on your senior leadership team. But you are not certain to what extent they see what you see and how they would explain what needs to change.

You want to take the initiative, but you are not sure about how.

Vad är ett Agilt mindset och hur beskriver man det?

Det är en fråga jag fick finna svar på i och med det sista tillfället i Scrum Master programmet Mia Pilebro (agil coach på arbetsförmedlingen) och jag genomförde på Arbetsförmedlingen. Denna artikel beskriver den definition jag landade i, resonemanget bakom samt varför detta är viktigt då man förändrar en organisation mot en Agil kultur och arbetssätt. De definitioner jag hittade när jag sökte svar på frågan kändes inte kompletta, enligt mitt tycke. Efter diskussion med mina kollegor på Crisp, och med Mia, landade jag i en definition som består av ett antal påståenden, hållningar och en intention.

Anti-Agile är en av mina favoritövningar att facilitera vid uppdrag hos kund. Använder man denna övningen internt inom en organisation så synliggör man ofta många dysfunktioner som finns inom organisationen; kulturellt, strukturellt och hur man arbetar. Övningen fungerar också väldigt bra som en murbräcka i att bryta tron att allt fungerar så bra som det är, och föreställningen att vi är så agila som vi möjligen kan bli. Det senare är många gånger en utmaning då en stark föreställning om sin egna förträfflighet är ett stort hinder att ta sig över som coach för att få kunder att öppna upp sig för coaching och vägledning i sin arbetssituation. 

Interview with Doug Kirkpatrick, startup team member of Morning Star and co-founder of the Morning Star Self-Management Institute. Famous for being built on their principles of self-management, which has led to that Morning Star is today the largest tomato processing in the world. Today Doug has left Morning Star to spread his experience as a speaker, author, and consultant.

In his book, Beyond Empowerment, Doug tells the story of how Morning Star became an example of true empowerment.  He tells us how they went beyond traditional ways of delegating (empowering) and creating a self-managed and truly empowered company. 

I found Morning Star to be an intriguing and fascinating story! I have been following the company for quite a while and recently had the fortune to meet with Doug. During one of our discussions, he shared the fascinating story and his experience as one of Morning Star’s original colleagues.

To learn how you can operate a large successful company in a very agile way based on self-management and a few simple but powerful organizational principles, then continue reading.

Inledning

Ser jag tillbaka på mina år som konsult och coach på Crisp har det skett en rätt stor förändring i vilka typer av uppdrag vi får. Många organisationer möter en allt mer föränderlig omvärld med snabbfotade kunder; är de inte nöjda med det utbud som organisationen levererar går det till en konkurrent i stället. Det räcker inte längre med att enskilda team fungerar bättre; hela organisationer behöver förbättras för att nödvändiga effekter skall skapas. 

För att lyckas med förändringsarbetet behöver vi:

• Utgå från att organisationer är komplexa system vilket kräver en organisk förändring snarare än ett plandrivet och mekaniskt sådan. 
• Genomför förändringen evolutionärt drivet genom de hinder som teamen upplever, 
• Successivt forma den struktur och arbetssätt som just den specifika organisationen bäst behöver för att leverera värde. 

In this blog post I want to share a powerful tool, the Leadership Health Check. It will help you become stronger as a management team and reveal improvement opportunities for how you, as a team of active servant leaders, better can enable the agile teams you support.

But first, let’s take it from the beginning.

One of my favourite exercises in my toolbox as an agile coach is something I learned during my years at Spotify; the Squad Health Check. It’s a retrospectives format, a self-evaluation workshop, in which the teams express how they feel they’re doing on wide variety of topics such as collaboration, value of what is delivered, ability to influence, received organizational support, etc. The result generates insights and commitment to actions of improvement for both the team and the supporting leadership. I love it because I believe it’s a great tool for strengthening autonomy, culture and continuous learning.

More than a year ago, a colleague at Spotify Georgiana Laura Levinta and I created a health check for the leadership of our Tribe (Tribe is a semi-autonomous department at Spotify encapsulating 4-8 teams and with a dedicated set of leaders and managers). Geo and I were inspired by the Squad Health Check, but the goal with this adoptation was to help the Tribe’s managers perform a self-evaluation of their ability to provide active supportive leadership to the squads within the tribe, and to generate a discussion on how they can improve as a team to be able to provide even better support.

Since then, I have together with my current client Casumo, adopted this for their context, culture and beliefs. We’ve run it several times with great success and value, both with the company’s leadership team but also on cluster level (semi-autonomous department). I believe the Team Health Check and the Leadership Health Check both are tremendously powerful; hence I want to unleash them to the wider agile community, hoping that more organizations will find them valuable and useful. Or at least be inspired by them, and then try something totally different.

Continue reading

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

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

Recruitment processes for agile team coaches differ greatly from one company to another. Jan Grape and Yassal Sundman share their insights on what makes for a good process based on their work recruiting coaches for their clients.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

Have you worked with teams that don’t communicate well? Or teams that don’t collaborate? What about teams that deliver late or with poor quality? Or maybe teams that are in constant negative conflict?

How do you tackle these issues? It might feel like you can fix everything by changing some of the people on the team. Before you do that, consider how you’ve set the stage for your team. Will removing and adding some people really solve all your problems? Or will the new members find themselves in the middle of a dysfunctional team, and end up unhappy and not delivering to their full potential?

Here are some of the things you can think about when you work with teams to create an environment where they can succeed.

Continue reading

For the past four years I’ve consulted for King as an agile team coach. It’s been a whirlwind of personal growth, learning about mobile games and meeting awesome people. I wrote about my biggest takeaways in an article on Crisp’s website. I am grateful for all the connections and insights that I’ve gained. I’m also

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

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

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

This is a strong retrospective for bringing issues up to the surface. Instead of just one person expressing an issue as a positive or a negative, the whole team feedbacks about the importance of the issue. The team then decides which issues to tackle. The retrospective also exposes issues where there is not common view, and highlights areas of alignment. It also allows the team to ask tough questions in a safe environment.Continue reading

You have a team member who has a pressing issue. It’s the single most important thing that they need to resolve. They explain the problem to a coworker, suggest a solution and ask for support… and all they get is a tepid response. This is a situation that repeats itself across workplaces every day. There are many reasons why people refrain from helping. They might not have the competence, they might disagree with the solution/problem or maybe they just don’t have the time. But what happens when they have the competence, agree with the assessment and could easily make time, but choose not to? Why don’t they? How do you help your team navigate these situations?

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

10 years ago, 2007, me and a few Crisp colleagues embarked on a mission: be best in Sweden at helping companies become agile. We had experienced first-hand the power of agile development, and wanted to use this newfound super-power to help both Crisp and our clients improve. Others joined us and – tadaa!  – Agile Crisplet was born (and the concept of crisplets)! That was the year I taught my first Certified ScrumMaster course together with Jeff Sutherland, co-creator of Scrum. Since then we’ve co-trained almost 30 courses! About 2-3 times per year. In fact, May 22-23 is our 10 year anniversary (join us at the course in Stockholm!).

Now 10 years has passed since our Agile Crisplet was formed, and I’m happy to see we have achieved more than we ever could have dreamed!

Dispensing with false humility here, we’ve somehow managed to become one of the world leaders in this field! Famous agile and lean experts partner with us. Super well-known product companies, large telecoms and banks, even government organizations, turn to us as first choice for agile guidance and training. Our videos and articles and books have racked up millions of hits, and we are basically overwhelmed with requests to do coaching, write book forewords, do conference talks and workshops, and run training courses. I’ve done almost 30 keynotes in 20+ countries. I’m amazed (and overwhelmed) every time I look at my inbox, I’ve had to hire an assistant just to turn down the 95% of all requests that we simply don’t have capacity to handle.

OK, so now what?

10 years is a long time, and now it’s time for a new focus! At least for me (Crisp is a no-CEO company where people are free to do whatever they want).

Continue reading

I recently attended a course (the excellent LeanUX course held by my colleague Martin Christensen) and again the topic of what a MVP is or is not came up in a discussion. In the Lean startup-world an MVP is defined as the smallest thing you can make to validate a hypothesis which helps you decide if you should continue developing something or if you should stop. For more information about this, I suggest you read Eric Ries’ blog post on the topic. However, in (very) many companies and organisations the term is used to describe the first version of a product released to the end customers. This “version one release MVP” usually contains as little functionality and features as is possible without making the end customers too upset, disappointed or unwilling to pay.

Another colleague of mine, Henrik Kniberg, wrote a quite thorough and lengthy blog post about MVPs a while back where he touched upon the point I’m about to make. While quite a few people see the different uses of the word MVP as problematic, I see it as a symptom of a need for a better word for describing at least one of its currently used meanings, i.e. the “version one release MVP”. Luckily enough a good friend and coworker gave me the answer to that need a few years ago: He called the first release of the hardware product we were working on at the time the “Minimum Loveable Product”.

Continue reading

A common pitfall for large and medium size organizations who are adopting Agile is to organize teams based on software component boundaries instead of feature teams. Some of the aspects of long term code ownership are more straightforward this way, but the negative consequences in terms of business agility and costs of coordination are huge. A few years back I designed a simulation exercise that I call Team Shapes which illustrates some of the issues and now I would like to share this simulation with the community.Continue reading

You have a feature to implement, and there are several implementation solutions available. How do you choose the best one?

Start out with all your potential solutions for a feature idea. Next, filter based on how the solutions perform using a set of verification methods. Finally, implement the feature knowing that you’ve found the solution that meets your needs.

Verification Methods

The following are the verification methods I’ve experienced most often on the projects:Continue reading

Conflicts in teams about how to work are common. There are expectations from team members on each other that aren’t being met. In a given team, members might be implicitly expected to perform a certain task. The team might have unspoken policies that seem to be common sense. Sometimes people pick up on these unspoken rules and implicit expectations, but when they don’t, you have a team in conflict. You can’t avoid all conflict (and a dose of healthy debate and discussion is good for teams), but you can help teams by explicitly defining the roles and working agreements. Instead of dealing with conflict after the fact, you start with discussion and agreement. The following workshop is the one I use with my teams and organizations.

Continue reading

I recently published a video exploring how an agile team based organization could look like. How does it function under the hood? In the video I also discussed how you get there.

I got tons of great feedback so I decided to provide the contents of the video in the format of a blog. If you prefer to read instead of watching a 11-minute-long video, then this is for you 🙂

Continue reading

The past couple of years I’ve been travelling back and forth to LEGO’s HQ in Billund Denmark, helping out with their agile journey. Super interesting! Learned more than we could ever fit in an article, but here’s an attempt to capture at least some of it, written together with LEGO colleague and co-instigator Eik Thyrsted