Hot answers tagged

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

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


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

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


6

Adding to the excellent answers you have already. Perhaps consider asking the team to do an experiment? Make the change you propose for a given amount of time and then review if it made things better or worse. There is often less resistance to an experiment than to something perceived as a permanent change.


5

Agile thrives on collaboration between people, rather than building walls around each team and throwing things over it. The ideal situation would be that the designers work in the same team as the developers and create their designs as the software is being developed, with the technology used to deploy the designs. This way, the designer is the one who ...


5

It seems that you are considering certain things to be immutable. Like having to always split stories vertically, or that there shoudn't be dependencies like C, or that once allocated story points can't be changed. These are not immutable. All the projects out there, all the products, all the features, and all the stories, will never fit entirely with all ...


5

This is a problematic question to answer because the "Spotify Model" isn't really a model or a framework or anything that would contain an answer to your question. What people call the "Spotify Model" was a white-paper that generalized the approach being taken at Spotify at a specific moment in time. Therefor, there can be no right answer ...


2

Teams Have Velocity; Team Members Don't Tracking velocity at the individual level is a common agile implementation error. It often occurs when teams or organizations are misusing velocity as a productivity metric or management target. Please don't do that. The point of velocity is to provide an aid to capacity planning. To be effective in estimating team ...


2

Agile doesn't prescribe any practices - it's all about you choosing how you work because it suits your situation. Particular methodologies though can be prescriptive - Scrum is a good example. If you feel like Scrum doesn't suit you anymore (are you sure it suited you before?) - change the process. You don't have to follow any specific methodology - being ...


2

I believe the misunderstanding is that the squads do not "own their own product". Typically, in the Spotify model, Squads will own part of the system or product. Squads are aligned into Tribes. In an organization with multiple, distinct products, I would expect alignment between Squads and Tribes in a way that each Squad or Tribe is aligned with ...


2

I see three options. My preferred option, in this case, is to have stories A and B. The work for C would be denoted as something that needs to be done in both of them. If the team is estimating, then I would estimate both as if the other didn't exist, and the set of work C was part of both. This enables you to choose which one you do first without missing ...


2

Or Is it always All Or Nothing with Agile practices? Agile is a set of values and principles, a mindset of how to develop software. You can create your own version of Agile methods, it's not just Scrum, Kanban, XP, etc. But if you go with one of these, it's best to use them as prescribed. I see you tagged your question with Scrum. If you give up on things ...


1

TL;DR As a member of the Scrum Team, you should articulate your needs and preferences as worthy of consideration by the whole team during a Sprint Retrospective. However, as a Scrum Master, your job is to facilitate the team's smooth functioning within the framework by supporting whatever works for them, so long as it doesn't contravene essential framework ...


1

This is a large topic to answer so I'll just add some general information. If you have other questions or things are still unclear, you should open more specific questions. In more traditional software projects that employ sequential phases for building software (like the Waterfall model for ex.) releasing software (i.e. making it available to users) ...


1

Release process means the steps you have to go through to get a product or product change into the marketplace or being used in its intended context. It is usually independent of the methods used to develop the product but is very dependent on the type of product, the technologies used and the organisation you work in. Release planning is something different....


1

Agile is all about responding to change. If you favour responding to change then you are likely to be doing the estimating relatively close to the time the work is to be done. In this context, the situation in your question is far less of a problem. Say, for example, we are estimating these stories a few days before work starts. A decision can be made about ...


1

It's a common problem when managing soft dependencies between stories. If A and B are small enough to fit in a single sprint then that's the most logical split. Avoid creating technical story for C if you can. For estimation purposes it's up to the team. If there is a clear priority order then you can build the technical effort (C) into your estimate for the ...


1

Scrum and agile practices can be followed with team members in different locations/time zones our IT developers and IT managers work from home. Furthermore, and in different time zones and different locations. Therefore, daily Scrum meetings are Not really practical for us. It is not clear to me why daily Scrum meetings are not practical. I have managed ...


1

One way to mitigate this problem is to focus on creating automated regression tests. This will: Reduce your dependency on manual testing and hence on the QA Mean that each team member is capable of working on development or testing In the short-term this may have an impact on the output from the team. But in the medium and long-term the automated ...


1

There are basically only two ways to deal with this type of situation: fix it or accept it. Part time people on teams and/or projects cause major issues. You loose productivity because of constant context switching. You loose time because you wait for people to become available while they work for someone else's team/project. Your planning gets messed up ...


1

There are a few things that I can see that are hampering you. Scrum is a framework designed around a product being built and supported by a cross-functional, self-organizing team. Since you talk about projects and people working on multiple projects, Scrum may not be the best fit for you. Even if it "works", you won't get the full advantages if ...


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