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
Har nött och blött en översättning av CYNEFIN på svenska. Så här ser det ut just nu: Kom gärna med förslag på förbättringar!
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?
When creating a team meant to work in an agile setting, most people remember that there are supposed to be more people in it than developers. They might skim through the Scrum Guide and fill the roles of Product Owner and Scrum Master. What few do is to think about what other roles that are really needed.Continue reading
Efter ha läst boken “Leadership Agility” av Bill Joiner och Stephen Josephs har mina verktyg att hantera utmanande situationer i min coaching utökats.
Ledarskap kopplad till Piagets utvecklingsteori
Underlaget till boken “Leadership Agility” är mångårig forskning kring ledarskap kopplad till Piagets utvecklingsteori.
Enligt den genomgår barnet och sedan den unge vuxne ett antal mognadssteg och man kan också klassificera ledarskap utifrån var individen är i denna mognadsprocess. För mig har det varit och är en modell som jag har stor nytta av i min coaching.
As a high-performing tech professional, it’s useful to constantly fine-tune your ability to add value.
For example, you might ask yourself at work:
What is the one thing we can change in our product, service or in the way we work together that can bring more value to our customers or the team?
This philosophy of looking for things that can add value can also be used for your personal and professional development.
To give you some inspiration, here are some of the real life small changes and habits that our team members at Crisp have made that have added tremendous value to our personal and work lives.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
When the BBC published their “No CEO” piece where Crisp is featured with an article and a 4 minute video, there were a lot of reactions. Friends cheered on Facebook. Colleagues gave a thumbs up on LinkedIn. The article was featured on Hacker News and Slashdot. Here are our reflections on some of the comments we found.
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.
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.
Design Studio is a design method that focus on a specific format for collaboration to create a shared understanding of the problem. This is done by, together as a team, coming up with a solid foundation for a design solving the problem.
Here’s the short version:
The overall rule for Design Studio is to never dwell on details to get most value out of the least amount of time. After a Design Studio session, the UX designer, have plenty of material to work with to take the design towards implementation. Try it out in the course Agile UX or read on to find out the details.
I gave a lightning talk at tonight’s Lean Tribe Gathering in Stockholm about A/B testing at King, how we develop games, features and decide which improvements to make. Here are my slides and notes from the presentation.
I love visualization and I collect visualizations. Why? Well, I love drawing and have a very visual way of thinking. But more importantly, I’ve been amazed time and time again, how great an impact a valuable and useful visualization can have on a team’s ability to focus, collaborate, and adopt new behaviour.
This passion for post-its and whiteboards finally manifested itself in the form of a book; “Toolbox for the Agile Coach: Visualization Examples – How great teams visualize their work”. Not only am I proud and happy of the final result, I’m also very excited about the way it came about. This blog is about how I wrote a book, publicly and collaboratively online, with frequent increments and tight feedback loops.
Jimmy Janlén wanted to make a move star out of me, so he persuaded me to do a short video of an earlier blogpost. So here it is, a 3 minute video clip! Enjoy! /Hans P.S. If you want to read instead, you’ll find the written English version here, and the Swedish version here.
Continue reading
During my ongoing search to find new and improved ways to grow more human centric, high performing workplaces I was introduced to Sociocracy and Holacracy in 2012. I was immediately intrigued by the underlying principles and fundaments, especially with sociocracy and have been experimenting ever since. With the recent emergence of Sociocracy 3.0 I’ve turned my attention towards learning about and experimenting with it’s modular, optional framework of principles based patterns, with fantastic results.
S3 is a free and open, principles based framework of patterns for people wishing to collaborate more effectively and benefit from agile principles at scale, regardless of their chosen approach to product development and service delivery. It provides a rich variety of compatible options to choose from and adapt, according to unique context and needs, building on sociocratic practices and integrating principles from Agile / Lean to dynamically steer and evolve organization.
In my team, we are working on improving real-time performance for our main service. The goal is to have response times below 100 ms in the 95th percentile and below 200 ms in the 99th percentile for certain database volumes and request frequencies.
We don’t know what will be needed to reach this goal. We have some ideas, but we don’t know which one, or which ones will do the trick. We call these ideas “experiments”.
We can estimate each experiment, but we don’t know how many we will need to do to reach the goal.
This is the story of how we apply the scientific method to working with performance improvements.
Since I have found the Ansible documentation to be lacking, and StackOverflow insufficient in this matter, I feel the need to share how you can append to a list using Ansible.
I’ve created a demonstration playbook and published it on GitHub. See: https://github.com/betrcode/ansible-append-list
Curious about unconferences? Perhaps you’re thinking of running one? Or maybe you are invited to an unconference or open space, and the organizer sent you this link to describe how it works? If so you’re in the right place!
This doc is a high-level summary. For more details and facilitation instructions, see the ebook How to run an internal unconference.
An unconference is basically a conference without predefined topics. There is a high level structure and theme, but actual topics are generated by the participants on the spot, and breakout groups are formed dynamically based on interest and relevance.
If you know what an Open Space is, an unconference is really just an Open Space event with some added structure at the end to make it fit for company-internal events.
This is a pretty awesome format for cases where you want a super-flexible and participant-driven agenda and structure. I’ve been using it for years at Crisp, Spotify, Lego, and other clients, and it tends to spread virally within organizations. I’ve done it mostly with groups of 20-80 people, and people often say things like “all conferences should be like this” or “best conference I’ve ever been to!”
Hi! I’ve updated the Kanban boards collection with examples from departements outside IT, Product portfolio and Corporate Legal. Download “10 kanban boards and their context” as pdf
Continue 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:
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.
The Spotify ‘model’ was presented in 2012 and has stired a lot of interest in the agile community and the software industry in general. In May I was asked to talk about this a the Bay Area Agile Leadership Network meetup in San Francisco (where I at that time was working as an agile coach
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
Continuous discovery means an open backlog where everything is considered speculation and hypothesis. Continuous validation means that the user experience is validated for each release, rather than up front. This may sound like big budget to you, but let me give you a case study, about how a single team accomplished it on a tight budget.
A small team with a small budget has the advantage of not losing its head with big ideas from experts in different fields, be it architecture or user experience. The budget constraint sharpens your effort in a way that could be healthy even to a larger team.
Candy Crush Soda releases a new version of the game on all platforms every other week, year round. I’ve written about the delivery pipeline and the challenges the team faces on King’s tech blog: https://techblog.king.com/candy-crush-soda-saga-delivery-pipeline/ Previous posts about working with the Soda team: How We Developed Candy Crush Soda Saga What Should We Build Next? Get in touch
Continue reading
I’m currently coaching a team with several stakeholders in different parts of the organization. It’s difficult to know who to talk to when decisions need to be made. The line between what the team can decide about and what the stakeholders need to be involved in is also blurry. To help create more clarity and a better collaborative environment with our stakeholders we decided to create a delegation board. The meetings we ran this week were appreciated by everybody, so I thought I would share what we did and what we learned.
The www.crisp.se website is based on WordPress, with a custom Crisp theme.
This is the story about how we’ve developed our custom WordPress theme, how we’ve made it easy for any Crisper and external consultants to work on the theme, how we’ve setup version control, continuous delivery, staging and production environments on Amazon Web Services (AWS). And how all of this is setup with absolutely no automated tests whatsoever.
Elephants are not giraffes and user stories are not requirements. They share some traits and you may find them in the same context, but that does not make them the same. Despite that, many believe that user stories are the new requirements because there has to be requirements for a project, right? I give that a double “no”, they are not requirements and that is not anything we really need. User stories are about being able to explore options and seize opportunities. Requirements are about deciding up front and sticking with that.
Daniel and Martin have been in the same team since the beginning of summer and they’ve been collaborating in an unconventional way. Yassal interviews them to understand what’s been going on.
You’ve been successfully using mob programming with your team at Expressen for the past 6 months. How did you get started?
Daniel: The project started without any tech solutions in mind. We decided as a team that mob programming was a good way to figure out what tech stack to use. We had no backlog, but we sort of knew what we needed to do
Martin: I remember proposing this as the best way to do discovery work from a tech perspective. We didn’t know what language or tech platform we were aiming for, and this way we would learn more quickly as a team and could come to a decision.
So, what is mob programming anyway?
Daniel: I don’t really care about the formal definition, to me it’s group programming rather than pair programming. One person is at the keyboard and the others act as support, coming up with suggestions, or researching potential solutions. This helps the whole team stay on the same page, and makes sure that we’re all learning at the same pace.
Hej kära läsare! Mitt namn är Martin och jag är en “process-aholic”. Jag har sett processer (eller avsaknaden av dem) överallt sedan jag var barn. Jag har sett en del människor som gör saker på “fel” sätt och en del människor som gör saker på “rätt” sätt. På universitetet lärde jag mig dock att inte ens när det kommer till processer är livet svart eller vitt, men jag förstod aldrig hur jag skulle kunna särskilja en “bättre” processen från en “sämre”. 11 år senare när jag fann Scrum blev jag glad över att hitta en process med inbyggd processförbättring. Jag kunde äntligen experimentera och sedan utvärdera om det hela blev bättre eller sämre. När jag insåg att de flesta team körde Scrum utan denna del, bestämde jag mig för att försöka lära världen ämnet kontinuerlig förbättring. Detta är ett sådant försök, men det var nog uppenbart…
Vad jag har saknat när jag predikat om tillbakablickar/retrospektiv är tydliga och konsekventa mål. Att nyttja de fantastiska grundvärden som agila metoder vilar på, såsom Extreme Programmings kommunikation, återkoppling, enkelhet och mod (inklusive respekt från version 2) och Scrums öppenhet, engagemang, fokus, etc, har hjälpt mig att sikta bättre på kort sikt. Men det var inte förrän jag lärde mig om två specifika (och överlappande) mognadsmodeller, en via Torbjörn Gyllebring och en via min kollega Fredrik Lingren (tack så mycket till er båda!) som jag förstod hur jag skulle kunna tillämpa en mer fokuserad strategi för ständiga förbättringar. Detta är min strategi:
