17

To have a better understanding of the project status and a better relationship with the developers who report to me, I want to introduce daily standup meeting ( as per suggested) to the developers in my office, but the problem is that this is never a part of our culture, and I afraid that introducing this, they would think that the management wants to "spy on them".

Currently, how do we work is as thus:

  1. Define Road Map for my product under development using Redmine. And I define the tasks that should go into each Road Map. The date for a Road Map is fixed ( Usually on a monthly basis) and usually, One sprint per Road Map.
  2. After that, I assign the tasks to the developers and ask them to provide estimation for each task. After looking at their estimation, I will either take out or put in more tasks for a particular sprint so that they don't over-commit and can't deliver in the end.
  3. I ask them to fill in the amount of time worked on a specific task everyday and the percentage of the progress so that I can keep track of the progress.
  4. I would review their progresses at the beginning of every week to see whether I need to move some tasks to the next sprint.

Clearly, as you can see from my question here, the above process isn't working fine. So I am thinking about introducing daily standup meeting, but I fear the developers would take it to mean that I am spying on them, and hence some bad blood may run.

Question:

How to introduce daily standup meeting in this case?

Improve this question
13
  • 3
    @jmort253, I've updated the question as per requested.
    – Graviton
    Dec 14, 2012 at 6:27
  • 3
    The daily stand-up is only part of larger process. It allows the team to become aware of problems as they arise and before the problems become show-stoppers. However, if the process (roadmap, tasks, progress estimation, etc) is totally dysfunctional, the stand-up will simply serve to make that clear to everyone. In other words, if the process itself needs fixing, the standup alone can't do that.
    – Angelo
    Dec 14, 2012 at 13:56
  • 3
    How do you measure the "percentage of progress" on a task? In software development, rarely is there a way to correlate the time taken to reach the current state to the time required to complete the task. I once had a project manager who tried to operate this way, and didn't understand that the final 20% of the work (by feature count, bug fix count, etc.) could take 50% of the time to complete - or that an unexpected bump in the road could set one back several days or more.
    – alroc
    Dec 14, 2012 at 14:38
  • 3
    Hey Graviton, normally we discourage cross-posting, but in this case, we really feel like your question fits both Project Management SE as well as Workplace SE. Feel free to post this on PMSE as well and make any edits that might be needed to address project managers.
    – jmort253
    Dec 14, 2012 at 21:01
  • 3
    Couldn't you just say, 'If you have any actionable items/road blocks/problems - come speak to me' and save everyone a lot of time? If you have six team members, five of them are going to be awfully bored while the six tells you they are 'blocked by X'. Rarely is that information relevant to the group, IMHO, and seems like it would be more effective to handle it on a 'as needed' basis, with the people who are impacted.
    – user3497
    Dec 16, 2012 at 16:38

4 Answers 4

Reset to default
10

One tip which might make the team feel that the standup is for their benefit, not just yours:

Traditionally, in the daily standup, everyone says:

  • What they did yesterday
  • What they are planning to do today
  • Whether there are any impediments or stumbling blocks

If you put the most emphasis on the third of those items, it might make it clearer that the daily standup is about keeping things running smoothly, not just about keeping the manager informed. I can't count how many times someone has said, in a standup, that they were having a problem in such-and-such bit of code, and someone else has instantly said "oh yeah, I've had that problem before, I can help you out". Particularly with larger teams, it really helps make the connection between people working on a particular area and other people who are familiar with it from past work.

Beyond that, as Darhazer said, it's a common mistake to turn the daily standup to status report to the manager, not to the team. If people are facing you and talking to you at the standup, nudge them with a gentle reminder that they are here to talk to their teammates, not to you.

And lastly, make sure that you also use the standup to tell them what you have achieved yesterday and plan to achieve today! If those things are connected to resolving the impediments and stumbling blocks that developers reported in previous standups, so much the better!!

