How to efficiently handle a scrum project when part of development team are from external firm?

Question

In my organisation for one of the project we follow Agile Scrum methodology and following is distribution of the man power for the project:

Scrum Team: 
SM
ProxyDev1(Internal): 50% in the project
ProxyDev2(Internal): 50% in the project
Dev3(Internal): 100% in the project
Dev4(Internal): 100% in the project
Dev5(External): 100% in the project
Dev6(External): 100% in the project
Dev7(External): 100% in the project
Dev8(External): 100% in the project

As you see above we have developers from external firm and also internally there are 2 developers who are only 50% involved in the project and these are the most experienced one in the project and other are relative new to the project.

Sprint duration is 4 weeks and we have 3 refinements(2 refinement with PO,ProxyDev and SM, and 1 internal refinement with proxy dev,devs and SM), 2 planning(1 planning with Proxydevs,SM and PO and other with PD,SM,PO,Devs), 1 estimation(all participate) and retro and dailys as usual where all participate.

As you can see proxydevs attend all the meetings as they are more experienced and we save lot of time by not wasting all developers time in these meetings.Additionally as Proxydevs are 50% involved the sprint duration is 4 weeks instead of 2 or 3 weeks so we could reduce the time used for scrum events. The PO is from other firm.

Now the problem as SM i am facing is that the external developers have less experience in the project and we are now having lot of overhead to explain them and the expectations are not being understood correctly. So things like concept work has to be done by us and they just do the implementation. How can we reduce the overhead from the external developers?

What are my options here to make the process run smoothly? Should i restructure or use other framework to work with external devs? Additionally can i improve the output by restructuring the internal team?We have to work with the external firm at any cost.

Thank you very much

Answer 1

External developers are what the name says - external. Do not expect them to fully contribute and understand the grand scale, only the core team can do that. It's much much more than attending all of the meeting also, so do not expect things to get better by organizing more of those. The best way a person can learn about and understand a project is being part of it, from a to z. Being involved in the discussions where project shaping decisions are made is crucial because that's the place all the questions get asked answers received. External people by definition can't experience that because they are "muscle for hire" and change projects frequently.

Having that said, I'm in no way suggesting external developers can't contribute in a meaningful way. On the contrary, but a couple of things have to be taken into consideration. First, acknowledge that they do not know as much as you about the project. Core people easily forget that and expect others to be on their level. This is also the reason why diagrams explaining how the project works are overlooked, unupdated or not made entirely in the first place. And I'm not talking about UMLs - simple pen-and-paper conceptual diagrams are a golden starting point in understanding how all the parts work. Secondly, for reasons described previously, external people perform best when the task domain does not change much, since in time they're going to understand that specific domain more and more and will be able to perform better. Thirdly, if it's in your power, choose those external developers who would be able to commit 100%, not 50%. Multitasking and context changing does not help productivity.

Answer 2

I would say the correct way of handling this is invite the entire team to the planning and grooming meetings. The purpose of grooming is to be sure that the story is developed enough that any developer on the team can understand it. It sounds like your stories are not being written to that level of understanding.

However, the first approach I would take is asking those developers what they think the issue is and what would make things easier for them. If they can provide a workable solution that doesn't need their involvement in all meetings, it will save some of their time.

Answer 3

It seems to me that the correct answer is to partially embrace your difficulties. As Petras and Christophe alluded to, the external devs basically aren't going to have the level of understanding over the project that your internal staff do, at least over the course of a few weeks.

Recognize this, and embrace it. The internal staff (and the PO, I suppose?) have a better understanding of the project & it's expectations, so they need to do more design document writing & revision. In the execution of this, remember that designing a program is itself identical to the act of coding that same program. Sometimes, programming might be analogized to building a house, but that's flawed, because the actual construction work in programming all gets done by the computer: we're all architects here, it's just that some of us design the skyscraper in a coarse & generic fashion, while others design individual floors to more detail. Recognize this, and adapt to it:

