Hot answers tagged

25

It seems to me that you are trying to fill each sprint to capacity, and keep everyone fully utilized. Planning for 100% resource utilization is a bad idea. You will only end up with busy people and delivery will suffer. The point with Agile and Scrum is to deliver value. One QA tester to five developers can quickly turn into a bottleneck while work moves ...


23

I don't see any problems with raising concerns that you are aware of yet don't directly impact you. There may be ramifications to your relationship with coworkers if they see that as breaking some level of trust with you, but there's nothing from the process side that would prevent someone from raising a concern or issue on behalf of someone else. The ...


22

You don't make any mention of a Scrum Master in your Question, so I'm going to assume that either s/he doesn't exist or isn't helpful. If not, make sure you involve the Scrum Master! It's his/her job to address process issues. That being said, Scrum provides a tool to address things like this - the Retrospective. Here's what I would do, in your shoes. For ...


22

This is the sort of things people write books about, so this is just going to touch on a few things at an incredibly superficial level. Autonomy leads to motivation: Research has shown that autonomy is a key intrinsic motivator. Autonomy leads to ownership: By allowing teams to make their own decisions, they feel like the successes and failures of those ...


21

If the team is truly self-organizing, then the members would recognize that they have an issue that needs outside assistance and would, among themselves, find a way to resolve it. One option would be seeking someone else, either inside or outside the organization, who is a subject matter expert who can provide an expert decision. Another option would be to ...


18

Mark, you are absolutely correct that the PO has final say on the backlog and execution is owned by the development team. This doesn't mean that the development team doesn't have input or say. They should absolutely advocate for things they think are important. However, the Scrum Guide is very clear that: "The Product Owner is the sole person ...


18

Hat tip to Nvoigt, Nvogel & D. Espina - all good answers, with particular emphasis on D. Espina's "sometimes, knowing one of your team is overly optimistic, you simply add your own margins to their input." I'll just add one more frame to the question - this is a problem in risk management. The core, fundamental responsibility of the PM is to ...


18

Really good question. Really hard to answer. Here is my two cents contribution. Agile showed up as a response to the practices of the late nineties for building software, practices that assumed you could define everything upfront in such detail and plan them out such that it was then just a matter of following that plan to reach a successful outcome. But ...


17

The PO is the owner of the product, but that doesn't mean they can do watever they want with the product. At the end of the day, they represent the needs and the wants of all stakeholders. Inevitably, you might end up in some situation where the PO has a different vision for the product than some of the stakeholders, but, like reasonable people, the PO and ...


15

And I'm going to take the middle ground between Bogdan and Thomas... Whichever side has the more competent PO. Bogdan already listed the responsibilities of a PO. To (over)simplify it in a single sentence, however, it would be: The purpose of the PO is to act as a link between the customers and the Development Team. As such, the PO is really the only role ...


15

One possible approach you could consider is using the surplus developer time to create automated regression tests. In the long-run this will give you better automated test coverage and will reduce your dependency on manual testing, helping to alleviate this kind of problem in the future.


15

In Scrum the team aims to complete the sprint goal by the end of the sprint. It shouldn't be necessary to estimate day-to-day deadlines since the delivery date is always the end of the sprint. I suggest you could stop trying to lead, stop estimating and allow the team to self-manage. A team of three people is quite small however, and one problem may be just ...


14

That is a frustrating situation Chris. From your question, it doesn't sound like the team can't develop things in smaller pieces, but rather that they won't. I base this on the fact that it sounds like when the agile coach is there they do and just in my experience as a developer, the type of splitting you are talking about isn't usually difficult. In short, ...


14

There is no canonical answer to this question, although as a rule of thumb, it would be better for the PO to be from the client side, not the contractor side. The Scrum Guide says this about the PO role: The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: Clearly expressing Product Backlog ...


14

TL;DR Trying to "future proof" your data is done by making your tools, processes, and data structures flexible, not by fixing them for eternity. You do this by embracing test-first database design, ensuring your data is normalized and extensible, and that your tools and processes support change. You do not accomplish this by treating your data or ...


