A couple of weeks ago I was invited to give a keynote presentation at an internal innovation event hosted by one of the more pioneering product companies here in the Stockholm area.
The organizers requested the name of their organization to remain undisclosed, but were happy to see a video recording of the talk shared publicly. The presentation was prepared by me and Emil Vikström together and now that it is available I figured I might as well share it here on the blog as well.
So here it is!
So how do you go about implementing a zero bug policy when you’ve got a long list of real bugs and users and stakeholders who want things fixed? I’ve been getting this question a lot after posting my blog entry Stop Managing Bugs, Start Focusing on Quality and creating the app and cards to help with the day-to-day maintenance of a zero bug policy. So over the summer I wrote a little story board book that will help you get started. Pass by the Crisp office if you’re in Stockholm to pick up a copy, or download the pdf on LeanPub. You can always find more information at FixItNowOrDeleteIt.com
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 to get started with Agile in marketing? Try out brand new Agile Marketing class in September.
/Mattias
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.
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 – yes. But – as important – is how you put them to use. Here’s where Lean and Agile thinking comes into play.
We got the chance to interview Linus and his race engineer at LL Motorsports, Bo Hanner, on how they have used Lean and Agile thinking, in order to keep an edge on competition.
Where is Linus now? While it still early in the season and many races to go, Linus has put himself in a favourable position, as a frontrunner in the Formula 3 UK championship.
If you would like to dig deeper and learn how a race team works, or how they use Lean/Agile to keep an edge on competition, then take the chanse and meet Linus and LL motorsports here in Stockholm on October the 18:th, at the “Agile Procurement for Business Agility” conference.
“Fix It Now or Delete It” is a simple method that gives you two options for dealing with a bug: Fix It Now, or Delete It! I wrote a blog entry about this method a few months ago, and now there are lots of resources to help you talk to your team about simplifying the way you deal with bugs.
As part of the preparations for the lightning talk I gave last week at Agila Sverige, I created an info-graphic, cards, a mobile app (thanks to Daniel Sundman for implementing it in react-native) for iOS and Android, and a website. There’s even a t-shirt or two.
I hope that these resources will help you and your team in your journey to a successful zero-bug policy!
ps Yes, I realize this was going overboard for a 10 minute talk, but I hope you enjoy it 🙂 There’s also a little picture book in the making.
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.
This article is the third in a series about system testing:
JUnit is poorly named. Given the name, people tend to think that it should only be used to write Java unit tests. And then people feel a bit hesitant about writing their integration tests with JUnit too. When they start with system tests, they often think they need another driver for their tests. Sure, maybe using another abstraction layer and a custom domain specific language (BDD), you can make the tests more readable for a non-programmer. That often comes at the cost of making the tests less readable for the programmers. And if we are honest, who’s going to read the tests the most? Perhaps just naming test classes and methods well and writing readable code can suffice?
This article is the second in a series about system testing:
You may want to read Dockerized testing vs end-to-end testing first.
A prerequisite for running your tests against a dockerized environment is of course that the service you want to test is packaged as a Docker image. Also, all of the services which the System Under Test (SUT) depends on needs to be dockerized. If you don’t have that, your environment is not fully dockerized and you will suffer the consequences of having to test against external services.
If your SUT is packaged as a Docker image and has no dependencies on other services, you can just start it using “docker run” and run your tests against it. However, usually services have one or more dependencies to other services, such as its own database, a queue and perhaps a external RESTish service that returns nasty XML. You want each of these services in their own container. To spin up a bunch of docker containers, you can use docker-compose.
I recently rewrote the end-to-end tests for a service. This brought up the question of what we should test in the end-to-end (e2e) tests vs our Dockerized tests.
This article is the first in a series about system testing:
Since the original e2e tests were written, we (my team) have also introduced another type of tests. We call them “dockerized system tests”. These are similar to the e2e tests. They also test the connections between services in the system, and how the system works as a whole. One key difference between e2e tests and dockerized tests is that the dockerized tests do not test the system when it is deployed the way we deploy it in staging and production environments. Our dockerized tests bring up all services in a single machine, and we usually don’t set up redundancy, clustering, load balancers and such things.
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.
As a product owner, your job is to make assumptions, or hypotheses. (Hypothesis-driven product discovery, anyone?) You assume that your priorities will be the best outcome, the shortest time to market or something else. But how good are your assumption when it comes to reality? Did that sale increase occur and was it thanks to your great mind or just pure luck? Do people around you understand and help you with your assumptions? Impact mapping is a lightweight tool that helps you with quantifying and communicating your assumptions.
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”.
Meet Enspiral, with the inspiring purpose of “More people working on stuff that matters”. This autumn I finally got to meet Joshua Vial from Enspiral when he and his colleague Susan Basterfield visited Stockholm for keynoting at the Agile People Sweden Conference. This was the first time Joshua visited us but Susan, I had already had the privilege to get to know last year when we hosted a workshop at Crisp on the Enspiral European tour.
Joshua Vial and Susan Basterfield from Enspiral
After the conference, I had a chance to sit down with Joshua and Susan to chat about Enspiral, social entrepreneurship, doing things that matters and the future of work. As we sat down and chatted and realized that we are a tribe of changemakers separated at birth, or at very least sharing latent strands of DNA. How else can you explain the exquisite similarities of two entrepreneurial collectives from the polar opposites of the planet? Crisp and Enspiral are like long-lost cousins. We are both two companies with a belief that there are better ways of organizing and leading work than the traditional way.
These new ways are based on principles of self-management, agility, openness, and participation. We believe organizations like this are more rewarding and purposeful for the people working in them. This will lead to that people’s potential are freed up to do more good and impactful things in the world.
Before there was the concept of frontend and backend developers, there were just developers and I was one of them. We did everything from HTML to SQL and it was not hard. Then something happened, JavaScript became popular. After years of server side rendering and thin clients, the pendulum was swinging back to fat clients again. And I was a backend developer.
Believe me, I have tried to get on the train with JavaScript and its hose of new frameworks. I took courses in JavaScript. I wrote applications using Meteor, tried Angular and React. But what I never managed to do, is liking it. There is simply to many ways of shooting yourself in the foot. And all these frameworks that come and go points to something, perhaps we are trying to fix the wrong problem. I suspect it is the foundation itself, JavaScript.
What I’ve strived for in all my jobs and assignments is to combine the best discovery methods with the best delivery methods, of course in the best possible way. I have tried and tested a lot of popular frameworks and ways of working, and the following list of principles is my conclusion. read more
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. read more
In the pursuit to automate testing to create faster feedback loops and build quality in, some teams forget the value of manual testing. In my experience, without manual testing (as well) we are toast.
You’re coaching a new team! Woohoo! You have so many ideas! You’re going to help make the team’s world a better place! All the things that you’ll do! Then you get there. The music stops, and the frustration sets in. You’re trying to help but team members come late to the daily scrums, they don’t update the information radiators and they’re zoning out during meetings. You’re not sure what to do anymore. What happened? You feel undermined and unappreciated. Aren’t you the expert? Isn’t that why you got this team to begin with? Why won’t they let you help them?
Let’s look at the journey of joining a team and how you can pave the way for a successful coaching experience! read more
How should you structure your Ansible variables in playbooks calling cloud modules? Ansible has extensive support for variables at different levels (there are 21 different levels!).
The inventory group_vars and host_vars offer enough flexibility for many use cases. However, when you are setting up cloud infrastructure, you don’t really have any hosts yet. Maybe you are setting up load balancers, instances, security groups and such things. Perhaps you want to setup the same things in several different environments (like “staging” and “production”). You want to re-use the same playbook, but adapt what it does by using different variable values in different environments.
In this post, I will demonstrate a way to structure Ansible variables in a playbook which pretends to setup a AWS AutoScalingGroup. I will show how you can separate the configuration for different environments by using a inventory directory. As a bonus, I will give you a neat trick to automatically load a extra variable file for each environment. We will use this to load a separate secrets file which is encrypted with git-crypt.
I had the opportunity to make an interview with Dave Snowden as he visited Crisp for his latest Master Class end of November, titled “What´s next for agile”. We explored the topic of What´s next for agile, new updates to the Cynefin model, now called Cynefin liminal. Check out the video below to of my interview with Dave (14 min).
Agile is increasingly becoming commodified and what are the opportunity for smaller Agile companies and anyone believing in the original Agile movement? (0:20). h “The key now is to produce new high energy efficient, radical, high value, innovations around the core of what Agile has become”
Do you have a long list of bugs? You definitely want to have a zero bug policy, but now you have all sorts of minors, majors, and criticals. You’re not really sure how to get to zero bugs (were you ever there to begin with?). You have spikes where you fix the bugs and your graphs show a steep downward drop, only for them to turn upwards again and reach new heights. Just maintaining the list of bugs is a full time job! To add insult to injury, when a team member finally gets around to looking at a bug, they usually find that it’s outdated, not reproducible or part of some long forgotten removed functionality.
There has to be a better way! How can you shift the focus from managing bugs to ensuring quality? Here’s a system that’s easy to start using, and rewarding when you follow it. read more
One of the most exciting aspects of working as an Agile Coach is applying what we know to other industries. Especially when what we do serves the greater good. We’re both always actively looking for opportunities to work with integration initiatives, and in this case we supported an initiative to improve integration of newcomers. Here’s how we facilitated the 2018 kick off meeting for Järfälla municipality’s Interfaith Council. read more
If you are a meat eater and you want to become more of a vegetarian (or at least eat more plant stuff and less meat stuff), and you kind of struggle with that because meat tastes good and you’re used to eating it, then this guide is for you! A short pragmatic guide for the aspirational vegetarian who still wants to enjoy good food.
I’ve been on this journey (and struggling, I admit) for about a year and half. I’m nowhere near full vegetarian, but I’ve cut down meat consumption by more than half, and will keep trying to reduce it. The nice thing (and a bit of a surprise) is that it doesn’t feel like a personal sacrifice at all!
Here are some tips if you want to join in:
Meat Eater’s non-dogmatic guide to become more vegetarian
(posted on GoClimateNeutral blog)
When you use Ansible to provision hosts, running a task on a set of hosts in parallel is not a problem. You simply use the `serial` keyword in a playbook. See: http://docs.ansible.com/ansible/latest/playbooks_delegation.html#rolling-update-batch-size
What about when you want to run a task several times in parallel, either on each host, or on a single host? A common use case is when you want to provision infrastructure at a cloud provider, such as Amazon Web Services (AWS). In that case, you normally run the task on localhost and the task just calls out to the cloud provider API.
The reason you might want to do these calls in parallel is because creating cloud resources sometimes takes a long time. AWS EC2 instances and RDS instances are examples of some resources which take a long time to create. If you want to create several, you can use a loop and wait for each to finish, but that takes a long time. As a alternative, you can create them all in parallel.
Here is a example Ansible play of how you can run any Ansible task in parallel and wait for them all to finish.
---
- name: Run tasks in parallel
hosts: localhost
connection: local
gather_facts: no
tasks:
- name: Pretend to create instances
command: "sleep {{ item }}" # Instead of calling a long running operation at a cloud provider, we just sleep.
with_items:
- 6
- 8
- 7
register: _create_instances
async: 600 # Maximum runtime in seconds. Adjust as needed.
poll: 0 # Fire and continue (never poll)
- name: Wait for creation to finish
async_status:
jid: "{{ item.ansible_job_id }}"
register: _jobs
until: _jobs.finished
delay: 5 # Check every 5 seconds. Adjust as you like.
retries: 10 # Retry up to 10 times. Adjust as needed.
with_items: "{{ _create_instances.results }}"
The output will be:
PLAY [Run tasks in parallel] **********************************************************************************************************
TASK [Pretend to create instances] ****************************************************************************************************
changed: [localhost] => (item=6)
changed: [localhost] => (item=8)
changed: [localhost] => (item=7)
TASK [Wait for creation to finish] ****************************************************************************************************
FAILED - RETRYING: Wait for creation to finish (10 retries left).
changed: [localhost] => (item={'_ansible_parsed': True, '_ansible_item_result': True, '_ansible_no_log': False, u'ansible_job_id': u'957883465297.7487', 'item': 6, u'started': 1, 'changed': True, 'failed': False, u'finished': 0, u'results_file': u'/home/max/.ansible_async/957883465297.7487'})
FAILED - RETRYING: Wait for creation to finish (10 retries left).
changed: [localhost] => (item={'_ansible_parsed': True, '_ansible_item_result': True, '_ansible_no_log': False, u'ansible_job_id': u'450659566541.7513', 'item': 8, u'started': 1, 'changed': True, 'failed': False, u'finished': 0, u'results_file': u'/home/max/.ansible_async/450659566541.7513'})
changed: [localhost] => (item={'_ansible_parsed': True, '_ansible_item_result': True, '_ansible_no_log': False, u'ansible_job_id': u'763185500456.7538', 'item': 7, u'started': 1, 'changed': True, 'failed': False, u'finished': 0, u'results_file': u'/home/max/.ansible_async/763185500456.7538'})
PLAY RECAP ****************************************************************************************************************************
localhost : ok=3 changed=3 unreachable=0 failed=0
See the example code at GitHub.
One of the plays runs the tasks in parallel, and one runs then in sequence, for comparison.
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 with a team to improving aspects of the whole organization.
When it comes to coaching a team it can be confusing for team members what type of relationship is natural for them to have with an agile coach. What’s in it for us? What is required from us to get something out of this?
Some basic things are needed to establish a good foundation for such a relationship. Getting some of them out in the open can help. To clarify what this foundation can look like I created this image a few years ago. It is meant to be used as a starting point for a conversation or negotiation between coach and team.
If you are a coach yourself I hope it can help you explain to your team what type of relationship you can offer them. If you are a member of an agile team I hope it makes it easier to understand what an agile coach can do for you, what it will mean for you to have such a relationship and what you can expect from it.
If you prefer an easy to print document, here is a pdf-version – My Role as Coach (pdf).
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.
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 interested in continuous personal development. So, I’ve been spending my free time connecting with and talking to people who are interested in projects and initiatives that leave a positive impact on people or humanity.
Are you interested in:
If you are and would like to talk, drop me a line and let’s do lunch some time!
Yep! The collection of Kanban boards now is now available in french. Big thanks to Nicolas Mereaux who made it happen!
Here’s the link to “10 tableaux kanban et leur contexte” (fr).
(the english 1.5v is available here )
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 him a little bit. I could think of no better way than putting him on the spot with a few tricky questions 🙂
Among them:
A key quote from the interview:
“If you don’t pay attention to the principles, the practices applied will deteriorate to ‘for show’
