Managing a Software Development Team, your thoughts please

[notsoheavyd3]

Daily meetings can be good or bad from my experience. I mean my previous job we did agile for about 9 months before I got laid off. (Yeah, don’t associate one with the other.) Anyway so with a good manager the meetings had some utility. Basically I’d check code in the previous day when I was leaving and whatever QA guy was working on it would pick it up. So the meeting gave me a chance to tell him what I did and what I thought should or shouldn’t work. (Plus he could ask a question or 2 if he wanted. Definitely worked better than e-mail.) Oh, I could also change tasks to help out another coder if he was slowing down. (I should mention the point was to try to break down tasks so it’d take about 1 day to do them so people could swap in and out as needed.) They were 10am and admittedly I didn’t do coding before then. (But come to think of it I never coded before 10 anyway) Oh I should point out for awhile they were totally useless because of an idiot manager who turned them into a status report to him.

Still, Agile has it’s ups and downs. (I mean the second dogma of agile is clearly a dangerous and stupid idea.)

[martu]

@Shagnasty

Daily meetings in IT are just bullshit plan and simple. At my prior company, we started having them at 8am sharp when our workload shot up quickly and we were having trouble getting everything done on time no matter how hard we tried. Ignore the fact that they were a form of punishment because most people didn’t get to work before 8am so we had to call in during our morning commute and listen for 30 minutes to an hour about a bunch of stuff that didn’t have anything to do with our individual work. As we fell more behind because the workload grew and management wouldn’t hire any more people, they added an afternoon meeting as well plus a whole menu of status update worksheets, checklists, and e-mail update requirements. You could choose to do actual work or do a good job at keeping all the tracking metrics up to date and in sync but not both because there wasn’t nearly enough time for that. I chose to do actual work and get in regular hot water for it. Some coworkers didn’t actually do any work but they filled out the metrics and updates diligently about there lack of progress and didn’t get in trouble for it because that is all we were really measured on at that point.

To make a long story short, the entire management team from our project manager to his boss, his boss’s boss, and up a couple of more levels from that either quit suddenly or got fired together depending on who you believe. Our team was able to do actual work with them gone so things improved right away even if we were still overloaded. We had time and freedom to do our job which was the best gift anyone could give us.

It all started with one little daily meeting and things spiraled out of control ruining many careers. Don’t let that happen to you. Good IT work never depends on scheduled banter. Leave the love in’s to the marketing and HR types.

@msmith537

I agree with Shagnasty (I’ve also worked with him on IT project teams). Daily IT meetings are bullshit. In a previous job, I was on a development team of about 30 people (including PMs and whatnot). We used to have a meeting EVERY DAY. We would go around the room, update a 2 week calendar and discuss whether we were “behind”, “on track”, “ahead” and why. The meeting would take like 2 hours. So pretty much you had about 2 hours to develop before lunch and another two hours after until the “afternoon check point”. Of course, I couldn’t do much development during those hours because every function or stored procedure had to undergo a 12 step “code review” where it was evaluated by your peers for functionality, form and aethetics. So most of my time was spent either reviewing or being reviewed.

Basically it’s like 5:00 before I could even sit and do any work.

By the way we also used to have to do a “team cheer” - some combination of stomping, snapping, clapping, hooting and hollaring or whatever the team came up with.
I like to do about a once a week meeting as a PM, just to keep people abreast of major developments, discuss any issues or whatever and just make my presence felt. Then you guys are free to go back to the nerdery and do whatever it is you do.
As a cautionary tale, here is what you DON’T do as a project manager (or in this case, more of a program director). I work for a startup supporting the customized code in two projects for my director’s client. When I started with the company, I had a team of 3 analysts. 2 of whom build the several thousand lines of code across several hundred stored procedures in a dozen interconnected databases that made up the two projects I was running. Now it seemed to me that just the day to day maintenance and bug fixing of these onging projects seemed to occupy my entire staff. Four months ago, I had come up with a pretty reasonable, but aggressive project plan to meet the laundry list of requests my boss had promised our client. The biggest request was to merge these two projects into a single project. Something no one anywhere in the company has ever done (so why not give it to the new guy you hired). Unfortunately, this plan required the continued use of my preexisting team. And even then, I thought it might be a bit tight.

Our client then signed on for three additional projects so my boss decided that his “new” deployments were more important and required the use of all of my staff. Good news, I am starting to get them back now a week before the deadline.

My job now, as project manager, is to perform all the roles of a project manager - keeping our client happy, scoping out the project, writing documentation, training and testing plans, so on and so forth - plus now I am also my own development team doing the job of three people.

Those meetings as you describe are not the daily scrum meeting they are something else. The scrum meeting is quick to the extent the Agile evangelists suggest having it standing up to make sure everyone gets to the point quickly. A strong hand leading the meeting is all that’s required plus a learning curve for everyone to get to know what the meeting is for.

[martu]

@notsoheavyd3

