Having problems within development team re approach

Question

Noob PM here - I have a project with 3 developers (one of whom is tech lead), a BA, and a tester. The tech lead (hereafter referred to as TL) is responsible (on the RACI) for the technical output of the team, i.e actually delivering the software.

TL would like to deliver the project using a kanban-like methodology, and has asked the BA to deliver high level epics which they have then together broken into stories. This was all pre-project. Now the project has kicked off, TL has organised planning meetings which everyone is attending, with the view of breaking down the stories into tasks and estimating.

However, at first planning meeting another of the developers who had worked closely with the business area in question to produce a very basic proof of concept as part of our requirements gathering, rejected the approach out of hand, saying that there was no point in going back to basic user stories when we already understood most of the process and what needed to be delivered, and refused to take part in the task break-down and estimation activities.

TL has recently come to me and stated that they can no longer be responsible for the output of said team member. I'm at the point where I don't care what methodology they use but we need to get started and I am unsure how to intervene (or if I even should) to best continue.

• Is there another methodology I can suggest which will mollify the team member who doesn't want to estimate tasks, and also give us the ability to be agile and transparent in our delivery?
• Would it be feasible to allow said developer to continue along their line of development in parallel to the rest of the team and somehow allow the two resulting solution-strands to merge at some point?
• What would any of you do in my place?

Thanks for your advice.

Answer 1

David is absolutely right, there are very few instances whereby refusal to work can be considered acceptable, generally the accepted norms would be if to continue would compromise yourself and/or the organisation legally or as David has already said if to continue would constitute recklessness and present a risk to life etc. The developer’s behavior is unprofessional at best and sufficient to show them the door at worst.

However, I did have some thoughts whilst reading your post which may be worth considering;

You’ve mentioned that the Technical Lead wants to deliver the project using an agile/kanban-like methodology. Is it safe to assume that this is a deviation from the standard norm within the organisation? If so, and judging from the comments made by the ‘problem developer’ regarding there being no point going back to user stories etc. It may be a case of not understanding the purpose and other benefits to be gained through adopting the proposed methodology even if it does mean covering some ground that (s)he feels has already been covered.

I've been in similar situations as a developer myself whereby someone would complete a training course, read a book, attend a seminar etc. and come back full of ideas on how they were going to completely revolutionize the way we worked and delivered projects. The problem is not the methodology, in many instances the new ways of working were an improvement, most emerging methodology’s are improvements on previous ones so it stands to reason that they deliver benefits. The problem was that not everybody had attended that course/seminar or read that book in addition to the normal human factors associated with change.

If the Technical Lead has the right to determine the approach used and is adopting a methodology that’s unfamiliar to others then I’d suggest that the stage be set through an ‘introduction to …’ session (it needn’t be hours long) whereby the principles are established, the framework to be used is clearly outlined, the win-win scenarios to bring everyone on board are set out and lastly that it is clear that this is not ‘optional’.

In direct response to the points you have raised however;

1) Attempting to mollify an individual will only undermine your authority and credibility in the long term.

2) In addition to the above allowing for 2 separate work streams to be undertaken where there is no common understanding or agreement i.e. in the form of user stories and then hoping that these will somehow merge at a later date without problem is in my view a mistake and not one I would be willing to risk.

3) If I were in your position I would take the action expected of me within the remit of my role. In the scenario you’ve described that would be to document the risk, thoroughly and with the input of the technical lead. Escalate the issue to your accountable Project Manager so that this doesn’t come as a surprise to them and to ensure that this is visible to the project board and ensure that the Technical Lead is aware that his current stance is also unacceptable. If he feels that he is unable to manage the output of the assigned development resources then he needs to escalate this via his normal channels. Denial of responsibility does not constitute removal of it.

Answer 2

You cannot refuse to do work. You can offer up an objection, you can propose a few other alternatives and state your case, but you must always support the decision and the team and continue. As a PM, you cannot allow a team member to "refuse" to do work. The only time refusal is remotely acceptable is when something catastrophic is predicted: safety, life threatening. If you feed into this by trying to "negotiate" with this developer, you are reinforcing the act of refusal, which means you can expect it to occur again down the line.

