Tag Info

Hot answers tagged

140

I think the problem is the task: "I have been tasked with teaching other teams a new codebase". You have been given the wrong job, or maybe misinterpreted the job you've been given. By presenting at the code level, you invite code level thinking. Start at the system level and present the design and the design choices that were made. Don't allow extended ...


63

"Park them". At the start of the lesson, explain what you are to discuss, and clearly explain what is considered Off Topic. If you are asked a question that is clearly OT, say so and move on. If they come back to it, write the question on a whiteboard (This is critical) for later discussion and move on. At the end of the lesson, when they are on their own ...


46

To get this out of the way ahead: I consider "15mins of slack" before a meeting not enough. When I come to work, I have to read mail and look at what I have done yesterday in order to know what it was, so I can tell the others. Others will need to have had a cup coffee before being able to start thinking straight. Where I worked we usually had at least ...


33

I have an idea... How about moving the meeting to a more sane time? See my answer here on a related question. Why on earth would you have strict working hours for programmers?


32

I would find daily stand up boring and useless if I felt there was little to no value in it. There are a few things that can reduce the utility of a daily standup. The information being shared never pertains or affects me in any way. Absence of team ownership and everyone always working on their own projects. Absence of team communication outside the ...


32

As an alternative to daily scrum, we're thinking about asking developers to provide daily reports with the following conditions: What a terrible idea. Do you think that this can decrease their productivity? Yes. Why? A verbal presentation at a meeting combines writing and n people "reading" the report into one concurrent activity. Talking plus ...


32

Why are the backlog items not inserted and prioritized before sprint kickoff? Wasting developers time is not fun. Let your team leads work with the product owner and project manager a few days beforehand to prioritize stuff. This goes for planning who is on each sprint team too. Why is it taking a day to break things out into tasks? If you have a reasonably ...


30

We had daily standups at my first job. Well, with all the co-ops/interns/temps, it was actually on the long side - usually around 30 minutes. But the idea of a short, timeboxed, daily meeting helped a lot just to know what other people were stuck on - and if it was something I was working on, I could reprioritize my tasks to finish what they needed to ...


29

I had experience participating in a "SCRUM" team with several employers. It appears to me that the managers take out the "daily scrum meeting" as the main point of SCRUM, and set it as the goal, instead of having it for what it is: a mean to achieve more effective development cycle. Very quickly the 15 minutes meetings became 45 minutes meetings, the ...


26

If your meetings are held for the purpose of doing actual work like coding, then you should have laptops in your meetings. Otherwise it is my opinion that there should be no electronic devices of any kind in meetings, including blackberries and such.


25

I find these meetings very valuable. They offer the following benefits—in return of spending just 15 minutes! Keeps everyone on-topic. It's easy to dig into your own problems and forget about what others do, or to repeat work being done by someone else. Daily meetings prevent this from happening. Doesn't allow people to slack. At these meetings you make ...


25

Make estimating easier Break your sprint planning down. Do you need to estimate the individual tasks? I've done sprint planning two ways: Stories are estimated in story points and then tasks are estimated in hours Stories are estimated in story points and tasks simply fall under that with no estimate Of the two, I prefer the second option. I find ...


21

We have our daily scrum at 11.45 AM. This way everybody has arrived, even with unpredictable traffic, ... It doesn't matter at which time of the day you place it for having a "full day" between each daily scrum, as long as you keep it on the same hour. Another positive side effect of placing it at 11.45AM is that meetings don't overrun to e.g. 1h since ...


20

Set expectations correctly and be honest, open and upfront. Make sure your goals are open and transparent. Start off discussions with the high level view as promoted by andy256 (+1) but also make sure that you include your objectives, e.g. "...as we look at this issue, lets make sure we don't focus on x, y and z. Let also make sure that we're not looking ...


19

In my experience, the best way to improve standups is to follow the rules exactly. A lot of agile practices can be bent, but if you're having trouble, a good first step is to return to the prescribed way of doing it: Stick to 15 minutes for the entire meeting. People get bored easily, especially at mandatory, team-wide, daily meetings. Have each person ...


