Dev talk: flexible teams yay or nay?

The devs had a recent conversation about how they want to work. Their choices were mostly between stable component teams and flexible feature teams.

What’s a stable component team?

A team organised per application, or platform, or whatever other component the team choses to structure around, is called a component team. We have an iOS team, a few web teams, a design team, and an Android team. These are component teams.

What is a feature team?

A feature team is team of experts that deliver features to the customers. The team is not focus on a certain feature, but they only deliver customer functionalities, across platforms or apps. It’s customer-centric and everyone in the team will work to deliver the feature, no matter their speciality, e.g. to deliver a feature you need a certain amount of web, mobile, design, architecture work; if the designers finished their tasks in day two, they need to find different ways to help the team deliver the feature, either doing front-end, or some back-end, etc. It promotes full-stack and continuous learning, thus a lot of times it’t very hard to engage the devs into organising themselves as a feature team.

What is a flexible feature team? (according to Ralph)

A team of experts that work on a feature, then disassembles itself and the team members create another team with other colleagues to work on a feature, and so on. Considering this definition, it’s not really a team, just groups of people working together to deliver a feature. As they form and disengage from feature to feature, they probably don’t have the required time to turn into a proper team.

The team decided to work as flexible feature team. As an Agile Coach, I consider this to raise a lot of issues (slowing down delivery, lack of focus on quality, lack of ownership for maintenance as the team dismantles after the feature is done, wasted time to form a team, create working rules, and gel together to deliver their best work and the list can continue).

But at the same time, I can’t protect the team from learning and failure. The experiment has started yesterday, I’ll be back with results.

My question is: flexible teams or feature teams? What do you prefer?

 

 

 

Advertisements

Devs talk: personal interest and customer value

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.