How to Manage People in 15 Minutes a Day
blogs.harvardbusiness.org
blogs.harvardbusiness.org
My advice would be to make communication asynchronous.
Use something like Yammer for status updates to make sure everyone knows what everyone else is up to.
Write good commit messages for each checkin. Make sure it's understood that everyone on the team is expected to read these checkin comments.
Write release notes for each feature. Stuff these notes in a wiki. The audience for these release notes are the non-technical people in your company, too. Sales, marketing, production, design, etc.
Have adhoc face-to-face time. At FogCreek, the team eats lunch together. http://www.joelonsoftware.com/items/2008/12/29.html
When I used to work at a game development company here in Vancouver, the entire team of programmers used to get up at 3PM and walk to the coffee shop together down the block to grab a coffee. This is when we would bounce ideas off of one another, talk about what we were stuck on, and let each other know what we were working on.
Management tried to formalize this into 10AM Scrum-style standup meetings. That didn't work at all.
You're right that forced, formal scrums are a waste of time. The problem is, however, that spending time with your mates looks like a waste of time to a lot of people. You'd think it'd be an obviously good thing to do, right?
By all means, take 15-30 minutes each day and grab coffee. Go for a walk as a team. Relax and chat about what work-related things are on your mind.
Daily stand-ups are an attempt to get people doing this. But it's like pulling teeth. Unless you've actually been on a high-communicating team you just don't see the value. Even then for some folks it rarely occurs to them that by "wasting time" everyday they might be doubling or tripling their productivity. Then the scrums become bland and formal, nobody ever has any obstacles, the PM turns it into a status meeting, and you're truly wasting your time.
A lot of my friends' companies have drunk the corporate Kool-aid and adopted Scrum (e.g. sending project managers to Scrum Master training, forming Scrum teams out of organizational chaos). Scrum isn't that bad - it's not perfect - there are aspects I dislike. It's not as bad as teeth pulling, somewhere between gum cleaning and flossing. Daily burndown updates are always painful. It's better than nothing. But being forced to throw out a number for a task is sometimes lunacy. The whole point of Scrum in my opinion is to micro-manage programmers and hold them accountable.
It's a simple thing, but people keep screwing it up. Say you have a two-week sprint. What can you do in two weeks? Make a list. Then go do that.
You don't have to break your list up into dozens of tiny tasks -- that's crazy. But that's exactly what some PMs and CSMs want the teams to do. Some consultants even require that everything be broken up into tasks of less than 4 hours.
If you do it that way, yes, it's micromangement hell. But the way it's supposed to work is just you describing and committing to doing some work in a certain amount of time, whether that's one huge story or a dozen little stories.
I encourage people doing it the first time to break their work up into little pieces, if it helps them figure out what they need to do, but even then I actively discourage the CSM from tracking at the micro-task level. There's simply no benefit.
Agile is a very simple philosophy with common sense practices. If you try hard enough, however, you can make your life miserable with it. Unfortunately, people try their hardest to remake it into some kind of micro-management, data-centric, ritual-based death grind. It's not supposed to be like that. Stand ups, like I said, can be coffee at 3 everyday with the team. Stories can be big. etc.
There is the aspect of holding programmers accountable, no doubt. But there's also the aspect of giving them the freedom to break up their work and execute it in any fashion they see fit. Companies focus on the first part and then forget about the second.
We did do fairly large stories (e.g. complete UI panels) but we go slammed when the requirements changed and we had to go back and rework what was 'done' in Sprint 4 during part of Sprint 6. I always joked that I was going to give a well done steak to my scrum master at project's end (e.g. a raw piece of meat).
I fear that my first gulp of Scrum has left a bad taste but it was an intense experience. We are much better now - very little requirements churn and we have a UXD group. We don't have Mighty Morphin' Wireframes now. Scrums are now managed according to the scrum master, which means if the SM is relaxed, hands-off (like ours is) we don't get pressured to update the burn down every day.
Burn downs. During the first project there was intense pressure to meet the burn down expectations so people would work overtime and that skewed their accuracy and added stress. What ended up happening in practice was that some tasks took hours from other tasks.
Sorry to hear about the bad taste it left. Sometimes it isn't the way you work but just the initial mix of folks that make a big difference. Some people are okay with chaos and changing requirements (ie, they know how to nail down what they can and what they can't and do the work expecting change) and some folks aren't.
Remember that agile teams aren't just a big list of stuff where you do a little each sprint. That's something you could train monkeys to do. You're supposed to be managing the big picture, working risky items first, designing for change, etc -- all of the good stuff that keeps you out of those "done" screw-ups.
EDIT: Burn-down mania: make your sprints small (a week or two). If you end up working OT, it's simple: don't buy so many stories the next time. Some guys will say you should never work OT, but I find that impractical in the real world. Better to have smaller sprints. If something hurts, stop doing it. I also find PMs pressuring teams to buy more stories than they can do. The PM shouldn't be the CSM because of this conflict of interest. The team should be in charge of what it can do or not inside a sprint.
Thanks for the story.
Go away and leave me alone so I can solve the problem?
We both laughed, but he got the message loud and clear.
1. Walking back to your office after a meeting? Praise in public, criticize in private. Don't correct someone in a hallway.
2. Constantly spot dead time. Relax and reflect on your own shortcomings and goals.
3. Don't show up without warning unless it's something urgent. This is an unnecessary interruption.
4. Make two calls on your way home from work: not unless it's urgent. You can't focus on a conversation and drive.