8

Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories: As an SDK user, I would like to be able to grant permissions to a user so that I can manage what different users can do. and As an interface user, I would like to be able to grant permissions ...


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


6

Welcome to PMSE! From the Scrum Guide: Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. So, your goal should be to progressively move away from the notion of "dev owners of features". Also, it is good to set aside bandwidth for handling unforeseen ...


5

Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically. So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case. Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns ...


5

I second ctrl-atl-delor (+1!) - you should invest on automation. Agile methodology helps on how work is organized, but regardless of the methodology, you should automate as much as possible of your work. We have a similar scenario in our project - and I'd guess it's fairly common on legacy applications. You have two main fronts of work: SDLC automation:...


5

TL;DR In most cases, you should only have one project per product. The desire to split a single product into multiple projects is usually a sign that inter-team collaboration and iterative integration have become a central bottleneck for your process. I provide additional analysis and recommendations below. One Product ➡️ One Project ➡️ One Integrated ...


4

TL;DR You present two choices for your team, but it's a false dichotomy. The underlying issues are really: the lack of intra-team collaboration during development, and insufficient slack in your process to maintain a reliable cadence. In the answer below, I reframe your current problem in order to analyze your chosen solutions. I then offer a "top ten ...


4

The practices are not mutually exclusive and, in fact, dove-tail together well. Unfortunately, it is unlikely that either will address the problem you state. Both BDD and TDD write tests as you go throughout the work. You still need to bound the backlog item. Most teams do this with acceptance criteria during backlog refinement or, at the latest, in sprint ...


4

Generally, the question I would ask is: "What benefit do you gain from splitting them?" The risk in splitting them is that your prioritization loses focus on end value and, more broadly, that you could get a lot done, but not meet the success criteria of the project because some teams excel while others struggle and you erode focus on that. Many times I ...


4

Well done you are doing a grate job. Scrum has lead you to diagnose several problems with your process. I would recommend devops, developers and ops merge. They then fully deploy to testing (that is the same as operational). After testing you press a button to deploy to operational. Docker is a good tool to help with this. The other thing (and most ...


3

Perhaps the most important question is: why do you want to? There are a lot of groups out there that they that "Agile Development Practices" will make a traditional project complete faster. While this isn't strictly wrong, it commonly fails - the main reason for this being that without a proper understanding of why different practices work, its hard to ...


3

Combining an agile development approach with traditional waterfall can be highly problematic. Effectively you have two approaches that are pulling in opposite directions. Waterfall is about planning and following plans whereas agile is about responding to change. I have worked in organisations that attempt to combine the two approaches and some of the ...


3

Is there an optimal workflow to still work with the DC and not leak money going back and forth discussing requirements and get a (mostly) accurate estimate in a short amount of time? Sadly, the answer to this is almost always "no". In software development there is inherent uncertainty. This arises from several factors, including: Requirements are often ...


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

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

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

@tiagoperes's Answer is good, but a radical change to suggest. To provide a less radical suggestion: have you looked at the cone of uncertainty? The idea behind the cone is that all estimates are ranges. The range starts out very wide but then narrows down as more information is gained (eventually becoming a point, once all uncertainty is gone - if you ...


1

From what I read in your message, the problem isn't the estimation itself but the whole organization of the team with DC and Devs in charge of PO's responsibilities. So, that middleman shouldn't exist and PO should finish the requirement documents after DC gives requirements to PO. You still work with DC, just in a more organized way. This answer I'm ...


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