Daily meetings can be good or bad from my experience. I mean my previous job we did agile for about 9 months before I got laid off. (Yeah, don’t associate one with the other.) Anyway so with a good manager the meetings had some utility. Basically I’d check code in the previous day when I was leaving and whatever QA guy was working on it would pick it up. So the meeting gave me a chance to tell him what I did and what I thought should or shouldn’t work. (Plus he could ask a question or 2 if he wanted. Definitely worked better than e-mail.) Oh, I could also change tasks to help out another coder if he was slowing down. (I should mention the point was to try to break down tasks so it’d take about 1 day to do them so people could swap in and out as needed.) They were 10am and admittedly I didn’t do coding before then. (But come to think of it I never coded before 10 anyway) Oh I should point out for awhile they were totally useless because of an idiot manager who turned them into a status report to him.

Still, Agile has it’s ups and downs. (I mean the second dogma of agile is clearly a dangerous and stupid idea.)

Yep agree with this it has been good for us no doubt, I am doing mid year reviews now and all the developers, including some old 50 years old plus hands are on board with it, but we are juts doing the minimum to count as agile. I doubt anything other than a software house could follow all the ‘rules’

[robert_columbia]

I’m a developer.

A big thing for developers is allowing them to pick their own tools within reason. If one employee wants a 4 monitor setup, and is willing to use their own monitors and extra video cards, let them. If they want to use their own IDE or debugging tools, let them (of course, you don’t have to let them expense it, they can buy their own copy to keep and use it at work). Let them bring in their own keyboard and mouse (or trackball, or other pointing device).

Acknowledge that software development is fabulously nonlinear in terms of productivity and throughput (Brooks)*. Doubling the size of your dev team does not double productivity. Making developers work 12 hour days instead of 8 hour days does not increase productivity by 50%.

• If you don’t know who Brooks is then you have no business managing developers.

[robert_columbia]

And also, please do not act so as to make your developers suggest that you change your name to “R. U. Dunyet”.

Read your email. Don’t ask developers for pithy oral summaries of that complex bug report that they sent.

Don’t give out oral requirements. Oral, undocumented requirements bite you later:

(based on reality)

Manager: “Why did you add a button that deletes all documents that are at least 6 months old or are marked deprecated?”
Dev: “You told me to.”
Manager: “When did I do that?”
Dev: “I can’t really remember, I think it was sometime last fall.”
Manager: “Change it so that it deletes all documents.”

[martu]

@LouiseE

Just a single opinion piece, but I like this one quite a bit. It really hits the nail on the head:

http://www.computerworld.com/s/article/9137708/Opinion_The_unspoken_truth_about_managing_geeks

Interesting thank you.

[martu]

@robert_columbia

I’m a developer.

A big thing for developers is allowing them to pick their own tools within reason. If one employee wants a 4 monitor setup, and is willing to use their own monitors and extra video cards, let them. If they want to use their own IDE or debugging tools, let them (of course, you don’t have to let them expense it, they can buy their own copy to keep and use it at work). Let them bring in their own keyboard and mouse (or trackball, or other pointing device).

Acknowledge that software development is fabulously nonlinear in terms of productivity and throughput (Brooks)*. Doubling the size of your dev team does not double productivity. Making developers work 12 hour days instead of 8 hour days does not increase productivity by 50%.

• If you don’t know who Brooks is then you have no business managing developers.

@robert_columbia

And also, please do not act so as to make your developers suggest that you change your name to “R. U. Dunyet”.

Read your email. Don’t ask developers for pithy oral summaries of that complex bug report that they sent.

Don’t give out oral requirements. Oral, undocumented requirements bite you later:

(based on reality)

Manager: “Why did you add a button that deletes all documents that are at least 6 months old or are marked deprecated?”
Dev: “You told me to.”
Manager: “When did I do that?”
Dev: “I can’t really remember, I think it was sometime last fall.”
Manager: “Change it so that it deletes all documents.”

Thanks but as I have spent the vast majority of my career as a developer I know all this.

So no one has ideas on keeping up with the latest processes and practices?

[jonesj2205]

@martu

So no one has ideas on keeping up with the latest processes and practices?

I haven’t managed developers, but I have managed other technical (and non-technical) types and my advise would be to not spend any time on keeping up with the latest process dogma.
If you want to keep an eye on the current fad for ideas that might work for your team, great. But no system works for every situation or every group of individuals, not the last one, not this one and not the next one. And the more a manager focuses on implementing an ideal the more pointy is hair gets.
I don’t want to imply I think you’ve gone overboard, unlike some of the other posters I don’t think a 15-minute meeting in the morning is necessarily bad, as long as it really is the communication for status/issues/etc.

[martu]

@jonesj2205

I haven’t managed developers, but I have managed other technical (and non-technical) types and my advise would be to not spend any time on keeping up with the latest process dogma.
If you want to keep an eye on the current fad for ideas that might work for your team, great. But no system works for every situation or every group of individuals, not the last one, not this one and not the next one. And the more a manager focuses on implementing an ideal the more pointy is hair gets.
I don’t want to imply I think you’ve gone overboard, unlike some of the other posters I don’t think a 15-minute meeting in the morning is necessarily bad, as long as it really is the communication for status/issues/etc.

Thanks for the input.