Software development team meetings

Question

Hi All,

This is not a programming question, but its suitable to all programmers and developers working in a team.

I am a software developer, in a team of 4 developers and 1 DBA. Our team leader just came up with a idea about team meetings. In past, we used to have a weekly meeting to discuss everyone's weekly performance and any problems during the week. Now our team leader is breaking the meeting into 2, first meeting of the week would be a standing SCRUM kind of meeting where everyone will just give a overview of whole week (SCRUM says that this kind of meeting should be a daily task). Second meeting during the week would be 1 hr meeting where everyone of us will have 15 min to demonstrate the work we did during the week (sounds wierd).

My question is, is it a good way of checking the progress of team by asking every member to demonstrate the work done? Does anyone else has faced such a problem?? What should be the better way of team management rather than creating bounderies like this?? I am asking this question because I am feeling like I am loosing my morale; because after so much hard work I still have to demonstrate my work to team leader as a uni student to his professor.

Thanks for your help.

Answer 1

One of the primary reasons for demonstrating work done is so knowledge is spread out and everybody knows what's going on. Specifically, if you get hit by a bus tomorrow, it becomes much easier for somebody to step in wherever you were and continue.

Additional benefits are problems can be detected and fixed quickly rather than down the line.

As long as you're not being micromanaged, the team knowing what everybody is working on is a good thing, not a bad thing.

Answer 2

Well there is nothing wrong with code reviews or people helping each other. People are usually not at the same code level.

The only issue I would have is that it seems like a waste of the teams time if the members are discussing what they are doing for the benefit of one person and not the whole team. The project manager ("leader") should take his time doing that with everybody and not waste in meetings.

Its hard to tell what is really going on but it sounds like the manager is trying to make it easier on themselves instead of doing what is right by the team.

A role of any manager is to remove the obstacles out of peoples way to allow them to do what they are good at. Meetings are not work. They are an unfortunate bi-product of the poor ability human beings have at communicating. A necessary thing that should be kept efficient as possible.

Answer 3

Demonstrating your work is part of the Scrum methodology (the Review) and is the best measure of progress. It sounds as though your team has almost made the leap the Scrum. What I would suggest is that you implement 1-2 week Sprints during which you hold a daily standup Scrum meeting. At the end of each 2 week period the team (as a whole) demonstrates what they've built. "What did you build that we can ship to our customers for their benefit?".

I would try to get your manager / team leader to properly engage in the Scrum movement. Best place to start is here, here or here.

Finally, you should also have at least one tester on your team that works with you!

Answer 4

Think of it as an opportunity to show off what you are doing and learning. Don't think of it merely as a lack of trust on the part of your team leader.

I don't think that having some accountability for what you are working on is an onerous burden and it could be helpful. If the team is really focused on improving and helping each other to improve a weekly sounding board seems like a lightweight way of jump starting this process. Eventually, you may want to move on to code reviews as an extension of this.

The last thing you want to do is come across as being the person who doesn't want someone looking at their code. That would say to me that you aren't interested in improving or getting feedback on how you could improve. The best programmers are the ones that know they don't know everything and have lots more to learn; they also look to everyone around them for new ideas and constructive criticism.

Answer 5

It sounds like the demonstration meeting should be more of a code review (or perhaps it already is?). If it's treated like a peer review, then you should just learn to appreciate it. In the long run, it will make you a better developer.

I really don't see a problem with a manager asking to see what's been done since the last meeting. In the end, s/he has decisions to make and data to report that are directly based on your work. Also, if you can't show off your work to your manager, who can you show it off to?

If I've interpreted your situation correctly, you need to change.

Answer 6

Think of the weekly meeting as an opportunity to learn.

Learn about other parts of the system. Learn other people's methodologies for solving problems. Learn how you can improve your problem-solving techniques.

I had the opportunity to participate in these types of meetings, although in a different field and everyone was usually working on individual projects. However, the material presented by others was interesting and informative, and could sometimes apply to things I was working on. But even if I couldn't apply the ideas, it was still far from a waste of time. Of course, for others, the same was true when I presented my work. I have no doubt that this will be the same case in a team meeting where you're all working towards the same goal.

Answer 7

I see it as a symptom of a deeper problem...people aren't talking to each other, stuff isn't getting done and the manager is feeling clueless.

In a healthy team, meeting daily, weekly, bi-weekly, semi-weekly, monthly, quarterly, yearly, semi-anually (even to just stand-up) is unnecessary. People know what's going on and feel comfortable engaging each other to help solve problems. Communication is a natural outgrowth of what's needed to get stuff done, what needs to be done is clear and progress is public. Announcements can be made over the appropriate channels (which almost always means email/rss/twitter/sms/bells) and people are free to work the hours that best suit their optimal output.