Improve this answer
4
  • 1
    RE: Impediments/stumbling blocks, it also helps call out particular tasks that are blocking others' tasks, so maybe that particular developer doesn't realize he's blocking 3 people from continuing with their work until he finishes that class he's been having trouble with, but the other devs don't understand he's having trouble with it, just getting annoyed it's not yet done. Basically 3 devs "task 123, 124, 125 is waiting on 122 to get finished. John how's that looking?" John: "I'm having trouble getting x to work." Other devs "lets get together after this...
    – Randy E
    Dec 16, 2012 at 17:56
  • 1
    Great point Randy, I was totally thinking of external impediments but of course there can be ones internal to the team also, and a good standup should help in getting them moving
    – Carson63000
    Dec 17, 2012 at 3:22
  • +1 - " not just about keeping the manager informed" Management reporting should be a by-product of the data included in the tools to make it easier for someone to get things done.
    – user8365
    Dec 18, 2012 at 14:38
  • @Randy — Why would a stand-up meeting be needed for that? When a worker Alice needs something that is being done by a worker Bob, naturally Alice goes to Bob and asks about the thing. Then asking "Can I help you with this thing?" is a matter of team spirit, and has to be encouraged by the employer.
    – Nicolas Barbulesco
    Jun 28, 2015 at 15:28
9

When you introduce a new practice, you have to start with the why. Why daily standup? What the developer has to say on this. Why he have to say it. One common mistake is to talk at the daily standup the same things you can already see in Redmine. Or to turn the daily standup to status report to the manager, not to the team. The daily standup have to be between team members and should answer the question why this task is not going the way I was thinking it will go yesterday. It should not be finished/not finished report, unless someone needs to know if this is finished or not (but usually a tool like redmine can tell this). And you have to be prepared - and explain this to the team - that they will fail to use the standup meeting properly and you have to coach them.

Improve this answer
3

IMHO, without embracing the spirit of Agile (for example, in Agile world you do not assign the tasks to the developers) this wouldn't work; it will become аnother status meeting (and participants will have to stand instead of sitting for the sake of ritual).

Improve this answer
4
  • The purpose of standing is to keep the meetings brief; assignemnt of tasks by the OP is done elsewhere.
    – user8365
    Dec 18, 2012 at 14:51
  • 3
    @JeffO: thanks, I already know this secret. By the way, there is more than one way to keep mettings short. assignemnt of tasks by the OP is done elsewhere in SCRUM environment it's done by the team, not OP
    – Steve V
    Dec 18, 2012 at 21:22
  • 2
    I've had this issue with a group that tried to do this. These daily standups required 10 or so people to get in a room, and they often lasted for 30-60 minutes. It ended up such a waste of time for most of us that we finally got our managers to nix it in favor of something else.
    – Shauna
    Dec 19, 2012 at 19:24
  • 2
    @Shauna : that's exactly what I was talking about - people are trying to use rituals from Scrum without accepting core values of the Agile methodology. It's funny to see how my reply has been voted up and down quite a few times ;)
    – Steve V
    Dec 19, 2012 at 20:20
2

In the context of this question (and your previous one) daily stand-up meetings and sprints can form part of the Scrum approach to Agile software development.

We were starting to look at Agile, then ended up hiring an experienced software engineer who guided us through the initial 18 months of getting a full-blown Scrum system set up. Now, no-one would go back, but this was a huge change in our culture and was hugely challenging.

Standups formed a part of this cultural shift from the outset; in fact they were the simplest part of Scrum to get into play. This video from Atlassian summed it up. They used to have a whole series on the website, which were very good.

My experience is that, as a line manager, its also very tough. "Letting go" and learning to coach, guide and trust your team is very hard.

While "stand-ups" are important, the key is the retrospective meetings, and asking the team to honestly take ownership of their own short comings and address them.

So - to sum up, we adopted stand-ups as part of a drive towards a formal scrum process. This was led from (some of) the team, and as a (non-developer) manager I had to educate myself very rapidly on the implications. We progressed to scrum master certification for the majority of the team.

Compared to where we were, I can only describe the process as transformational. We're a more productive, happier team as a result.

Improve this answer
1
  • Who, "we"? You talk like Louis the Eleventh.
    – Nicolas Barbulesco
    Jun 28, 2015 at 15:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .