Hot answers tagged

51

It's not that you aren't supposed to report status in the Daily Scrum. Instead, the purpose of the Daily Scrum is to enable the Developers on a Scrum Team to understand the current state of progress toward the Sprint Goal and adjust their plan to maximize the chance of the team achieving the Sprint Goal before the end of the Sprint. What the Daily Scrum ...


47

If You Aren't Planning Together, You Aren't Working Together The Daily Scrum is not for addressing "issues," minor or not. It's a just-in-time planning meeting for the Developers to collaborate on the current day's work. If there are issues or blockers identified that won't easily fit within the time box of the Daily Scrum, then this is the time to ...


33

TLDR: You don't have a Scrum Master Repeat after me: The Daily Scrum is not an update-to-management meeting! Your Scrum Master(SM) is acting not as a SM, but as a manager. The problem is, the SM is not supposed to be a manager. Take a look at the described duties of the SM. Notice the complete lack of anything along the lines of 'track the progress of the ...


27

It sounds like you have team members from high power distance cultures. People may not speak up when the boss is in the room because their values require them to listen and follow, not to advise or lead. You may even notice it happening between junior and senior team members or between yourself and team members. Read more about power distance here: https://...


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

You ask: What is the best way to implement agile in these circumstances? Before thinking about this question you should think about how to bring in some common sense into the situation. Having people work overtime isn't sustainable in the long run and with time people start to make mistakes because they are tired and stressed. They end up working more and ...


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


20

So should you ALWAYS go by the 3 questions, or should you go by tickets? Or is there a way to tell when which approach is "better"? The 2020 version of the Scrum Guide removed the three questions, while the 2017 version of the guide says this: The structure of the meeting is set by the Development Team and can be conducted in different ways if it ...


19

If you do development work in the sprint, you should estimate. If you don't, then it's better you skip on providing your own story points estimates. You can help your team with information and advice, and support them to reach consensus, but you should let the people that do the work perform the estimates, otherwise you might be influencing them in one ...


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

Hiring and Personnel Management are Organizational Problems Testing is a Design and Programming Concern Modern TDD and BDD are architectural and programming concerns. In fact, I'd go so far as to say that any developer who hasn't embraced best-practice techniques like test-first design, continuous integration, DevOps pipelines, and so forth isn't really well-...


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

Testing should not mean executing tests (I expect that's what you mean by manual testing). The main business of testing comes in designing, developing and curating automated tests, analysing and understanding defects and fixing them. These are absolutely "development" tasks because development can't be complete without testing. Doing these testing ...


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


16

Any Agile practice, Scrum included, relies on collaboration and transparency for it to work properly. Your management failed at both these things. They are imposing a certain way of working on the Scrum team (in fact, forbidding to work a certain way, which is even worse) without asking input from the team, and without even providing an explanation for the ...


16

There is a lot to unpack in your question, but from what I read I see two main issues: the old guard (as you name it) doesn't want to change their way of working. What they did might have worked before, or not, but they found themselves a certain pace of doing things and the changes you want to bring forth are not to their liking. Since you mention a new ...


15

Analysis There is a chilling effect when he is here. Am I overreacting? Should I just try to build up the confidence of the team? or should I ban my boss from the retrospective? In my experience, this is a classic case of missing the forest for the trees, and mistaking process problems for interpersonal ones. Let's enumerate some of the issues that ...


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

Does Scrum take into account interruptions? Scrum does not. The Scrum team does. Scrum teams are self-organized and plan their own work. If part of that work consists of fixing urgent bugs from production or handling requests from other teams, then the team needs to find a way to organize around that, how exactly depends on the context: they might ...


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


15

It looks like Scrum doesn't address this issue in any way? No, it doesn't. Scrum is a guide. Although it prescribes stuff, it doesn't prescribe a lot of stuff. This is one of the things that are left at the discretion of the implementer. For ex, it used to provide a sample for 3 questions to ask during the daily, but those were dropped eventually (probably ...


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

Building only a user interface prototype will not usually reduce risk. It may increase risk because it would not deliver a working product. The better approach is usually to do whatever you need to deliver a working feature or features in a single iteration, which is what Mike Cohn suggests. Don't confuse uncertainty with delivery risk. Uncertainty is normal ...


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

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


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