Managing a Software Development Team, your thoughts please

In My Humble Opinion
1

I run a small software development team at a medium sized financial institution and we are in a state of flux at the moment due to a few people leaving and as such my role has expanded to include full responsibility for development practices.

My question for anyone either

[ul]
[li]Running your own developer team(s)[/li][li]Being managed as a member of a team[/li][/ul]

Is how do you handle all the management tasks required so that the programmers can get on with their job, writing code?

Over the last year or so we have moved into an Agile\Lean methodology, our rough process is as follows:

[ol]
[li]Daily meetings at 9am to discuss what we are doing, no longer than 15 minutes[/li][li]Friday meeting scheduled for an hour to discuss in detail items we were not able to cover in the daily meeting. Often this turns in to a 15 minute meeting[/li][li]Once a month a subset of developers meet with a DBA to discuss processes and practices. Here we talk about new versions of software tools, coding standards, new technology etc[/li][/ol]

Anyone do anything significantly different? Anyone read a good book or article about this sort of thing?

2

I’m in infrastructure, not development, but I’ve found Michael Lopp’s blog and book to be invaluable for insights on the soft-skills side. For a less smartassed approach, it’s also worth checking out Becoming a Technical Leader by Gerald Weinberg.

3

Even with a handful of people those 15 minute meetings can be wasting a man day. They are going to stretch out as people come and go, and have to switch gears. If the meeting is only 15 minutes there wasn’t a need for one in the first place. You do have phones, email, IM, stuff like that right?

4

Thanks that blog looks interesting.

5

It’s standard Scrum practice as far as I know, from here It's Not Just Standing Up: Patterns for Daily Standup Meetings the aims are:

I’m confident it has made us work together better, we often have single developers on tasks which can lead to isolation, whether it’s worth the 15 minutes a day I couldn’t say for sure.

6

That was my first thought, too.

The problem is that it’s very typical for coders to work best when they have long periods of uninterrupted time to get into their work and write a lot of code. Promoting this kind of concentration results in high-quality code being written in a timely manner.

When you insert something like daily meetings, even if they’re short, it inevitably breaks up the day. You said they’re at 9am every day; I guarantee no coding gets done before that meeting is over, regardless of what time your coders come in. Why would you start on something at 8am when you get in to work when you know damn well you’re going to be interrupted in less than an hour? You don’t. Instead, you screw around, read your email, drink coffee, and shoot the shit with your coworkers until after the meeting.

And honestly, what is so important that everyone needs daily updates on what every person on the team is doing? Sure, you want to be in the loop when it comes to the project as a whole, but is it really integral that I know that Jane, who has been working on a bug that has absolutely nothing to do with what I do, has come a bit closer to a solution? Not really. Once a week or so, sure, let’s get together and talk about what everyone’s doing. But other than that, if I need to know the status of someone else’s work, I’d much rather pick up the phone or shoot them an email or walk over to their office than have to spend time every day in a meeting.

7

The bolded part is not true but I do share some of these concerns, what do you think of Fowler’s justification for the meetings posted above?

8

Yeah, I’m on the functional design side but the less meetings the better. My best bosses knew what people’s duties were and were superb at keeping track of what we were doing by using every possible communication tool within reach: dropping by with a quick “got a meeting with the bosses in half an hour, anything I should know about?”, a “how’s your stuff coming along? You’re writing the docs for next week’s meeting, right?” at the water cooler, and email when we were too far for those casual approaches. Even in an almost-all-American team, meetings drifted further and further away from the formal, invites-sent-ahead stuff and into “let’s grab coffee together and talk about it” ground.

In those teams where bosses were less good at the casual-looking approach, one or two weekly meetings to keep the boss appraised of what was going on were enough. We would normally schedule them either right after lunch (if they could get long or if held on Fridays) or right before.

9

Granulizing the process is fine, but ithe optimal granule size is going to vary in every environment. If your meetings are only 15 minutes long than there can’t be much content in them. The secondary advantage of team building is great, especially when there are personnel changes, but if you need daily meetings to maintain that, it’s not working.

