44

The Daily Scrum is not an update-to-management meeting! From the Scrum Guide (emphasis mine): The Daily Scrum is a 15-minute time-boxed event for the Development Team [...] This optimizes team collaboration and performance [...] The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the ...


41

Conversation is Not Inherently Disruptive I work with a team of developers who are talented but often distract each other with chit-chat. You say they are "talented but distracted." What makes you think they are talented? Why do you think they are distracted? What is your metric for determining that the team or the process is operating at a sub-optimal ...


16

If you ask this question, or even if you have troubles answering it, you are likely a victim of dark scrum. A daily scrum meeting, done right, has no micro-management. Terms have power, and dark scrum is one of these potentially important terms that I would like to see spread. Scrum was never made for this kind of micro-management, and its mis-use can have ...


14

In addition to Sarov's excellent answer, there is also the purpose of the meeting. The daily standup is not a management engagement. Neither the Scrum Master nor any other project or senior manager is doing any managing during the daily standup. I see this even stronger than Sarov does - not only is management not being reported to, there is also no flow ...


13

I strongly believe in being with a team. Let's consider a simple example: your team faces a critical issue. People are trying to track down some technical glitch but they struggle to catch it. Anyway, they decide to stay late. Still nothing. Another day the situation is the same: they decide to stay late. Now, where a manager should be? The manager won't ...


10

Your Capacity Planning and Prioritization Processes Need Re-Engineering You appear to be attempting to solve the wrong problem by treating this as an individual-availability issue. This is most likely because you have a weirdly-matrixed organization that isn't based around project teams or team capacity planning, but apparently based on the notoriously ...


10

I don't know why aclear16 deleted his answer. His answer is perfect. There are a ton of positives with idle, unproductive time by way of teaming. It matures the team and you want that. I'd even go as far to say that, if you are running behind, let the social time continue because the positive aspects of that will help, not hurt. And likely the down time was ...


8

The first issue you must face: Are distractions good or bad? I think this can not be answered with either a clear yes or no. First, no developer can work 8h on end and still remain sane. On a good day you get 4-6h of concentrated work. But don't think that, since they are not sitting concentrated at their desk that they are "not doing work". In my ...


7

Whatever you do, do not micromanage! That is the single worst thing you could do. You will put a lot of stress on them, on yourself, you will kill the potential productivity of the team, and you make yourself the bottleneck on the team. I am not saying your team is a bunch of whiny kids, and I certainly am not saying that they are useless, but my ...


7

I second @sqreept opinion (+1!), you're trying to deal with the symptom rather than with the cause. Having said that, my opinion below only represents a few between all possible scenarios. Now, the scenario: my team is chit-chatting a little bit too much Why? Because they know they have loose deadlines to meet. Why? Because developers tend to be ...


6

You are doing the right things and acting as a Scrum Master should. It sounds like you may need to do some coaching, explaining to the team, to management and to the stakeholders how Scrum works. Try and back up as much as you can with evidence, such as quotes from The Scrum Guide, from articles and blog posts on reputable websites. It would also be good ...


6

Not sure if it would help, but an analogy I often used is comparing velocity to your time on a 5K run. (credit where it's due, I adopted the analogy from Mike Cohn) It's only observable. If you think, "I'll just run harder" you'll just burn yourself out early in the run and probably get a slower time. Instead, you can take actions that you think will improve ...


5

Under any other circumstances expecting to get a daily update from developers would be considered micromanagement. That's not true. I'm not even sure if we are defining micromanaging properly here as there are ways to micromanage without requiring a daily update from developers. A Scrum standup is not for management. It's for developers and by developers....


5

There are no consequences for not performing in your organization, so what do you expect? There can be valid reasons for a project being late. They should be presented to the leader when they are recognized, so you can do something about it before it is too late. The leader has to know what is going on and be able to spot excuses. If you have too many ...


5

I agree with Barbaby Golden, and would like to add what helped when I wanted to show the impact of changing the teams often: Show the management the velocity that is achieved in the last X sprints to show what they can do,backed up with actual numbers Check when developers left / joined and see if there is a noticeable change in the velocity around that ...


4

Your question has one answer & one hidden question in it: "overdoing the symptomatic chit-chat?" overdoing: When is normal chit-chat become overdone? symptomatic: Yes, you're right. This is merely a symptom. Don't try to fix the symptom. But, from experience, if you worry about chit-chat and that becomes visible, they'l unconsciously do more of it :) I ...


4

When the "stand-up" is properly orchestrated, it's a free exchange of ideas about each other's work. It's meant to enforce collaboration, not confrontation. Unless your manager is actively developing with you (they usually are) they should not be in the meeting. Too many times have I worked on projects where people who worked across the isle from each ...


3

Consideration should be given to the nature and size of the organisation, and the number of projects / initiatives being run. If the team is likely to flex significantly in terms of the people working within it, and if there are several (or many) teams all working on different projects, then it may be necessary to consider the reality of having people moving ...


3

I have been in sort of a similar situation before we went full Scrum with actual planning with the teams and Product Owners to define the sprint backlog. What we were doing to mitigate the constant flow of requests to the development team (20 devs, 7 QA) was the following: had a good idea of what the dev team capacity is, depending on historical data, ...


3

There's too much going on in your question to give concrete advice but here are some basic rules I usually apply: If a project is complex or complicated and non-repeatable, use scrum. If your project is simple and/or repeatable, use whatever process method you prefer If your project is in chaos, do anything but get out of the chaos and into the simple, ...


3

I guess it is one of the most common problems - a PM needs to use bunch of tools and methods to steer the project and keep everyone happy except himself. It is true that you need 4 core aspects: Planning/schedule Organizational environment for collaboration Analytics and metrics Reporting I would suggest taking a look at tools that offer everything in one ...


3

Document the minimum required for a proper, unambiguous implementation. It requires a lot of efforts from both analysts and implementors, so will depend a lot on your project environment maturity. If you're working on a more agile environment, a close relationship and conversation between parts might reduce the amount of extended documentation. If you're ...


2

There's a great for programmers, called The Clean Coder. It's very motivating, and calls for taking responsibility for what you write.


2

Create an incentive structure that rewards them for solving problems. Then give them the responsibility and opportunity to succeed (or fail).


2

I would start with one-on-one meetings with the team members individually. Highlight concrete examples of where the blame rests with the member and not on the external sources. And in general discuss any areas where there is opportunity for personal growth. Quality issues are a great example. These should lead right back to the contributor who created ...


2

As PM, one of your main tasks is to make sure the communication and information is flowing to the correct people in the correct way. There's no one-size-fits-all solution (that I'm aware of, at least!) but some important points must be taken into account when dealing with all the documents you have to deal with. Documentation must be useful. Every line of ...


2

TL;DR Would a PM normally be assigning fine-grained tasks to individuals in a small team[?] Your question is non-deterministic. Project management is simply a discipline; the scope of the project management role is defined by each organization. Your organization should re-evaluate its management goals and restructure its development process accordingly. ...


2

Always. You said the word "involved". Involved - yes. Dictate - no. One of the most often unseen aspects of a successful Agile development project is that the team is one cohesive team. Not the technical team and not the business team, but the singular Team. Everyone has a stake and everyone has a say. If I was to ask a different question, how would ...


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