13

I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the ...


13

Vertical Slicing is a Best Practice, Not a Framework Requirement Your prerequisite tasks (by definition) must be prioritized over their dependencies, so a separate task or user story for C should be created to track it. The only reason this feels a little icky to you is that you're making at least one of the following implementation errors: Allowing your ...


13

Raise the matter first during a retrospective and find out how the team feel about it. One time I can see when visual feedback might be important is during sprint planning. In planning sessions the SM may need to guide both the PO and the team and will want to know that everyone on the team is comfortable with the sprint goal. There are alternatives to video ...


13

First, some clarification is important. Scrum does not expressly forbid any job. People in the Scrum Team can have any job titles as long as it respects the structure and rules of Scrum. Further, people can exist outside of the Scrum team that support the team as long as it does not violate the rules in Scrum. Now, I've worked in Scrum teams who are ...


12

TL;DR Part of any project management framework, but especially agile frameworks like Scrum, is the necessity of continuously managing stakeholder expectations. People want what they want when they want it, but a big part of project management is explaining to people what they can actually have within the various constraints impacting the project. As the ...


11

Tasks that are not listed increase context switching. People have to keep them in mind, but they forget. Then they remember about them in the middle of another task and think to themselves "Oops, I almost forgot, but I need to keep it in mind. What else did I forget?". This draws brain power away from the actual task at hand. All this may repeat multiple ...


11

I agree. These people are asking you – privately – to speak for them anonymously, and you also feel that it is an issue worth raising. Therefore, after carefully considering (perhaps, with them) exactly what is the issue and what might be done about it, I would recommend that you do raise the issue "as though it were yours." Now, you also have a separate ...


11

Let me challenge the frame of your question a bit: Why do you have such specific requirements that change for every ticket? Is it really necessary to have different margins between buttons on different pages? Is it necessary to have different styles for things on different pages? Isn't the job of a designer to create a recognizable style for the whole ...


11

In Scrum, "the team" is ultimately deciding how to implement stuff (within constraints that may be given by the organization.) Of course, this depends on the team being able to work together and come to a consensus. If one half insists that code must be written in C while the other half doesn't accept anything but Java you don't have a coherent ...


11

I think the timing is important. During the daily scrum, he needs to focus on the "what". During the rest of the day, if he feels his experience (to juniors) is valuable, then there's no reason to stop him from dispensing valuable advice. But he cannot pollute the daily. Once he has to "walk around" to dispense his advise individually, he ...


10

I think it is valuable to make a distinction here between a need you have for yourself vs a need the team has that you are helping them with. If this is a personal ask, then servant leadership has nothing to do with it. It's a request from one co-worker to another (or a bunch of others). You could raise this at a retro or in conversation - that's largely up ...


10

If a company is to be Agile, "the entire company" needs to be Agile. It's not something you just decide to do, or actually... decide on the development team to do. It's a change in mindset. For example, you can't keep things like traditional "Command and Control" attitudes in the company's top layers, while placing all the responsibility ...


10

The agile approach does not necessarily imply shortsightedness. Depending on the problem domain, you may have a very complete understanding (in your example, the industry exists for quite some time, has best practices, etc.) or a very limited understanding (such as a novel idea for a social network). Very complete understanding It would be foolish to throw ...


9

I'm a developer working with legacy code on scrum, and let me tell you, i think they're right in their ways, because i do the same. Let me explain my case, be aware though i'm what people consider a cowboy/hacker programmer: TL.DR: breaking everything on smaller items isn't good, you're missing on patterns & interactions: you're exchanging the chance ...


9

TL;DR Scrum is an empirical control process, and therefore "big, upfront planning" is intrinsically an anti-pattern. But Scrum certainly includes a lot of iterative and just-in-time planning, along with a predictable cadence and a set of inspect-and-adapt events when the framework is properly applied. Scrum Uses Iterative, Just-in-Time Planning ...


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