Now I’m just a simple country programmer with almost 40 years experience completing software development projects on time and on budget, so take my advice with a grain of salt, but IMHO, every software development project needs to be broken down into steps whose time period is based on the individual step itself, and developers need that time period with minimal interference to do their best at hitting that deadline. Once a week meetings that have no specific agenda are sufficient to maintain teamwork and deal with serious roadblocks. There may be any number of impromptu meetings of interested or necessary parties to brainstorm, and finding ways to facilitate that on demand is more important than conducting that on a scheduled basis.

YMMV, but I’ll ask you if it’s worth 1 man week per week conducting daily 15 minute meetings.

10

Manage a team of 8 developers here. We moved to the agile methodology (we’re so agile that we have to finish coding before we get requirements. Don’t get me started on that.) about a year ago.

Early on in the process the scrums are not useful and seem like a waste of time but once you really get into the work they become useful as it is easier to manage workload when you know exactly where everyone is on a daily basis. It also means you don’t need to manage them throughout the day so you can just get everything out in the morning and then leave them alone.

As far as your actual question… Get the management tasks done however you can. I’m not sure how your job works but I am expected to get just as much coding done as a non-managing developer so I get the management tasks done whenever I get a chance. Sometimes things are later than they should be (just finished writing expectations for the year for my team… 80 days late) but there’s really nothing that can be done about that. Upper management knows this.

11

Really? Assuming that people come in around 8, you think that a lot of good, quality coding gets done in the 30-60 minute time frame before the interruption? I guess we just have to disagree.

I tend to work in 2-4 hour (or more) blocks of time, and I’ve found that common among developers. Give me 4 hours of uninterrupted time and I can get an immense amount of work done, whereas an afternoon punctuated by even a couple 15+ minute interruptions makes me feel like I get nothing done.

Hell, my current workload is workerbee on one (very important) project, Project Manager/coder on another big project, and 80% coding/20% managing on a small third project. I get fookin’ nothing done lately because it’s constantly talking to clients and going to meetings.

Well, let’s see:

Share commitment : I guess I don’t buy that publicly committing to everyone really does anything. Seems kind of child-like, actually. Developers definitely need to know what they’re expected to do every day, but that’s a matter of communication between manager and developer.

Communicate status : Makes sense, but I don’t think it’s necessary to do daily unless there’s some sort of bad thing going on. If the group is way off track, or if there’s a really pressing issue, yeah, communicating status on a daily (or even more frequent) time basis makes sense. Otherwise, every week is fine.

Identify obstacles : Once again, makes sense, but not every day, nor with the entire team. I would rather have an ad-hoc meeting with the relevant people at the time the obstacle is identified than to have to do it with everyone once a day.

Set direction and focus: I sound like a broken record, but again, not necessary every day. If a developer is having trouble with direction/focus, I think one-on-one meetings with their manager does more to help than daily reminders.

Build a team : Blech. Teams either work or they don’t; I’ve never seen a “team building” exercise work better than the way a team naturally emerges from months of working together.

The one thing that every good manager I’ve had has done is to only set up meetings when they benefit everyone at that meeting. Meetings shouldn’t be solely for the manager - that’s the sign of a lazy manager IMO. If the manager needs a status update from everyone on the team, that manager should gather up those statuses himself, either in-person or email or whatever. He shouldn’t make everyone sit around in a conference room listening to everyone else’s status. And the same goes for development issues. Occasionally there’s an obstacle or risk that involves everyone on the team; it’s far more likely that only a handful of people are necessary.

12

My team does the daily meetings, but we do them 10 minutes after start time. Enough time to put down your stuff, review things if you need to, grab a drink, whatever. Usually they end up being less than 5 minutes (it’s a small team) but I think they’re helpful and I think it is a good way of holding people accountable to what is going on. Plus, if something doesn’t move for awhile, people start asking more detailed questions about why, and often roadblocks get resolved. Honestly, I don’t know how we’d function without them. It’s how I always know what is going on and what to expect from the day. For what it’s worth, they’re so well-accepted that we have them even if management isn’t present.

