Hot answers tagged

49

Pretend the Waterfall team is an outside contractor Since you're interfacing with the Waterfall team's code solely via an API, just pretend you're hiring an outside contractor to create that code for you. The Scrum rules for how you write your code don't apply to them. You submit your requirements to them, they write up a formal Statement of Work for ...


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


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


19

First of all, make it known to your stakeholders that there is a project risk in your project. The waterfall team is asking for things (final, unchanging requirements) that you don't have at the start of your project. To mitigate this risk, you can analyse your current backlog for items that may affect the data that you need to exchange with the system ...


18

Responsible vs. Accountable Roles in a Pull-Queue System The question you're asking is really an X/Y problem. You have a couple of other problems that you haven't actually called out in your question: Kanban is a pull-queue system, not a push system. So, unless the API team knows to pull from your "feedback" column, or unless they have their own backlog ...


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


17

After having worked in a few different regulated contexts, I find it difficult to believe that you can't automate at least portions of the work needed to satisfy your compliance requirements. In my experiences, the claim that you can't is based on reading too much into the regulations and standards and relying on common misinterpretations rather than actual ...


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

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


14

Choose your battles carefully You mention you are new to the team and new to the organization. It will take some time before the team fully trusts you and your judgement. If that has already happened then you have more arguing power to support your point of view. If you are still very new, then have patience and wait a while. It's also very important to ...


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

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


14

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


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

I think this has a canonical answer, at least from a traditional PM point of view if not with Agile or Kanban or whatever else. If a piece of work was unable to be finished for whatever reason, by the mechanic, developer, trades person, whomever, then the issue falls back to the PM or PM control part of the project to be tracked and resolved. The ...


11

I have seen highly effective teams full of junior developers and disastrous teams full of senior developers. Rather than focusing on seniority and experience, I recommend: Hiring highly collaborative people Looking for a good mix of personality types (starters, completer-finishers, etc.) Hiring people with good leadership skills - willing to step up and ...


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

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

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

There are two schools of thought about what an Epic is. Some define an Epic as a large user story, often one that cannot be delivered in a single iteration. However, it can be placed and ordered in a Product Backlog and then be refined by the team when it comes up. The refinement activity will decompose the Epic into a number of User Stories, each of which ...


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