Managing a Software Development Team, your thoughts please

[martu]

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

• Running your own developer team(s)
• Being managed as a member of a team

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:

1. Daily meetings at 9am to discuss what we are doing, no longer than 15 minutes
2. 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
3. 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

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

[black rabbit]

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.

[TriPolar]

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?

[martu]

Originally Posted by black rabbit

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.

Thanks that blog looks interesting.

[martu]

Originally Posted by TriPolar

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?

It's standard Scrum practice as far as I know, from here http://www.martinfowler.com/articles...tandingUp.html the aims are:

Originally Posted by Martin Fowler

Summarizing several papers and references ([Anderson, 2002], [Beedle et al., 2000], [Cochango, 2006], [OrgPatternsStandUp], [Rising, 2002], [Rising and Janoff, 2002], [Wells, 1999]) daily stand-ups should achieve the following goals:

• share commitment
• communicate daily status, progress, and plans to the team and any observers
• identify obstacles so that the team can take steps to remove them
• set direction and focus
• build a team

Share commitment
Making daily commitments to each other as a team is the most important goal of daily stand-ups. Sharing commitment is more important than sharing progress or status. This is not to say that an observer will not have a sense of progress and status from the stand-up, but this is secondary to team members publicly committing to each other, and identifying obstacles that prevent them from meeting their commitments.

Communicate status

The focus of the meetings is on the technical progress in the architecture and the work plan. [OrgPatternsStandUp]

Communicating status is not much of a differentiator for stand-ups against any other kind of status meeting. The mechanism that stand-ups use for communicating the status, that is the team updates each other instead of a manager, is a differentiator. Updating status every day also ensures that the team reflects on what they're doing at least daily.

Identify obstacles

When one team member shares an obstacle in the Scrum meeting, the entire team’s resources come together to bear on that problem. Because the team is working together toward a shared goal, every team member must cooperate to reach that goal. The entire team immediately owns any one individual’s problems. [Rising and Janoff, 2000]

Raising and removing obstacles earlier allows the team to maintain its momentum. The stand-up itself is not intended to remove any particular obstacle but rather to provide a forum for people to identify obstacles so that other team members have the opportunity to help.

Set direction and focus

During the daily meetings, the Scrum master would call attention to backlog item priority. This was especially helpful for new team members, who might have gone off in another direction. [Rising and Janoff, 2000]

We want everyone to be moving in the same direction. The stand-up is used to continually remind the team what that direction is.

Build a team
More so than artificial “team-building” exercises, effective teams are built by regularly communicating, working, and helping each other. This is also strongly tied with team members helping each other with shared obstacles.

The team is aware of any particular member's problems because they hear about it every day (until the problem is solved). This environment encourages people to raise problems as a history develops of other people helping when problems are raised.

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.

[Athena]

Originally Posted by TriPolar

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?

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.

[martu]

Originally Posted by Athena

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.

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?

[Nava]

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.

[TriPolar]

Originally Posted by martu

It's standard Scrum practice as far as I know, from here http://www.martinfowler.com/articles...tandingUp.html 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.

Originally Posted by martu

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?

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.

[geneb]

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.

[Athena]

Originally Posted by martu

The bolded part is not true

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.

Originally Posted by martu

but I do share some of these concerns, what do you think of Fowler's justification for the meetings posted above?

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.

[fluiddruid]

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.

[zoid]

Originally Posted by TriPolar

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.

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.

Originally Posted by TriPolar

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.

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.

Originally Posted by TriPolar

Once a week meetings that have no specific agenda are sufficient to maintain teamwork and deal with serious roadblocks.

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.

Originally Posted by TriPolar

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.

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

[martu]

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

• 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.
• 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.
• 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.
• 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.

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

[ethelbert]

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).

[martu]

Originally Posted by ethelbert

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).

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

[cuberdon]

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/artic...managing_geeks

[cuberdon]

(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.

[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.

[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]

Originally Posted by 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.

Originally Posted by 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]

Originally Posted by 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]

Originally Posted by 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/artic...managing_geeks

Interesting thank you.

[martu]

Originally Posted by 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.

Originally Posted by 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]

Originally Posted by 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]

Originally Posted by 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.