However, we don’t do a weekly meeting. The daily meetings are enough. We just all can call a meeting if there needs to be one. Sometimes these are weeks apart, sometimes it’s more than one in a day, it all depends on what’s going on. Estimation meetings happen when they need to and scheduled appropriately, or we’ll call an impromptu “meeting in 5 minutes to discuss <some big bad defect>”. Review meetings, to me, are not necessary with the daily meetings going on. YMMV.

Now, we have a small team (3 devs, 2 QA) and so we’re all pretty involved with everything. I’m in QA, and while I don’t always need to be involved in the dev discussion (we’ll wander off if we’re not needed), I’ve often picked up on a lot of stuff about a defect fix that helps me write better test cases, or that stops me from needing to find a specific developer to get something moving. I wouldn’t want to sit through what, say, 20 developers are all working on every day. But if you can split into small groups who are working on the same area, I say go for it.

Note: We use a scrum/kanban board method.

13

I’m an IT PM and I agree with all of this.
I don’t code, so I see my job as making sure the coders have everything they need and then staying out of the way.

It’s my responsibility to build a timeline of all tasks and make sure everyone understands what they are responsible for. Update me once a week and as long as we’re on target I’m happy.

I pull my teams together no more than once a week unless we have a critical issue that has to be dealt with immediately. We discuss any jeopardies, task status, and the team gets a chance to bring up any new issues. That’s one meeting a week and I try to be done in 30 minutes, and I never go over an hour.

This is critical. I need the team to know that if an issue arises I need to know about it ASAP so I can get it fixed. I may talk to each person on the team individually once every 2 weeks for 15 minutes but there’s no reason to bring together the whole team for the majority of these issues.

But like I said, I see my job as making sure the team including the requirements analysts, designers, coders, testers etc. don’t have to worry about anything but doing their job. If something comes up - tell me and I’ll take care of it - then get the hell back to work :smiley:

14

Thanks all interesting discussion and very helpful. Rather than addressing each point directly I’ll make a few comments below.

[ul]
[li]Though the meetings are scheduled to last 15 minutes sometimes they are over in 5. I fully agree with fluiddruid that there are times when they seem a waste of time but most of the time they produce solutions or at least advice.[/li][li]Coding is done before the meetings, I know this for a fact because I’m still coding myself and manage to get a bit done before the meeting. Yes being in the coding ‘zone’ for 4 hours is better but not all tasks require 4 hours. I may move it forward to when ‘everyone turns up’ though as this is a concern, thanks.[/li][li]I have to agree on the longer weekly meeting being superfluous, this has been my thought for a while now. I’ll probably only schedule this for when we need it.[/li][li]I think you may have misunderstood what the daily meetings are for - ‘Meetings shouldn’t be solely for the manager’ and they aren’t, they are for all of us. I know exactly what everyone is doing without the meeting. Without the meeting though I don’t think the developers would know exactly what everyone is up to. Further plenty of times issues are raised in the meeting and someone not involved in the project has provided a solution, without the meeting I’m not sure this would happen. Of it it did as frequently.[/li][/ul]

No one has touched on how you keep up your processes and practices up to date and as efficient as possible?

15

How do you hold your meetings? In person? Phone? Netmeeting?

I have always been curious about asynchronous meetings, but have not had any experience with them. In my opinion, the best meetings have everybody in one room and everybody has a laptop with some software capable of sharing desktops. The next best is everybody at their desks with the sharing software (something like NetMeeting).

16

In a room with at least one maybe two people via a Tandberg link.

17

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

18

(missed the edit window)

At my company, different sub groups have weekly in-person meetings, and we also individually email a weekly status report to our boss and the rest of the group. The reports are at most half a page, and the format is very flexible. At a minimum this will include a list of my current projects, what I’ve released, and what I expect to work on next. If I’ve made significant progress on a large issue, or encountered significant roadblocks, I will briefly describe them. I don’t usually include lists of bugs I’ve worked on, though I could. On rare occasions the boss will ask for more detail.

For daily communication outside meetings, we have multiple irc channels both company-wide and intradepartmental. We may seem to be just sitting at our desks quietly typing away and not talking, but we discuss coding, debugging, and deployment issues all day long over irc.

19

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.

20

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.