• Everyone will be dealing with the dev tools, so everyone gives design feedback on those, in addition to writing some of their own if the case calls for it. Try to be permissive on what's allowed for their personal tools: I started using a lot of C macros on a vm project, because even though the macros hide the actual structure of the code, the particular structure that they hide (a bunch of error handling of a few standardized patterns) is actually noise from the perspective of what the code is doing. I was able to catch bugs much easier after swapping in the macros than before, to the extent that when I was finally able to compile the core system (which was still not enough to actually run it, despite being several KB, mind you! all I was trying to do was bootstrap up to a meaningful starting point for testing), there were maybe one or two bugs other than the ones involving parenthesis mistakes. I was done with those fast enough that I didn't bother recording them.
• You, the Proxies, and the PO will be dealing the most with the design documents, so you four need to be running bug-fixes on those: and yes, for all practical purposes, those should be counted as a sort of code. If the external devs are having trouble with understanding the docs, then it implies that those docs have a "bug" (or several), which needs to be fixed. Think of this as being a sort of self-testing code.
• The external devs will be focusing the most on implementation, so they'll naturally need to write the tests/documentation/etc. for that. The design docs need to be written (and possibly indexed) in such a way that their usage of the documents is fairly efficient. They should all keep a notepad or something to jot down quick "docs bug" notes for themselves while writing the first-pass of whatever code they're adding in at the moment: that code & those "bug notes" should both "compile" at the same time. The function (just as an example) hasn't really successfully compiled until the "bug notes" have been quasi-formalized & written down somewhere, perhaps in comments at the start of the code in question. Ideally, you'll have a tool to automatically extract these notes and add them to a database upon submission of the file to your VCS repo. Make it clear to the external devs that vague reports are fine, particularly since subtle bugs tend to be harder to find, and thus are more important to get info on. For a simple example, the phrase "I could care less" is used to mean "I couldn't care less", but it's actual meaning is the exact opposite: if it was written in a design document, then it would be very possible to not notice the mistake (or in the case of some people, not even realize that it was a mistake!), and then have it subtly modify the meaning of a sentence later in the same paragraph, potentially causing different members in the same team to get even more differing impressions of the intent than they already would have. Inconsistency of terminology, failure to fully clarify the fact that two things are in fact different, and other such things can be noticed in the same way. In a previous job of mine (albeit in an unrelated field), one co-worker had actually been incorrectly calculating a particular value that we were supposed to track separately for each sub-set of data for three years, but it had only happened because the supervisor of the group had never realized that he had failed to provide clear documentation of the calculation method for the value in question.
• It's natural and proper psychologically to be reluctant to toss complaints about e.g. the design documents to whoever created them, particularly if it was done by management in some sense. Thus, while it's desirable for people to just come out and tell you what issues they have, it won't consistently happen. Furthermore, they might not realize the significance of something that they've struggled with, or they might not realize that someone else has been having trouble with it. Thus, whoever "aggregates" the bugs should be making a point of taking bugs that are suspected to possibly be related to poor understanding of dev docs around to all of the dev-team members, along with the section of the dev docs in question, and have a sort of micro-Scrum to test that section of the docs, and engineer some potential improvements to it; maybe 15 minutes max per individual programmer or programmer-pair (whether you do this with a pair of programmers probably shouldn't depend on whether you're actually using pair-programming, but instead whether you think that individual pairing will be likely to produce more feedback as a pair or individually). I suspect that you, as Scrum Master, should be the one to take on this role. Remember when doing this that you are not precisely doing this for the sake of whoever you're bouncing the dev docs off of in that particular meeting, but instead for the team in general, so minor quibbles that someone has with the docs might actually be more valuable in some cases than major flaws, since a major flaw that is easy to recognize & fix is less likely to be unrecognized by a programmer with their head half in the docs & half in their code than a subtle miswording.
• Treat the reports of "bugs in the design documents" as precisely that: bug-reports on the design docs. Aggregate them, sort them for similarity, hunt for additional unreported cases, formalize the similarity, devise the "patch", apply, double-check. Wash, rinse, repeat, forever; or at least until you can't figure out anything else that seems like it would improve things. This should be sort of an "open scrum" of it's own, with PO, SM, and your two Proxies, with the external devs popping in whenever they have something they feel like bringing up. For this purpose, a lot of the work for it (well, a portion each of the review, retrospective, and planning stages anyways) should happen when the full team is all at the same location, with this meeting ending a little bit before the matching project-wide meeting. Dev docs are properly a sort of project of their own, so it's not a great idea to couple dev doc development efforts too closely to the greater project: it's sort of a project-within-a-project, and the majority of developers probably won't have any particular thoughts on it's results until they've had a bit of time to stew over the results. Try to keep them in the room with some donuts or something, and make sure they can check over their emails or whatever as well, just so they'll be more likely to do quick sanity-checks if you run across something they have familiarity with. When you finish that meeting you just clean up like you would normally, review the stuff you were planning to bring up in the normal project meeting, and move to the whiteboard on the opposite end of the table or something. However it is that you track project info, try to rig it up like that, with your "tactical" stuff and "meta" stuff in the same area, but segregated a bit to make the mental shift easier to do. Probably the best way to do it would be to have some offices surrounding a project-specific meeting room, with one side of that room dedicated to "tactical", and the other side to "meta", but even just swapping the side of the table you're at, when combined with "meta" and "tactical" tags in your project software, should present a workable solution.
• While I said to be permissive with developer-specific dev tools, remember also that those tools may sometimes be adopted by the project in general if they meet a particular need. Don't place restrictions on the actual tools because of that, but do have the external & internal developers keep a list (or several) of their personal tools for the project, and a quick blurb about what the tool is for in case another dev needs the same thing: these lists are input documents for the developer documentation, and thus fresh versions need to be included when reworking the dev docs. To support this, make certain that both they & the personally developed dev tools are in the VCS repo, so that you can pull a specific version into the "project tools" if appropriate without then locking the original dev into an old version for compatibility with an "extension use" if the original use starts to diverge.
• Correspondingly, the documentation of the dev tools is part of the dev docs. While a tool remains specific to a single developer, that short description of it's purpose is likely sufficient, but once it moves outwards it'll need something more substantial. If a tool is both relatively large or complex (e.g. an executable with a few command-line switches or something), and sticks with the project for a prolonged amount of time (months or years, not weeks), then it'll need proper documentation, so you'll need to start that.

