4

Scrum intentionally does not layout exactly how the team will build the product. There are a number of reasons, but most pertinent to this question is that what works for one team may not work for another. Similarly, what works with the tools of the early 2000's may not apply as well today. One of the reasons we work in iterations is because it gives us ...


4

I think DevOps defines the best practices here: specifically the principle of small batch sizes. In other words, if the batch sizes (code commits) are small, then the code reviews can be frequent and short. I would live with the frequency because that's more of an Agile thing and it's OK! Build a team culture that supports it. DevOps also tells us to ...


3

I am not aware of a process that explicitly discourages developers to pick their tasks. Instead, most agile frameworks encourage the use of self-organising teams. One aspect of being self-organising is that the team will decide how tasks are distributed amongst the team members. It would certainly be legitimate for a team to try a random or pseudo-random ...


3

You ask: Is there a process that promotes the group to assign tasks to individual developers. The tasks should be assigned as part of a group decision and as part of what comes next. What you need to do is to explain to the team (those doing the picking) what you are aiming at. This may then encourage them to divide up the task as you expect. Once they ...


3

I suspect there is no single answer to this question. Individuals are different. Some may find that doing a code review is a welcome distraction from their coding tasks. Others may struggle with the context switching or may not enjoy doing reviews. Teams are also different. I can see the nature of code reviews varying depending on many factors including: ...


3

It depends. It's important to realize that Kanban doesn't have anything to say about code reviews. It's simply a set of tools for visualizing and improving the workflow and flow of work through a workflow. There are a few key concepts - the Kanban board which provides a visualization of the workflow, work on the board, work-in-progress (WIP) limits, work ...


3

Might be too broad to be answered, but I'll give it a crack. First, by In the meantime a former decision maker is still with one foot in and I am in charge of decision making now I assume you mean that there's a highly-placed employee that is still interested in the project, but no longer has authority. So, first thing is to touch base with him to ...


2

You need to get VISIBILITY into what's happening there. Right now you seem to be mostly blind to what's going on and you are forced to trust this external provider. A 3 months estimate turned into a 9 month one. Any chance for the 9 month estimate to later turn into 12 months? Check your contract and see what the agreed deliverables are. Do they deliver ...


2

Agile is about self-organizing teams. The team is the one that can figure out the best way of doing the work, and usually, you end up with some kind of pull system. People take work, they are not assigned work. If the team decided it's a good idea to encourage everyone to take tasks that they are not familiar with, then that's one thing. If you want a ...


1

You can use a self-hosted repository such as gitlab or gitea/gogs. Gitlab is pretty full-blown with commercial and community (free) versions, gitea (which is a fork of gogs) and gogs are very light-weight. I run gitea on my private server for stuff on which I'm working from different development machines. For just 5 developers, it's probably all you need. ...


1

TL;DR Code should be reviewed when someone is ready to review it, and when the team has the capacity to perform the code review without "stopping the line" or impacting other work-in-progress. Analysis In any pull-queue system, work is pulled (never pushed) when someone is ready to work on it. So, work should be pulled into your "Code Review" column when: ...


1

As others have indicated, your contract should detail how to resolve a dispute with your vendor and you're on the hook to follow those terms. My first action would be to work with the vendor so I can attempt to understand the true health of their work; I would provide them with a deadline of a few days to bring forth verifiable evidence of what is completed ...


1

Nine months or even three months without any delivery is already a red flag. De-scoping in order to meet a deadline that is still months away also seems like a poor way to manage a project. However, extracting the project from the agency, attractive though that may seem, would surely incur some significant risks and costs. Firstly, understand what is their ...


Only top voted, non community-wiki answers of a minimum length are eligible