The Hamsters: The best team I've worked in and how we achieved it with extreme programming and value slicing.
- jvigersten
- Jan 20
- 6 min read
Intro
We all worked in a large team, around 15-20 people. Our workflow consisted of long dailys with un-aligned goals. Our work was mainly dependent on individuals coding their own tasks and functions, creating a PR into the current "testable" branch and letting the testers do their thing.
The work was heavy on individuals, generated a lot of context switching, merge conflicts, messy branch-merges, bugs and unstable environments and releases. Most of all it affected the customer and the people using the product.
A few of us noticed these problems early on and raised our concerns, after a while we where heard. More people had realized that it was unsustainable, and it was decided that the team should be divided into 3 separate teams with various focus areas.
Nobody complained.
Team selection
People where given the task to name their preferences, focus areas and expertise in order to help dividing people into the three teams.
Me, with my design and testing focus wanted to work close to the user interface, in a customer-oriented team with close contact to the people using the system. I voiced this and where sorted by the sorting hat into just that team together with a group of great people that complemented each other very well.
The team consisted of:
Design Lead - Kajsa/Sandra
Backend Lead - Björn
Backend Dev - Marcela
Frontend Dev - Donatello
Tester & Designer - Me
Even though we all knew each other it was a new start, with new beginnings and that also means new group dynamics. The team joined a workshop to set the team standards, ways of working, team contract, expectations and to get to know each other on a deeper level.
Workshop activities
We started by listing things that we all felt had been successfull from previous experiences. (Screenshots in both English and Swedish).
After this we created a matrix of good and bad on individual and team levels to help guide us what we felt we should try to avoid and what we wanted to keep and foster.
Together we came up with ideas about what kind of team we wanted to be.
We continued to build upon this and discussed practical things like workflow, customers, transparency, quality, individual vs team goals, common responsibility, continous improvement amongst other things.
After doing all of these different exercises together we cooked our thoughts and ideas down into a working agreement that would act as our team contract. It defined us as a team, how we wanted to work and how we should work to achieve a satisfying work environment that would also satisfy our customer.
After finalizing our working agreements we defined and visualized how our process would look like.
The Hamsters
We came up with the team name "The Hamsters". The team name is inspired by a mindset that I was introduced to on a conference many years ago that involved a fictional drunken hamster that would deploy code to production at any given moment, however the team was not worried about this since they rarely had any issues with their code.
This became our motto: Our team should be able to push code changes to production at any given moment. Our working processes and quality mindset should guide us to create working solutions and iron out as many mistakes as possible early in the process.
And we achieved this.
Our process & workflow
The team decided to work with Extreme Programming, also called Mob programming.
We read the book "Software Teaming" by Woody Zuill and Kevin Meadows to help everyone feel safe and educated on the area.
Extreme programming can shortly be described as everyone working together at the same computer with the most important thing. I won't go any further into this in this blog post, that's for a separate post, but you can read more about it via the link above.
The team decided to work with a kanban board without any specific time frames and with as few standing meetings as possible. We decided that dailys everyday was important and that retros should be held weekly with the ability to cancel it if the team felt that it wasn't needed that specific week. If it was canceled we always had the retro the next coming week.
Our product owner attended all our dailys and informed us of changes that might occur. We reminded him to always keep the backlog prioritized so that we could move on to the next thing quickly when finished.
Refinements where not standing, we approached a on-demand refinement method that gave us the possibility to refine what we where working on when it was time to work on it. This removed meeting time and added focus time for development and we didn't have to refine things that might be subject to change in the future.
Before starting to work on a new feature we first performed user story mapping to help us understand and identify the users journeys.
Our design lead and I did most of the user research and came up with design solutions, but we also involved the developers in our work as much as we could to gain both a better common understanding as a team but also to help benefit from their developer brains.
We then broke everything down into different value slices. Each value slice contained the minimum amount of work that was needed to be done in order to deliver value to the customer and the people using the feature/product.
Together we identified which value slice made most sense to begin with and started working. The entire team was involved in the development of each feature continuously.
When the development of a value slice began everyone from developer to tester and designer where involved in the Mob. We switched driver and navigator (extreme programming terms) on a regular basis, resulting in everyone being able to write the code, involving everyone in the thinking process and raising questions as we went by.
As soon as the code was written we tested it locally, if it worked well there it was instantly published to our test environment where I started testing the functions, exploring charters and providing feedback to the developers, if an issue was discovered and reported we fitted that into our day and fixed it as soon as we could.
This process helped us minimise context switching, eliminating the need for pull requests and the dependency of individuals, iron out design issues, questions, potential bugs and identifying things that we might have missed very early before publishing it into our testing environment.
Our workflow enabled us to deliver features with very little bugs and issues into testing and production environments. Resulting in a quick workflow with fast and stable releases of small incremental steps that always provided value to the people using the product.
On our best week we released at least one value slice every day with zero issues or negative feedback coming back our way, this resulting in what we called a perfect week.
Pros and cons with our workflow
After describing and summarizing our workflow I'd like to end this post by listing some of the pros and cons that we discovered while working like this.
Pros
Everyone is involved, minimising:
Context switching
Lead times
Dependancies on individuals (everyone knows what's been done)
Pull requests
Improves quality output
Right thing get's developed at the right time
Competence sharing/Personal development
Designers can code
Frontend developers learns backend and vice versa
Testers can code
Developers get's to think about testing and actually test
Cons
Individuals can be energy drained from time to time by socializing so much
Important to take breaks frequently and establish rules that fits the team. E.g it's OK for individuals to take a brake anytime if needed.
It's a way of working that sometimes can be hard to "sell" to management/developers.
It shouldn't be, but for some misconceptions it is. Learn how to talk about it in the book I mentioned in the beginning and prove them wrong!
Tricky to set up a perfect hybrid workplace. It fits best in an office setting but fully managable to do remote (we have proved this).
Final words
I hope this post have given you some new ideas and insights about how to work "differently". For me this was a checkpoint in my software career and something that I will always look back on and remember as something that we did really well, as well as a great learning experience.
Some topics in this post can be explained more in depth like Extreme Programming and Value slicing. This is something that I will cover in a future post, but if you want to read up more about it on your own these links are useful:
Comments