I arrived in the tech office at 12:30 – coming from our other office. There were a few colleagues having lunch and discussion how they’d like to work. One of my colleagues especially was really strong in his 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 colleagues).
“It would be great if features 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 involved 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 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 maximising 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.
The conversation continued without much addition to the above. The issue here is that the devs would come to propose a different way of working based mostly on what would benefit them personally and what would make work more fun. Which is something I always consider when it comes to teams formation: the devs should agree among each other to do the work that they are more passionate about, or brings them more learning.
AND deliver maximum value to the customer. This discussion should not happen outside of the context of the customer. If the need be, the team should be flexible enough to reorganise themselves to deliver fast and quality, regardless of personal interest and growth. Of course these situations should be balanced with their own growth but an agile team should focus first on how to grow as a team, rather on how to grow individually.