How much project management is a software developer supposed to do?

  • To not be too broad to begin with, the direct question would be:

    Is it expected that a developer should continuously remind project manages of a feature not implemented because he lacks resources to implement it?

    The rules are as follows: We have a board with tasks in columns. A developer picks a task in "OPEN" and starts working on it. As he does that, he moves the task to "IN PROGRESS". When he is finished the task goes to "DEVELOPMENT DONE" (later into testing). But if something goes wrong the task should be moved into "FEEDBACK" where something needs to be resolved. Maybe design is missing or some description is unclear...

    Pretty simple if you ask me.
    In my opinion as developer when a task is not completable and its ticket is in "FEEDBACK", it is a responsibility of a project manager to keep track of a feature and take effort to find a person who can resolve the problem on it.

    But what happened in our team: A ticket was sent to "FEEDBACK" as the API that was needed was not implemented. The ticket sat there for a few months (yes, close to half a year actually) and then at some point one of the project managers simply closed the ticket because another project manager reported that he forwarded the issue to another team. Another month passes by and suddenly this not-completed-feature comes up. Now one of the project managers is furious and claims that it is our responsibility as developers to keep track of such things and that he would expect we have some sort of list of things-that-are-not-done.

    Is this true? Should we somehow keep track of some extra things next to the board we already have? I would expect that a single board should suffice for such things and the development team did all in their hands to prevent such a mess. If not, do you have any recommendation on how to avoid such problems or how to better track such potential issues?

    To give a full story on how/what happened:

    We are making a mobile application. A few months ago we received a request that on a specific screen (rarely seen by a user) an error may be received from the API (because of some rare situation). Now this specific error will also report a sub-error code. So if this error occurs, a sub-error A or sub-error B will be added. And depending on this sub-error the app needs to show either screenA or screenB. But the API did not provide A nor B and the task completed could not be validated or tested.

    So the ticket was put into "FEEDBACK" explaining that the API is simply not ready for it. But then some discussion started on the ticket about seeing the screen anyway just to check the design. So the developer added a logic to randomly show screenA or screenB and reported this in the ticket which was still in "FEEDBACK".

    Months passed and at some point one of the PMs tried to handle this. So he (I assume) reported this to the team responsible for API and commented on the ticket, something like "They told us this is a bug on their side. Mention: theOtherPM, can we close this ticket now?". And "theOtherPM" then closed the ticket. Another month later all hell breaks loose over this and I am confused why is this the fault of us developers.

    Note: Another thing to mention is that the other team, which is responsible for the API (among other things), is not part of our network and not even part of our company. We, as the development team, have no direct communication with them. So there was no other way to solve this but through our management.

  • Responsible vs. Accountable Roles in a Pull-Queue System

    The question you're asking is really an X/Y problem. You have a couple of other problems that you haven't actually called out in your question:

    1. Kanban is a pull-queue system, not a push system. So, unless the API team knows to pull from your "feedback" column, or unless they have their own backlog for you to place the work items onto, it's unclear why they would be expected to pull the work (or even be aware of it).
    2. Agile frameworks are highly dependent on cross-functional communications. If you're just statusing tickets, rather than collaborating with stakeholders like the API team, then your process is broken.
    3. Work items that aren't clearly tied to a milestone or deliverable aren't being tracked. There's no way to determine from your question alone who owns that within your company's current process.
    4. The distinctions between the responsible and accountable roles for your process have either not been defined, or insufficiently communicated.

    If you have tradition project managers who are responsible for the project, then they are ultimately accountable for tracking the status of work items and reporting them appropriately. This is true whether or not they delegate some of that responsibility to members of the team.

    On the other hand, if you have a truly agile process, then both responsibility and accountability for tracking work items should be clearly defined by the team's working agreements, both within the team and with other teams. There's no right or wrong answer to who should be accountable or responsible, so long as it meets the needs of all stakeholders, including those of the project team itself.

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2