Wow, bad advice. Or maybe just bad advice for managing programmers. Interruptions suck and this advice just seems like interruption-based management.
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.
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.
> Daily stand-ups are an attempt to get people doing this. But it's like pulling teeth.
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 interesting you would see it that way -- 'cause I'm an agile coach. I train CSMs and teams when they first start using agile/scrum techniques.
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.
The project was interesting because it involved the new process (Scrum), a new technology platform (Adobe Flex), and a fair amount of requirements (rework) and technology (refactor) churn. And it was a "1.0" product. And there were high revenue expectations (which were exceeded+met, at least until the recession)
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.
To the degree you are relaxed, having fun, and working hard, it's working. Use that as a guide. Scrum/Agile isn't magic or new -- it's just stuff that smart teams have been doing for decades.
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.
Agreed. Four-week sprints are more like a frigging 10-k. And some of them were run in perilous, icy conditions (1.0). However, that's the in-company standard now. We're ok with it - we've learned much more about team velocities and how to balance it with product owners' expectations.
Excellent point. We don't do scrum/agile, but I found the daily quick meetings valuable. What worked for me as team lead was to change my parking spot so I came in through the door nearest my team (we were at opposite ends of the bldg) and I'd hold a 5-10 minute meeting before I even sat down that day. A very simple "how did things go yesterday/what do you plan to do today/are there any obstacles or questions to get you going" and we were done. Contrast this to the larger status meeting with the bigger group which normally turned into a 1 hour waste of time!
This reminds me of Jack Welch's dictum to make every interaction with an employee an opportunity for evaluation. In quiet, implicit ways, a manager should always be evaluating his or her people, he says. The flip side suggested by this piece is that every interaction could be an opportunity for feedback and coaching also.
How to micro-manage and de-motivate people in 15 minutes every day.
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.
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.