I arrived in the tech office at 12:30 pm – coming from our other office. There were a few colleagues having lunch and talking about how they’d like to work. One of my colleagues especially had a strong opinion. Let’s call him Ralph.
“I think working in flexible teams would make everyone happier. I personally have more to learn from working with different colleagues, on different products every sprint, in a different context.”, Ralph said.
“That sounds interesting. How would you exactly benefit from that?“, I happily jumped into the conversation (I wouldn’t be able to stop the coach in me help him figure out how his theory would work for him and our colleagues).
“It would be great if feature teams will always have different people. Let’s say we start working on a feature, we bring in UX, mobile, design, data, all the people we need and we stick together until we finish the feature. Then we switch to work on a different feature with different people, or some from the same teams. This way, learning is maximised by (1) working with and learning from different people, (2) working on different features that might involve different platforms and skills“, he continued.
“I understand this sounds great for your personal learning and growth. How about the customer?“, I asked.
“How about the customer? They get the feature done and tested as normally, so I don’t understand your question“, he answered quite confused.
“Well, as a new working team, how well will you work together with your new teammates? How is your domain knowledge on the new feature? Will everyone work in his expertise area every single feature – design will do design, mobile will do mobile, back-end only back-end and so on? Do you think your delivery speed and quality will increase from feature to feature or stay the same as now?“, I tried to point him in a customer-centric thinking direction.
“I don’t think speed and quality will be affected. And yes, each teammate will work on their speciality. From my point of view this is the most fun and it would make me the happiest“, he answered, without really answering my question.
“Doing something fun is also important to me. If the work we do is fun, then we deliver better code and better products!“, jumped in another developer in the conversation.
“How about customer value? Having fun AND maximizing the delivery of value to the customer would go hand in hand together in this context?“, I asked as there was absolutely no mentioning and consideration of the customer in the conversation.
We continued talking but it seems that there was a strong sentiment among the majority of the team to try this approach. We agreed to do it, as long as we don’t endanger delivering our quarterly goals.
All current teams had one grand meeting to discuss how they’re going to work as features teams. After much debate, they settled on a framework, pretty much like this:
- feature leads (lead engineers) will discuss with everyone at sprint start about the functionalities that we’re delivering following sprint
- we also list down maintenance, refactoring, bugs and any other work that needs to get done, and feature leads take over the tasks depending on the platforms they’re working on at the moment
- the rest of the team decides what they should be working on and jumps from team to team each sprint (or not, the choice belongs to them) based on the work they want to do
- we keep the same rules otherwise (we’re doing LeSS)
- maximise learning
- increase motivation
- maintain current pace
- increase excitement
One month later, we had an overall retrospective with the entire team, and we looked at the past experiment:
- individuals migrated towards their former team mates (the ones they are most accustomed to work with and with which they already had a working method)
- a couple of individuals switched teams but not every sprint; we were already planning to do that after discussing with them, as the pace of the team or the personalities of the team mates were not a match for these people.
- Ralph – yes, same Ralph as above – proposed “something entirely different“: let’s have holistic feature teams, teams that are stable, work together but on different features from sprint to sprint, depending on customer needs and current roadmap. I applauded his proposal.
- everyone in the room acknowledged that, even thought they thought they wanted flexible teams, the reality is they still migrate towards the team they feel most comfortable working in.
Looking at our assumptions:
- there was a general confusion about who works on what and people trying to catch up with the different features that were being built; it reduced learning
- the above created also frustrations for some team mates; some others adapted faster to the new structure
- we slowed down a little in delivering our commitments but we recovered after the teams found some stability.
Sometimes discussions, arguments, data don’t work and you have to let the teams fail to maximise learning, while you’re there to support them and make sure that the customer needs are not affected and value is delivered. It is hard to do for an Agile Coach that would like to help the teams learn the easiest way, but it is good learning for the entire team.