Following advice from here, as the product manager, I am encouraging my dev team to become more cross functional by allocating basic front end tasks to the back end developer and vice versa. I have told both developers that I do not expect them to be specialists, but be able to do basic tasks to speed up the completion of sprints.

I am experiencing the following:

  • Both developers are now complaining that they are not being played to their strengths and are losing time when the other can do it better.
  • Both developers are challenging me by arguing 'if you expect us to be cross-functional, why don't you join in and code as well'. My role is strictly is hands off in a delivery role.

I feel as though I am being undermined to some degree, at the same time can see their point. In this situation is it better to just be firm with your decision?

  • 1
    Do the developers understand why you want them to be cross-functionally trained and what do they think of those reasons? – Bart van Ingen Schenau Apr 6 '17 at 11:31
  • 2
    Regarding point 2: Unless there is a regulatory reason why you can't, you should try to pick up a development task now and then, in-between your normal duties, to show the team your good will. – Bart van Ingen Schenau Apr 6 '17 at 11:34
  • 5
    "It is simply not my job and I have no interest in being a developer otherwise I would have signed up to do exactly that.". If you fill in front-end or backend in that quote, it could just as easily have come from your developers by what I understand from your question and comments. That is a piece of corporate culture that you have to break through. – Bart van Ingen Schenau Apr 6 '17 at 15:43
  • 1
    I have to stop this conversation. It is not in my job description to get you to see my point. – Bart van Ingen Schenau Apr 6 '17 at 18:09
  • 4
    @bobo2000 Your title is "manager". There is no such thing in Scrum. Decide what your role is (PO or maybe SM) and act accordingly. Or switch to another framework, Scrum is no silver bullet. But don't say you use Scrum and then directly manage people. That won't work. – nvoigt Apr 7 '17 at 11:15

Two responses

  1. WIFM - From the perspective of the team, why should they be more cross functional? What is in it for them? I suspect this is an opportunity to move the incentive away from activity (played to their strength) to product. Cross functional teams produce better (be prepared to support this with facts). It is easy enough to play to their strength if that is what they want - you can assign them hours and hours of meaningless work. Or they can commit to producing as a team and understanding the results of their production (Weber on Anomie).

  2. If you take pride in your product, then you want the people upstream and downstream connected to your product. You want to know that your output is used and valued - that implies understanding the downstream needs. Likewise you want to connect to upstream work and value - is there any way to improve your relationship with upstream? Do they deliver what you need or what they think you need. Are the requirements clear? Are you just a fungible link in a chain that can be replaced by anyone who can contribute N lines of code a day at X$ with Y errors? Think carefully about that answer, because I can open monster in about 3 seconds. Or do you want your upstream and downstream partners to argue to keep you?

Third thought - the snarky reply suggests to my that you have team issues with respect. if my team said that to me, I'd schedule a closed door meeting to discover why my team didn't perceive my contributions as valuable. What part of my job would you like me to stop so that I can spend hours as a minimally competent coder?

| improve this answer | |
  • 1
    I set up a meeting this morning, that is the problem. They are so involved in the technical side, that they don't understand what's going on in the commercial side of the business sales or operations where a lot of my work is done. Managing stakeholders, resource management, risk management, requirement gathering etc etc – bobo2000 Apr 7 '17 at 11:40

Ask yourself what is the real problem you are solving? Maybe do a root-cause analyses. After you know ask the development team how they think they can solve it? (Promoting self-organisation) Forcing new idea's will give you a fight. Learning costs time in the beginning, slowing them down. What is the end in mind? What will we gain. Let them decide by themselves, but let them solve your problem.

Once they see that becoming more cross-functional (Architecture, Design, Coding (Back/Front-end), Testing, etcs) is a possible solution to your problem they might be more open to the idea. But accept that they might have a different solution they want to try first.

Suggestions to become more cross-functional are:

  • Swarming, e.g. working the full team on a single story. You will have the split it smartly and work together to complete it as soon as possible, before starting something new.
  • Pair-programming, good for knowledge sharing and learning techniques. Also non developers can pair. Also pair-testing might be a nice thing.

Find out if some developers already want to become full-stack. They can be your friend to help convince the others, slowly. Keep repeating it for a long time to change a culture. Don't give up to fast.

| improve this answer | |

Time and again you surprise me with ways how to be not agile.

I am encouraging my dev team to become more cross functional ...

That's great!

... by allocating basic front end tasks to the back end developer and vice versa.

Wait, what??? You do not allocate tasks. Any task. At all. You give tasks to your team and the team self-organizes.

You give your team a goal and you let the team decide and plan how to do this. Right now, they only know half the story, literally.

As a product owner, I want my team to be cross functional, to [?]

Yes? To do what? You are asking them to progress in a direction, without a clear goal when to stop.

An example of a good way to ask for becoming more cross functional would be

As a product owner, I want my team to be more cross functional, so the team can still deliver complete features (=value) at an acceptable speed even if one member takes days off

