6

Why should a developer want to work Agile? Because a properly-implemented agile framework improves the pacing of a project and the sustainability of the developers' work efforts. It also increases collaboration between developers and stakeholders. If it doesn't do all of these things, then the team (or the organization) is probably Doing Agile Wrong™. ...


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 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 ...


3

IT IS! People forget this or gloss over it all the time. Pushing authority down the hierarchy has a lot of benefits for the organization and the individual but it is definitely harder - and for some people, it isn't worth it. For those that find it worth it, some of the most common reasons are: 1) Pride - Along with ownership comes a pride in the work that ...


3

If I understand your situation correct you are looking for a way to help teams to talk about/analyze/assess what areas to improve and give the people that supports these teams (mangers, coachers, etc.) a high level summary of what’s working and what’s not. Based on this I would recommend you to look at the Squad Health Check model by Henrik Kniberg. What ...


2

So, I need to assess the health of the engineering process as it currently is and make recommendations for how to get it to a better state moving forward. As this is an agile environment the questions I would be asking include: Are the teams themselves failing to self-improve? Are the teams empowered to fix their own problems? Is the working environment ...


2

Todd covers quite well (+1!) the reason from an agile team perspective. I'd like to add a parallel perspective to it - why a developer would want to work on an agile team. First of all, agile is not for every developer. Not that's a problem per se, as there's still a lot of projects out there that are follows Command and Control approaches (some even using ...


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 ...


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