tl;dr: Your design documentation needs itself to be treated as a development project, with a core team (the PO, the SM, and your Proxies), and a couple of hybrid user/developer/testers (your External Developers). Do that a a sort of project-within-a-project, with all project members cooperating on the inner project as well. And you (the SM) need to handle a lot of the "secretarial" work for that (because you're apparently there full time, while the others seemingly aren't). Also, some amount of info on developer-written dev tools needs to be "recruited" from the relevant devs, so that the dev docs for those can be improved by the same process when appropriate.

Answer 4

what's the real problem?

According to your own analysis, the problem is that the externals on your project have less experience IN THE PROJECT and do not understand the expectations, which require more work from the others and overhead for you.

It is not clear from your narrative if the root cause is that the externals do not have the occasion to acquire sufficient knowledge on the product and the expectations, or that they are not able to do more conceptual work.

Is it the skills?

If it's about ability, the problem doesn't appear to be related to individual skills, since it's the same for all four external developers. So it could only be related to the contractual set-up. This could for example happen if the profiles were chosen with the assumption of a traditional division of work, aiming for pure coders working only from specs (and eventually not mastering English sufficiently for oral interaction with the rest of the team). In this case, all you could do is change contracts.

Or is it the process ?

However, I'd be surprised that it's really a question of ability. So, here some questions for you: how long are they part of the team ? What occasion do you give them to learn more about the product and the expectations ? How did you organise knowledge acquisition on the existing functionality ? Can new internal developers contribute better than the externals, and if yes, why ?

I don't have the answers. But I suspect that you do not give externals the possibility to grow in their team role. In fact, not letting them participate the planning and all the refinements may seem to you as some overhead savings. But in reality, this practice deprive these team members from important feedback about what is acceptable or not, so that they will never be able to catch up and will always rely on your good will to provide the missing infos.

Keep in mind:

Alone we go faster, together we go farther

So if you look for long term benefit:

• either you integrate external members in your scrum team exactly as the internal members and apply all the scrum principles. This requires some initial knowledge transfer to catch up (could be done constructively, e.g. peer coding with internals when extending existing stories);
• or you organise the work differently, but then do not call it scrum. You must then acknowledge and accept the limitations, and in particular that some team members will never have sufficient knowledge for fully autonomous work and thus must remain locked in a specialist role, fully dependent on your input and preparatory work. Thus working in a very hybrid way.

I'd recommend to go for the first !