18

Ideally, the scrum master is responsible for facilitating the project activities and to address any sort of impediments faced during that. He/she does not participate in the "yesterday, today, impediments" spiel during the daily stand-up per se, however, is answerable to the team members for any kind of status on the impediments they have reported during ...


17

a) I will find out what the answer to this is from the person responsible for that area of the project and get back to you within the next two days b) This is a good point, thank you for raising it. I have not thought about this aspect but will do and get back to you within the next two days c) What do you actually mean about this as it does not seem to ...


16

The Scrum team is self organized so there can be somebody who is little bit more dominant and other ask him for his ideas about tasks they are working on but that dominance must be under control. What you can do: Motivate others to be independent but collaborative - this can be best achieved if you cooperate with their boss and HR who will set some ...


16

So how do you educate other programmers enough that they stop fixating on trivialities and can meaningfully contribute to the design? First, don't think of their concerns as "trivialities" or "bikeshedding". Those are judgmental words, and they're insulting. Their concerns are valid. They're just not important at the moment. The key to any good ...


14

Many conferences have a period where they accept proposals for talks. How and when this is done depends entirely on the conference. I imagine that getting asked to speak at one involves prior involvement with the conference or being otherwise well-known in the development community relevant to the conference. You can ramp up your involvement by joining open ...


13

Presumably, the reason for this question is because you feel that the team is somehow under-performing because of this dominant person. Perhaps because the rest of the team aren't contributing 100% because, well, what's the point? As a manager, if you are, it's your responsibility to make sure that all of your employees understand what their roles are. ...


13

Some of the problems encountered with daily SCRUM meetings : those which last too long. You don't want any manager guy in those daily because they're the root cause of this kind of problems. See how they'll usually be the ones using a chair (yes, having to stand up for those is to entice people to be fast) having to hear about someone (or 2 or 3 devs) ...


12

This is a fairly common practice, although I wouldn't say supportability is the main benefit. The real benefit for this approach is keeping a rich audit trail. It's also common place to have an extra column containing the username of the user who made the last update. If you're dealing with any kind of financial or sensetive data, I'm sure you've heard of ...


11

I can stand for hours on end. It doesn't make me any more to the point, or have any real significance/impact to a short daily catch-up meeting. But hey, if standing up lets you re-brand something as agile, it must be good! As for whether regular catch-up meeting in general are a good idea... well they help if you other processes are ineffective. If you ...


11

I'd begin by speaking at local user groups. It's fairly easy to get a spot (may be a few months out). Be sure to ask for feedback so you know what you can improve. For example, I spoke at the local user group, and then was asked to speak at the yearly "code camp" (a much larger event, with some serious sponsors).


11

I've done these in the past, but in the morning as opposed to the end of day. It generally took less than five minutes to fill out, so no, I can't see how there would be any decrease in a developer's productivity. The nice thing about doing it in the morning was that it made you think about what you're going to do for the rest of the day. Having said ...


10

Timing is the killer for many. Programmers like to code late, sleep late and come in after the morning rush. Having to be in office at a fixed time - way too early for them. And too late for others who may come in earlier and start working already. Flow is another issue. A programmer in flow with some feature will work until late at night, go home and come ...


9

Make sure that no-one monopolises the meeting. If 4 of the developers get their spiel out of the way in 5 minutes, and the next 10 minutes are spent listening to the team leader detailing all of the amazing, awesome new developments he's made, most of which are neither as amazing nor as awesome as he thinks they are, people will get very bored very quickly. ...


9

My observation is far too often these meetings are for the managers to look and feel like they're actually doing something rather than them being useful for the team and the project. For example, a team is assigned to do series of short bug fixes on different projects. They're really not working as a team but as individuals. However, because ...


8

I think they are very valuable if they are performed correctly. The format that has worked well for me is this.. Each person gives a short answer to the following questions. a) What are you working on? b) What will you get done by the next meeting (tomorrow)? c) Did you accomplish what you said you would get done at the last meeting? d) What obstacles are ...



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