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


33

With that much variation in the estimate, it seems like the work as it's currently defined is not ready for estimation yet. Based on that wide spread in estimates, I would say that the team doesn't have a clear understanding of what is required to complete the work. Unless the work was critical and must be started and get to done as quickly as possible, I ...


25

I don't think there is a simple answer to this question. Instead, I think there are a number of different scenarios: A team is very experienced in Scrum and rotates the Scrum Master role. They have no need for a full-time Scrum Master. A team is very experienced in Scrum, but they still face impediments and they prefer not to be distracted, so they ...


23

The first thing you should do is encourage the team to bring concrete arguments. "Things are more complicated than they seem" or "I dont think those complications are valid" are very vague arguments. "I disagree, because the database-adapter has 3.000 lines of code, so changes in this class are very hard" or "Finding all methods doing X takes a long time, ...


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


21

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


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


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

Story points are a relative measure of effort rather than an absolute one. However, each member of the team should have the same understanding of the size of a points estimate. A common understanding is achieved when the team estimates repeatedly together and when they agree common baseline stories against which to measure. This is really no different to ...


14

EDIT: First off, you have a bigger problem. The team that I've taken over doesn't currently do retrospectives or sprint reviews sadly. You may have tagged the Question as scrum, but you're not doing Scrum. Before you try to fix any of the numerous issues that pop up as you try to implement your Scrumbut, you need to first try Scrum by-the-book. If you don'...


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


13

One of the advantages of having such a small team is that, indeed, the people in the team are able to communicate freely throughout the day. A lot of the daily stand-ups might thus often end very quickly and may look like they are a waste, but they can still have a purpose even in a small team like this: to provide extra focus. The daily standup allows ...


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

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


12

Facilitate Communications; Don't Proxy Them In your specific example, the Scrum Master should function as a communications facilitator, not a proxy for the team. The Scrum Master often functions as a switchboard operator by: Helping team members to identify points of contact outside the team for collaboration and refinement of Product/Sprint Backlog Items. ...


12

Let's be serious, people don't usually care how you do estimates. What they care about is how much it takes and/or how much it costs. Time and money. That's what they want. The estimates is just something that helps you answer those questions. It doesn't matter what you use for estimations as long as people can get back a time or money value. It can be ...


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

Identifying the Story's Primary Consumer is Acceptable The term "user" in user stories is often better understood as an actor or role in a use case, or even simply as a value consumer. The primary goal of having a clearly-defined role in a user story is to frame the story to constrain scope. The secondary goal is to ensure that the user story is seen as a ...


11

Robert C. Martin said at one point about the Scrum Master that it: [...] should be a temporary role, to remind people to follow the steps of the process. It's not a separate job, but something one of the team should do for a bit, then pass it on. After a while the team shouldn't need a Scrum master as they will know how to operate their process. Maybe ...


11

shouldn't the adoption of agile values be present on both sides? Yes, it should. But often isn't. The problem is that Agile/Scrum is more of a mindset than a way of working. But people all throughout the organization see it as a methodology for developing software. If you are an executive, a business person, or working in some other department within 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 ...


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


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


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