As to your ideal response to the request, well, welcome to the corporate world. Smile, nod, attend the meetings and conform to whatever latest lunacy your boss wants to try out. It makes the process go much faster and the systemic interruptions to be much smaller. If you want to score brownie points, make sure to act like the textbooks advising your boss says the top performers will.

Do NOT, under any circumstances, suggest that going for coffee or standing by the water cooler counts as a stand up meeting, although the best managers will realise that those are the best times (and places!) to hold team meetings.

As to the better ways to structure the team meetings, it starts with a shared vision, shared values, engaged team members who genuinely respect and admire each other, clear objectives and clear obstacles. If you take a lot of care in setting up that kind of team in the first place (and, it's devilishly hard to do), the only challenge becomes making sure that they have the right problems in front of them and the right metrics to guide them towards the best solutions. They'll naturally create their own meetings and you, as a manager, just need to make sure to show up occasionally and ask questions.

Answer 8

My cynical answer: teams work or don't work because of the people, not the methodology.

In this case I'd suggest jumping through the requested hoops. If the whole idea is dumb, it will show, and you will just be one of the folks caught by this unfortunate enthusiasm. (I said I was cynical.)

If, on the other hand, the idea is good, it will work out just fine. One of my personal pet peeves is when it's painful but not painful enough to be gotten rid of, but that's just me.

I've been a team lead several times, and it is not an easy job. Sounds like your lead is trying hard to do the right thing. It's hard to say to them "I like your enthusiasm, but this idea sucks IMHO", so go along and try to help them.

Answer 9

The iteration demo spreads the knowledge of the product in the team. A side effect is that it will increase the communication in the team (or between the teams if you're transitioning to Scrum, not SCRUM BTW, it's not an acronym). It may also help QA gets up to speed with what there are going to test.

The demo allows to get feedback from the project stakeholders, and create trust.

Answer 10

It does not sound good. If every developer will have to waste one hour a week "presenting progress", they will for sure use 8 hours before to "prepare" for the presentation. (and lots of hard coded "fluff", just for the show)

So 9 hours a week/developer just to get a false sense of where the project are instead of having REAL project plan and tools to handle this.

Answer 11

If your team can have a development methodology where the 2 meetings are kind of like "book ends" then I could see this working OK in some cases. To elaborate a bit more:

The first meeting is what is held at the start of the week and is intended to set objectives or goals for the week, who has bugs to fix or what features are implemented, etc. This is to jumpstart the week for people and is kind of like a pep rally in a sense. "Go Team!" may be an undercurrent at times.

The other meeting is the flip side as this would be that meeting at the end of the week, to say, "Hey, look what I did!" sort of feeling. If this is done in a respectful way, it could foster some good competition in the developers. The DBA however, may find this useless to sit through though. This would also be where someone could ask questions to the whole team like, "Does it make sense to MVP this?" or "Which patterns are worth using for this feature?" that may come out.

This does make me think of a few questions:

• Who is setting the schedule, the team or the managers?
• How often can priorities be changed?
• Does the team have the ability to communicate in cases where a deadline won't be made?
• How are cases where a lot more time is spent on something than initially thought,e.g. estimates were way way off?
• Do these meetings have clear objectives for everyone?
• Is there expected participation from everyone or is there just a series of someone showing something and noone asking questions about it?
• Do the managers understand the resistance developers may have to these kinds of meetings?

Just some food for thought.

Answer 12

Generally meetings for the purpose of showing what work was done are held because the people in question are dead wood or management requires a weekly/daily(?) status update on progress. But these type of crap meetings should be quick.

The problem occurs when meetings are held for the sake of having meetings and not after some measurable level of progress was made. For example, it is Friday and therefore we have our 1:00 PM weekly meeting vs we just completed the first pass of the such-and-such module.

We have daily 5-10 minute stand-up talks just to have a usual time/place to ask questions/get ideas. We will do full team code reviews on an as-needed basis (after the code in question has gone through at least one peer review with a lead) just so everyone else is familiar with how a problem was solved. These are the meetings where we'll walk through the business reasons, the process, and the code.

The problem is compounded by the fact that management and the client generally want a weekly status update -- after all they're paying for the work. As a lead the only information I provide is if we're moving/stuck and if we'll make/break our dates. Do they really care that some module is 73% done? No, they generally just want to know if it will be done by next Thursday and if it won't be done then what happened and how do we adjust the schedule.