Remove the developer. Walk him/her out the door. Document your risk, do the best you can while you are searching for a replacement. Doing anything else weakens your position as a leader and pretty much stomps on your technical lead.

By the way, the technical lead saying he can no longer be accountable for.... You need to set him straight on that, too.

EDIT: I would concur that, as much as possible, conflict should be resolved where it is occurring, in this case with the technical folks. However, your TL is escalating, using words like I am no longer accountable and this developer is refusing.... At the point of escalation, the TL is asking for your help, which means it is time to step in. And if "refusing" is accurate, then time to cut bait.

Answer 3

Wow. Tough break!

Firstly, do you have a PID that outlines the approach to project delivery, including the development model to be used to deliver the project. I'm assuming not, which is a shame since that could be waved as the agreed approach.

However, my advice is this:

1. Trying to find a new methodology or approach that would mollify the disruptive team member would be a mistake. You are not in charge of deciding the development methodology (are you?)

2. It would likely be catastrophic to try and allow a sub-team of 1 within the wider team to plough their own path

3. I assume that the Tech Lead gets to decide on the development approach and that is certainly what has happened here. In that case it is not your responsibility to fix- The Tech Lead is (or should be) accountable and responsible for the technical output and if one of the technical team members is jeopardising their delivery they need to solve that problem. As PM you should take note of the risk and log it in your risk log (and make it visible in the project board meetings), you should also work closely with the Tech Lead to understand the risks, issue and constraints around this, and help to facilitate where possible/appropriate- but the Tech Lead needs to resolve or escalate to their technical management.

At the same time you should escalate to the Senior PM to whom you are reporting- This is a sensitive and tricky issue and leaving an inexperienced PM to try and resolve it is asking for trouble. It is a characteristic of inexperienced PMs that they try to solve all problems and keep everyone happy, believing that any failure that results in project problems are, by definition, their problems to solve. This is not the case. Your job is (amongst other things) to track progress against the plan and ensure that risks and issues are tracked and mitigated. If the developers came up against a thorny technical blocker they would not turn to the PM to solve the problem, and nor should anyone turn to you to solve this problem.

Make sure you record and manage the risks transparently and without emotion. Stick to the facts. Similarly record and manage all issues in the same way. However you do have to be aware of sensibilities, you cannot, for example just cite the problem person as the issue in your logs! Let the people best placed to resolve the issue, resolve the issue- they are the Tech Lead and the personnel respective managers. If everyone signed up to an approach, or even if they didn't but the TL decided it and that is usual behaviour for your company, then the technical teams should resolve it and your job is to call out the risks and issues and any delays and costs caused by the problem(s).

Good luck!

Answer 4

This is a tricky one, because of the complex management structure you're stuck with, and it doesn't help that the TL and the developer are being rather immature about it.

I would generally say to kick this one over to the manager of the developer who's being a problem, because from what I see, he's refusing to play nice with the team and that's a performance problem. The biggest potential problem with that is that his manager will agree with him, and the TL's manager will agree with the TL, and you get stuck with different teams having some stupid political battle over methodology.

You might also try having a one on one conversation with the problem developer and see what his objection is, explain the reasoning behind the agile/kanban approach and see if you can address his reservations. From my own experience introducing agile to developers who are new to it, they often feel like there's unnecessary overhead and they would be better off spending that planning time writing code (you know, real work). If you're not able to resolve the issue one on one, then try to get all three developers in a room to figure out the best approach.

As a guiding principle, I would lean towards supporting the TL (even with his asinine insistence that he isn't responsible for his team anymore), because his role is to be responsible for the methodology (making an assumption here; is it correct?) and because you're depending on him to make this project successful. I would not, except as an absolute last resort, dictate an approach. The most likely outcome of that is three angry developers who don't want to work.

Final note: so much of the approach to this problem depends on the personalities involved. Use the PM who's ultimately responsible for the project as a resource if you don't know the people well.