Organization structure in startup

Question

I was given the role of managing 5 different teams (iOS, Android, Backend, Firmware and Hardware (electronics)). All these teams consist of no more than 4-5 developers. There is also a QA team (2 engineers) and they are testing all the components, either feature or new firmware.

All teams used to work separately with their own boards, backlogs, and sprints. Last month we started working on features dividing it on stories and moved iOS, Android, and backend to one dev board. Currently, we have 1-2 dynamic feature teams, as some features can have different lifetime and require different developer pairs (for example, iOS+Android+Backend or FW+Backend, etc.) and individuals who are working on small tasks/tech debt or other items.

I need to understand: - What would be the best organization structure of the above teams? Currently, I don't have any idea but to continue working as small feature teams. - How to estimate the productivity of each team member within one board where we are tracking either features or individual tasks. I understand that it would be better to track velocity of the TEAM, however, teams are kinda changing from feature to feature and not stable enough to trust the velocity.

Thank you in advance!

Answer 1

Based on what I'm seeing I'll give you two answers. If I were in person and able to do some first-hand observations, I could probably come up with a more refined suggestion.

1- Best Case: Your best case is to take the time, now, to move your team members towards better cross-functionality. Instead of having an iOS Dev, an Android Dev, and a QA person, you want three Agile Devs where one just happens to be stronger in iOS, one in Android, one in testing.

The challenge is this usually can't happen over night, though you would be surprised how quickly you can move from functional silos to full stack developers if everyone is on board with the idea.

2- Quick Solution: Move to a Kanban workflow, with a heavy focus on Work in Progress limits. Have Team Member "Icons" (magnets, stickers, something like that) that they can attach to stories in the Ready queue. When all the people needed for a Ready story are on the story, and there is WIP availability in Doing, move the story over.

So an iOS developer finishes up a story. She sees that the third story down will need iOS and Backend work, only no backend person is available yet. The iOS Dev then looks at the stories above and sees that an Android person is working with a Firmware Engineer. She sits in on their pairing session so she can learn more about Android while she waits for the Backend person to be free. By doing this, you can move towards the Best Case solution over time.

I've got a "What do I do next workflow" that I often share with teams I coach. Here it is my Kanban version:

1. We trust you, do the right thing.
2. Is there some way I can help someone with a current task?.
3. Can I fix a bottleneck in the workflow (someplace where WIP or Cycle Time is high)?
4. Can I work on an unstarted task on an in-progress, user story?
5. Can I fix some outstanding technical debt, or make the system better?
6. Can I start a new story that is high in the current Ready backlog?
7. Can I learn something new or improve my skills?
8. When in doubt, see #1.