2

I work at a startup where I began as the only developer 3 years ago, and now I run the dev team. There's 15 employees total, 8 of whom are engineers:

  • 5 iOS devs
  • 3 Backend devs

We're currently just building an iOS application.

We're starting to grow up a bit and now have a UX Designer, a Head of Product, a Head of Marketing and so forth. After a long period of figuring out the product and some very long release cycles, we want to start iterating more quickly.

My goals are:

  1. to be able to have the team work on 2 or 3 vertical slices of features, in parallel.

  2. to be able to release those features each sprint

  3. to increase responsibility and and accountability within the team

Issues I'm seeing:

  1. Feels 'top-down' -- a lot of the team communication seems to come through me. ie. if a backend dev has an issue with some ios component, they might ask me, and then i'll talk to the iOS dev, and then relay information back

  2. Standups feel unfocused -- because we have 8 devs all working on different "bits" of things, standups don't seem terribly useful because there isn't really a unified effort amongst the team as whole.

  3. Throwing it over the fence -- After Sprint Planning, everyone tends to go into their silos. We discussed what needs to be completed, but the devs tend to go into their own worlds and, for example, not take initiative to discuss interfaces between front and backend, throwing things over all the wall for QA (which usually comes to me our product owner), etc.

Question: I'm wondering if it makes sense at this point to split the team into two cross-functional groups? I'm hoping this will accomplish the following:

  1. Each "team" will have a sprint goal which may consistent of 1 or 2 vertical feature slices to accomplish. I think it may be easier to self-organize in the context of a smaller group and figure out what needs to happen to meet the goals. Moreover, I think this could help aid in accountability since the team will have very specific goals.
  2. Standups can happen within each team, and therefore, will be focused on unblocking and moving progress forward as it relates to their specific sprint goals.
  3. Because each team has specific goals and accountability, they will be more responsible for things like QA, mockups accuracy, functional edge cases, etc before delivering to the product owner for final acceptance testing.

I suppose the above can be accomplished within the context of a single larger team, but I haven't been able to find a good way to make that happen yet.

  • 3
    It seems like you have an agile adoption problem, not a team size problem. Splitting your team before fixing the underlying issues is likely to double your integration problems rather than reduce them. – Todd A. Jacobs May 12 at 18:38
  • 1
    Are the non-developers (UX Designer, Head of Product, Head of Marketing, etc.) also part of the team or are they working separated? Does the team have a Definition of Done that includes testing and integration? What would the response of the team be if you said "this will go live in one hour" once they report a story as done? – Bart van Ingen Schenau May 12 at 18:47
3

from what you describe, I don't think you have a problem with your team size. 5 + 3 seems quite ok. Maybe I should add some comments to your points so you understand why I think your problem is something else:

Goal 1 and 2: Why do you think you need to handle 2-3 vertical slices at a time? If your release cycles are currently too long, the way do speed up the cycle is to handle less threads at a time. It is also good practice not to handle one thread by one person.

I think it is a common and wide spread problem to handle too many stories at the same time and hoping that it makes things faster. It does not. It will result in splitting your team into single developers, everyone doing is own stuff.

Issue 1: Are your developers in one team? If yes, why should a backend guy ask you about something the iOS developer did? Do they have a common goal? They should try to fulfill their common goal together. If then they find out that something is not clear and they need feedback from the PO, their should ask you. Together.

Issue 2: See comment to Goal 1 and 2. If everyone is working on different bits of something, you do not really have a team setup. We have also one team here that is doing it that way, lacking team work and building up technical dept because they need to be "fast".

Issue 3: Yes, also team spirit missing. It looks like the typical restaurant problem. Service and cooks are not working together, in worst case fighting their little wars and find out who is guilty and pushing work on the other side.

I hope that my comments make clear that splitting the team is not the solution. From what you are describing I cannot give you an easy solution here. Usually iOS and backend devs should commit themselves to a story, all together. And if they do not reach that, both together fail.

Moreover, if your work is split up so that everyone is doing his own little story, it may also be a problem of personal likes and dislikes. After some round of pushing guilt around, people get biased against each other. This gets even worse if the same people are handling the same topic over and over again.

  • 1
    Thanks for your response. I suppose I’m curious: if we have 8 developers, and they aren’t collectively working on 2 or 3 vertical slices and are only working one 1 feature, how would that work? – djt May 14 at 16:49
  • 1
    @djt This depends on the feature to implement. It might make sense in some situations to work on 2-3 slices. But if possible the team should concentrate on one feature (which might have multiple stories). What I want to say that working on different slices can make sense but should not be a goal. – maze May 16 at 10:33
1

There are a few things that stand out from your question:

to be able to have the team work on 2 or 3 vertical slices of features, in parallel

Why do you see working in parallel as a goal? Typically doing work in parallel costs you in terms of efficiency, due to the overhead of context switching.

if a backend dev has an issue with some ios component, they might ask me, and then i'll talk to the iOS dev, and then relay information back

This is a communication issue. Has the team discussed it?

Standups feel unfocused

Has the team discussed this? Have they tried anything to make the stand-ups better?

After Sprint Planning, everyone tends to go into their silos

Fixing the issues with the stand-up should help here.

I would suggest that the single biggest improvement you can make right now is to start discussing things as a team.

It may be that splitting in to two teams makes sense, but that decision is best driven by the team itself and not by an individual.

  • We currently discuss things as a team during the planning meetings and so forth. But thereafter, people tend to go into their own worlds – djt May 14 at 16:50
  • Similar to the comment I posted on the answer above, how would a team of 8 work on a single feature? My experience thus far is that it’s slightly close quarters. So my thought was that if we worked on 2 or 3 slices at once, there’s be less of that and essentially 2 or 3 devs would be responsible for each. – djt May 14 at 16:52
  • I absolutely get that sometimes it is practical to work on more than one thing at a time. But I wouldn't make it a goal to do this, it is just something that should drop naturally out of planning. The team will discuss the proposed work and then decide what the best way to split it up is. The point is to get the team making these decisions so that they are less inclined to work in silos. – Barnaby Golden May 14 at 17:49
  • Yeah I understand. The team is the one making the decisions as far as what to take on, what the edge cases are, potential scope questions, but then I find that each person more or less takes their tickets and does their work. So after planning, there still seems to be a disconnect on the continued team-based operation – djt May 14 at 20:35
  • Then that is the conversation you should have with the team. Why do they want to work that way? You could also make some suggestions, perhaps they might try pair programming for example? The key is that the team has to want to do things differently. Get them talking about it, find out what their motivation is. – Barnaby Golden May 14 at 21:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.