Do you feel like your organization’s development process delivers too little at too slow a pace? Your gut feeling is probably correct. In this post, I’ll describe three paradigms that result in near zero or even negative productivity.Continue reading
How to successfully drive initiatives, objectives or opportunities that require several squads (or teams) to succeed? How to do this in a way that respects the agile mindset without falling into the command-and-control trap? Today, this problem is more complex than it seems. We’ve designed and built our squads for self-organization and autonomy in theContinue reading
Are you struggling with improving at a fast enough pace? Perhaps you started your Scaled Agile journey by applying SAFe, parts of SAFe, or maybe even LeSS. What I’ve found is that once companies have started to apply a certain model, which represents one school of thought. they fail (or struggle hard..) to evolve beyondContinue 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.
Yuval is coming to Stockholm to teach a Scaled Agile class (Implementing SAFe) in January. I know Yuval from the Kanban community from a number of years back. We invited him because we know he shares the same pragmatic view on things as we do in Crisp. We made the interview in order for our audience to got to know himContinue reading
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’sContinue 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,Continue reading
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!Continue reading
Don’t stand in the way of great employees.
That’s one of the operational mantras that guide the finance technology company iZettle.
Two others are “Keep the startup spirit strong” and “Stay adaptable to changing market needs.”
In this blog post, we share some of the things we are implementing and tweaking at iZettle to keep producing great results and attracting in-demand, talented developers. My role has been to assist the tech development organization in making this work.
(Another blog post coming soon will cover the transformation of making the whole company agile, while this post focus on the practices that are put in place to keep a high performing, decentralized tech development organization at iZettle.)
Let’s begin by facing the reality of fast-growing startups.
The organizational challenges for most fast-growing startups
Most startups want a flat organization to keep their entrepreneurial juices flowing, but when new employees join in a steady stream there eventually comes the point where the founders or upper management feel overwhelmed by chaos.
Things get confusing.
Employees aren’t seen.
No one seems to know what’s going on.
What usually happens for most start-ups at this point is that bureaucracy processes start piling up. Layers of management are added, and project managers are introduced to coordinate the chaotic environment. And so are written reports for managers to send to upper management, and silos are building up between different departments. And decisions are taken somewhere else.
And then what happens?
Usually, entrepreneurial enthusiasm suffers and so does talent motivation and speed of innovation.
And that is exactly what iZettle wants to prevent.
But that is easier said than done when a company grows like a wildfire.
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 🙂
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 ThyrstedContinue reading
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.
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).
The talk is about Spotify’s current approach to getting aligned as a company. It covers:
- what problem we’re trying to solve, and how we’ve gone through two other models (OKR and Priorities & Achievements) before arriving at our current model
- how we define “Bets” using the DIBB framework (Data-Insight-Belief-Bet)
- how we prioritize bets using stack-ranking based on company beliefs and north star goals
- how we visualize bets on a kanban-like company level board, and group them into Now – Next – Later columns
- how different parts of the company visualize their own bets and align with higher level bets, using interlinked bet boards.
- how we synchronize and prioritize our work using different cadences at different levels of the company.
- how this model is used to support squad autonomy
- our challenges and learnings with this so far
Holy crap how did I manage to cover all that in 10 minutes?! Guess I talked fast 🙂
Some sample slides below.
Hi! Here’s the video of our presentation “Learnings from SAFe @ LEGO” at LKCE 2015. psst: Meet LEGO f2f at this years Fastfeedback conference 2016 (Stockholm, Sept 21-22:nd). This years focus topic is “Strategy – Turning insight to action”. fastfeedback.se Cheers MattiasContinue reading
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:
- Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
- 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.
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 our talk Agile @ Lego at Passion for Projects in Uppsala. Enjoyed discussing this stuff with project managers and the like from all sorts of industries. A common theme from the conference was the power of self-organization, and the role of leadership in creating the right context for self-organization to happen. Our talk provided a real-life large scale example of this.
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. 🙂Continue reading
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:
Hi! Here’s the video me and Eik’s presentation – “Learnings from SAFe @LEGO” (presentation at LKCE – Lean Kanban Central Europe, Nov 2015). Best quote: “..this looks exacly like what my 6 year son does in kindergarden” 🙂 Cheers MattiasContinue 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.
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 coachesContinue 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 EdgewareContinue 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.
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
Crisp has the luxury of working with small, medium, big and very big companies. We help through providing education. We coach and mentor projects, teams and organizations adopt and master the agile way of working. Last week we at Crisp invited a couple of our clients to participate in a round table discussion regarding agile transformations. The unifying theme were the challenges surrounding large scale agile implementations.
We at Crisp offered a platform and forum to share and learn in a neutral and safe environment. Four companies attended. One to four participants from each company. The participants were directly involved, and in one way or the other, responsible for the agile transformation taking place in their respective company. The size of the department or company involved in the change varied from 300 – 1500 people.
Building a well-functioning software delivery team is complicated. There are many factors to consider. Current team (if any), needed skills, available people, company politics etc.
There are some fundamentals that often (but not always) seem to work.
My fundamental principles for teams
- 5-9 people
- Dedicated team members (belong to only one team)
I find these principles to be a useful basis for discussion, when helping managers configure their teams.
The principles are goals, and one must realize that all cannot be achieved all of the time, nor instantly.
Just finished my session at SDC 2012 where I’m arguing for less hierarchy and economically aligned decision rules that enables local teams to do tradeoffs. Mary Poppendieck commented it as “traditional product management”. Maybe that’s where we are heading 🙂 Anyway, here are the slidesContinue reading