What should a struggling software development team do in a world of seemingly infinite improvement options?
Continue reading
A facilitation guide for team start ups and restarts
This guide explains the main ingredients necessary for facilitating a team start up and provides you with six example agendas. The guide includes questions to think about when you set up the facilitation and during the meeting.
The components needed for a team start up
- Purpose or mission -> why does the team exist?
- What is the business value?
- What does success look like?
- Understanding who the team members are:
- Clearly defined membership list -> who is on the team?
- Make sure that people get to know each other -> who are my team members as people?
- What are people’s skill sets? What do they know now, what do they want to get better at?
- Agree to how to work together
- What do team members expect from each other
- What behaviors does the team want to have
- How to talk to each other?
- How to split up work?
- What meetings/sync/feedback is needed
Questions to consider for each area
Continue reading
Bucket Estimation – How to estimate a really large backlog
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.
Large Backlog – To estimate or not, that is the question!
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.
The three states of working agreements
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”.
Trading control for great products – the Telia TV team example
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.
Doing Scrum with Multiple Teams: Comparing Scaling Frameworks
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
4+3+2+1 Team Success Factors
I’ve now published a new YouTube video where I present 4+3+2+1 Team Success Factors, a model that captures and describes what you can do to help make your team become strong and successful. These 10 factors are split into four groups. * The first group describes four dialogs we need to have as a team. * Next
Continue reading
Planning as a social event – scaling agile at LEGO
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
Continue reading
Scrum med flera team
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.
X-team Silos Game – getting in T-shape
Cross functional teams are complete in expertise but not necessarily collaborative. Sometimes team members hold on to their expertise too much and the team does not perform to its potential. This Lego game illuminates the difference when members allow themselves to take on tasks outside their expertise, being so called T-shaped. Play the game to kick-start your change and create collaboration.
More with LeSS: The Third Large-Scale Scrum Book
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.
Agile @ Lego – our slides from Passion for Projects
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.
The importance of size and proximity
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
Storlek och närhet har betydelse
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
Fluent@agile – visualizing your way of working
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
Scaling Agile (but not in the way you think…)
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.
Lean and agile at Edgeware
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
Continue reading
Agile Topics card deck
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 🙂
Dedicated Scrum Master or not?
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.
Guest post by Ellen Gottesdiener: Agile Product Ownership – 9 Essentials for Product Success
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
The Sprint Burndown is dead, long live Confidence Smileys
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.
A Scrum Product Owner Checklist as a mind map
If you wonder what a Scrum Product Owner need to do, here’s the checklist (in form of a mind map) for you!
Too small for a user story – bugs, fixes and support
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.
The House of Agile – A visualisation of the core of Agile
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
A Decade of Agile, A – F
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.
Continue reading
Concept Cubes
A while ago I was asked to help out create a checklist for a team, a checklist that could tell something about whether or not a user story was “good enough”. I opened PowerPoint and starting to ponder over how I could help. I immediately realized that a presentation would be boring, shown once and then forgotten, and not invite to curiosity. I put my laptop away and created a cube instead.
A couple of days later I showed it to a friend and colleague (Viktor Sessan, Agile Coach at Spotify), who were also very intrigued by the concept, and we started to talk about how to take this further.
This is the result 🙂 We believe that if you let an idea loose, and it is a good idea, great things will happen.
Time vs Story Points Estimation
One of the most common questions we get is whether to estimate in time or points. It seems like points are used only “to avoid thinking about time” and they are essentially the same. Wrong.
Let us give you the travel metaphor to give you an idea about how we are thinking.
Why I prefer ToDo over Trello for agile teams
The Gist
- ToDo has a flow. It knows about cycle times and about being DONE. Trello does not.
- ToDo has Planning Poker Estimates. Trello does not have any estimates.
- ToDo has automatic burn up charts. Trello does not.
- ToDo has swim lanes which groups cards by your dimensions. Trello does not.
- ToDo has Work-In-Progress limits. Trello does not.
- ToDo has upgrade possibilities to the full tool set of Projectplace. Trello has a bunch of plugins from different vendors of various quality.
Already convinced? Sign up for ToDo by Projectplace! Want to know more? Read on.