Hot answers tagged

20

Your problem is not that you have developers and non-developers (as you call the business analysis/product owner, the designer and the testers). Your problem is that these people have individual ownership on their slice of the cake and not on the entire cake. Here are a few things from the Scrum Guide (emphasis mine): Development Teams are cross-...


17

Your team appears to do mini-waterfall development within each sprint, which is a known anti-pattern, as you don't get the collaboration within the team that make agile methods successful. Also, Scrum only has 3 "job titles": Product Owner, Scrum Master and member of the Development Team. There are no separate developers and testers, they are all equally ...


10

You are doing a lot of good things already, but I would also recommend the following: Reduce how much you bring into each sprint Keep on reducing it until the testing bottleneck disappears and the team completes all the work they allocate to a sprint Continually reinforce the point that the team's job is to deliver completed items, not to do lots of coding. ...


9

You asked in terms of scrum, so that is how I'll answer. However, there are a number of red flags in your question that lead me to believe you aren't actually doing scrum (and I am far from a scrum purist). The scrum answer would be: as PO, you are responsible for the product backlog and priorities, not for process improvement. If you see an issue, you ...


9

Other comments here all ring true: too waterfall-y, not enough team responsibility, etc. but I'd like to emphasize a point made just once in other answers: you're absolutely setting goals too high. You HAVE to set bite-sized goals that are achievable, no matter how slow that is. If that doesn't fit the business schedule, the business schedule cannot be met ...


6

The first question I would want to consider in your position is: Are the issues being seen in test because the code is unreliable, or because the requirements have not been understood? The developers are presumably getting bogged down in ensuring the correctness of the code, but of the following two scenarios: The developer writes what they think should ...


4

First of all, every customer facing bug has an impact on revenue. That impact can be big or it can be small, but the impact is there. With that in mind, I would recommend extending the criteria for the various urgency levels to include guidance on the possible revenue impact. For example, bugs with a low revenue impact can fit in the lowest urgency class, ...


3

I'm getting a lot of "us" vs "them" feelings from your question, which is a major red flag. As a PO, you're part of the team, there's only "we". Others have touched on how it would be better to not have separate "sub-teams", but just one cross-skilled team, so I won't elaborate on that. I think your main problem is that the team is getting pushed to ...


3

Increase Your Collaboration with the Scrum Team However in this particular case its not an option. Not an option is generally business-speak for: "We want different results, but refuse to change any of the underlying factors." That isn't agile, and generally leads to finger-pointing and other non-constructive business anti-patterns. Front-End team ...


2

From a developers point of view, other answers concentrate too much on theoretic practices. To have any concrete answers, it is essential to know what kind of tasks the developers are dealing with. Also much of the time the problem is not the task bounced back, but some other task in the testing queue. That sentence suggest that there is a mismatch ...


2

I think that I would call for an "all-project stop and regroup." This team is obviously on a Death March, and that never works. You need to help the team – and, management – to understand what is driving the team to even attempt this. Are the expectations realistic? Is the analysis process any good? Does the team – well – really know what they are ...


2

When you receive a bug report, it needs to be triaged. The workflows that I use tend to look something like this: Review the bug report and confirm that it truly is a bug. Some people who report issues may not be aware of the intended behaviors of the system. The issue reported could be acting as designed. Assuming that the issue is a bug, check the quality ...


2

It is perfectly normal to have people of different skills and capabilities working in a scrum team. Therefore, it is normal to have Back-end, Front-end and QA roles separately in a team. Success of the team depends on not treating a small group of people within the team as a sub-team. The concept of sub-team works against the concept of scrum team. It is ...


1

Yes, and I will "circle back and add another answer" to say that the root-cause problems here are very-obviously external to the team. If programmers have been told that they must kill themselves to produce the necessary software ... they are not(!) ... ever(!!) ... going to "produce the necessary software!" Therefore – (putting on my hard-nosed consultant ...


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