Now they know a reason why you want it, they can themselves decide when they are good enough for the goal you set and they are even self-motivated because they want to take those days off (that you might otherwise decline if there is work to do that the other guy cannot do on his own).

It's their turn to figure out how they want to achieve it.

| improve this answer | |
  • Reason that you have mentioned is why I want them to be more cross functional, and have told them this. The other is because I can see the value of doing this to estimate the complexity of work better.When I set up the sprint, I set the sprint goal, and plan the work for the week with the team, but ultimately the team collectively decides who does which task, not me. The problem is that they are refusing to step outside of their comfort zone/specialisation. – bobo2000 Apr 7 '17 at 11:16
  • So basically you have not enough people to form a team, they are not co-located, you have not enough people to have a dedicated SM or PO and on top your team does not exhibit the Scrum values (openness, courage, respect) that would be needed to become more cross-functional. Maybe it's time to think about either getting a team that fits your framework or getting a framework that fits your team setup. – nvoigt Apr 7 '17 at 11:53
  • 1
    There is no shame in not doing Scrum. It's no silver bullet. You can be a manager and still do standups. Or planning meetings. Command&Control is a valid pattern if it works for you. Doing Scrum wrong however, will be a problem. So if you can deal with the personalities better by telling them in no uncertain terms what you want them to do... do so. There is no reward for doing Scrum other than... Scrum. Getting your work done comes first and if Scrum is not the way right now, go the way that works. Just don't call it Scrum :) – nvoigt Apr 7 '17 at 15:01
  • 1
    I cannot follow you. What I am suggesting is you do what is best for your company. It's obviously not Scrum because you don't have the people for it (both headcount and personality). That does not mean that Scrum is bad, the same way that soccer is not a bad game, when you have only two people who cannot run. Soccer is still a great game and Scrum is still a good process, but it's not for you. You need to adapt to what you have. And if you have two people that are not motivated to work cross-functional and a manager, you should probably do command and control. Or something else. – nvoigt Apr 7 '17 at 15:22
  • 1
    Well, maybe they don't need to do coding. What about training the tester in design and the designer in testing? I'm just saying "cross functional" goes for the whole team. Your developers will not understand if you want to get half the team to "cross functional". Either it's a team, or it's a designer, a tester and two developers. – nvoigt Apr 10 '17 at 16:17

How do I encourage my team to become more cross functional?

Pair programming. Get a new desk set up, with two computers on it, side by side. The one less-experienced at the task sits at one computer, and does the actual coding ('driving'). The more-experienced one sits at the other computer, uses it only for looking things up, and helps guide the driver ('navigating'). You'll get higher quality code out of it, too.

Just don't get rid of their normal desks. Not all tasks need to be pair-programmed.

Both developers are now complaining that they are not being played to their strengths and are losing time when the other can do it better.

Depends what is meant by 'it.' If the only goal the company (and, more importantly, the Team) has is to get these tasks done now, then they're correct. If, however, they care about the future at all, then the (less immediately visible) benefits to cross-functionality outweigh the immediate benefits of getting tasks done asap. Usually; some emergency tasks could obviously be an exception.

Both developers are challenging me by arguing 'if you expect us to be cross-functional, why don't you join in and code as well'. My role is strictly is hands off in a delivery role.

Sounds like they might just be acting a bit snippy, though as pointed out in comments, you could try it out, just to placate them. Or, if you're not willing to actually dive into the code, at the very least you should consider putting effort into understanding what they're doing. Gain enough knowledge (both about programing in general and in what's been done with it at your company) to be able to understand what they're talking about when they talk about things like foreign keys, models/views/controllers, repositories, 'that one **** method, with the rules', etc. You don't need to understand enough to work with them, but gaining an understanding of what they're talking about, at least, could un-ruffle feathers.

| improve this answer | |
  • +1 pairing, but I am not sure you really need different desks or extra computers to get started. – Niels van Reijmersdal Apr 6 '17 at 14:07
  • a) They work remotely. b) They are resistant to the idea of pair programming, since one is a front end developer the other back end, and want to strictly only focus on their specialities and will only work together to brainstorm how to solve problems on paper. c) I do understand the theory quite well, I was a former developer but frankly I hate coding, I don't have the patience to do it commercially. – bobo2000 Apr 6 '17 at 14:19
  • @NielsvanReijmersdal True, but not only would it help the pairing itself, it would help show that the company is serious about the whole concept. – Sarov Apr 6 '17 at 14:19
  • @bobo2000 You mentioned they work remotely. Are they in entirely different locales, or would it be possible for them to come in, say, one week per month (or one day per week, whatever works) to do pairing? – Sarov Apr 6 '17 at 14:22
  • No - they are in different countries. But even if I could, they do not see the value in pair programming, their whole argument is that they want to do what they are specialised in, front and back end development since they feel it is a waste of time playing developers to not their strengths. In other words the back end dev does not want to dive deep in front end and vice versa. – bobo2000 Apr 6 '17 at 14:23

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.