11

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.

Improve this question
9
  • 5
    Is there even the possibility of an authoritative answer to this? Isn't this going to vary from site to site/team to team?
    – MCW
    Commented Mar 24, 2020 at 13:55
  • 1
    @MarkC.Wallace I hope not. I would believe there are some general agreements about responsibilities of one position and another which should objectively point into one or the other direction. If not then "This needs to be defined within your team specifically" is a valid answer as well provided that you can have at least some arguments for both sides.
    – Matic Oblak
    Commented Mar 24, 2020 at 13:58
  • 3
    As a project manager who is also a seasoned developer, I would answer that it is your team's responsibility to keep track of the tasks that you either create for yourself or that are assigned to you from the outside. You are the ones who are actually developing the source-code and who are, of course, intimately familiar with the internal complexities of the underlying software implementation. Project managers generally focus on a higher and broader level of concern: "the project itself." They rely upon you to accomplish the bits-and-bytes minutia ... correctly and visibly.
    – Mike Robinson
    Commented Mar 24, 2020 at 15:29
  • 1
    Further: imagine yourselves to be the "subject-matter experts (SMEs)" of how, exactly, this application is being constructed and debugged so that it accurately and completely performs to-specification. That is your concern. Meanwhile, the project managers are looking, for example, at that specification ... at the surroundings in which the application will function ... at all the other projects and workgroups that might impact or be impacted by your work "They're looking at 'what, not how.'" Two parallel but different viewpoints and responsibilities, both essential!
    – Mike Robinson
    Commented Mar 24, 2020 at 15:32
  • 2
    Not that you should ever "go around the project managers to get resources!" If there is a problem with a remote team, they need to know it right-now. No, they don't need to know bits-and-bytes details but this is something that's roadblocking the project. // Obviously, this whole thing comes down to a communication failure. "Closing the ticket" might have been accidental, or misinformed. The cause should be investigated to understand.
    – Mike Robinson
    Commented Mar 25, 2020 at 15:58

2 Answers 2

Reset to default
17

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.

Improve this answer
4
  • The problem with your first point is that the API team is not part of our company and is for us more like a resource. Development teams have no direct communication with them so our PMs need to forward this "bug" to whatever means they have (From my understanding they have open communication, weekly meetings even, with the other company). So this ticket was pulled by a PM, the process was triggered, but the ticket got lost. Then it sounds as if it was implied the development team should have yet another Kanban which would track something not implemented. To me this sounds strange.
    – Matic Oblak
    Commented Mar 25, 2020 at 6:12
  • The second point also has similar problem than the first. I must agree that in most projects I worked on we would have direct collaboration and communication with other teams within a project. But it was not always so and I am not sure that this breaks anything. For instance some years ago I was working on an iOS remote control for a drone. Beside other things I needed to integrate a framework which was done by another company on the other side of the world. The framework was still in progress similar to API in this case. But I never met the team that made the framework. Is this a no-no?
    – Matic Oblak
    Commented Mar 25, 2020 at 6:16
  • The conclusion is interesting and kind of leads to what bothers me the most: The rolls are not clearly defined but at the same time as soon as a problem occurs finger is pointed. The reason why this bothers me is that the problem itself is not analyzed and no effort is made to ensure that this will not occur again. And unfortunately this has already happened twice and I still have no clue on how to approach this. This is why I turned to you guys for some help. Thank You.
    – Matic Oblak
    Commented Mar 25, 2020 at 6:29
  • 1
    I agree – fingers are pointing and the collaborative process is broken. I would think that the development teams and development managers, not higher-level project managers, would be responsible for the communications with the remote contractors because of the level of pure-technical context that is required to communicate effectively. "Kaiban" or no, someone's not talking to someone else and right now it's costing you a lot of money.
    – Mike Robinson
    Commented Mar 25, 2020 at 16:01
10

I think this has a canonical answer, at least from a traditional PM point of view if not with Agile or Kanban or whatever else.

If a piece of work was unable to be finished for whatever reason, by the mechanic, developer, trades person, whomever, then the issue falls back to the PM or PM control part of the project to be tracked and resolved. The assigned project personnel who was to implement that work either moves on to other work or even leaves the project site. That role would no longer, and in many cases, can no longer track and control that issue. The responsibility becomes the owner within PM controls and that could vary project by project.

If something breaks down in that process and that item is lost, the accountability of that loss is with the PM or PM controls.

Improve this answer
2
  • In a highly-technical scenario like this one, I'd prefer to say that the PM is responsible for knowing about the existence of the issue and knowing that it did get timely resolved. I would expect the development managers, working directly with the "home team," to be the ones who are communicating with the contractors, constantly providing information to the PMs but not asking them to be intermediaries. (I get the sense that in the OP's organization they are being asked to play these roles ...)
    – Mike Robinson
    Commented Mar 25, 2020 at 16:03
  • 2
    Roles can be defined in many ways. Some role definitions just won't make sense, however. I know most of the topics on this exchange are about software but I often consider other types of projects in answer these questions. I am thinking about a plumber on a housing job that ran into a blocker for his work. Plumber reports the issue and then leaves or goes to another part of the house. I cannot imagine the plumber being responsible for moving the blocker. Could require contract change, architecture change, engineering change. Out of scope for the plumber.
    – David Espina
    Commented Mar 25, 2020 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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