I will try to answer the Signal-to-Noise issue in another post (I think that being in the stand up meeting could be noise to management)

In answer to the questions…

* We raise an event if it needs to be raised. The important thing there is to increase the signal-to-noise ratio. If an event gets raised every time someone has a hangnail, it turns into “the boy who cried wolf” and folks stop paying attention to events that get raised.

* We talk about the problem enough to characterize it and understand the context. From there on out, it’s solutions, baby.

* Management doesn’t have to proactively ask about status because they’re in the loop all the time. They have access to the work item tracker so they can see what’s done, what’s left, and what’s in progress; they participate in the stand-up meetings (listening in, not reporting), and the team involves them when an “insurmountable” road block is there.

* We have regular team-wide and individual discussions with management about both project and non-project things to help keep us growing not only in the context of the project but also in the company and our own personal careers.

I can’t speak for other teams, but the group I’m in right now has an excellent manager who has figured out the exact balance of how much to be involved and how much to let us handle things. When we need help, we know he’s got our back, and we’re in constant communication through various means so he always has a “pulse” on how things are going in both project and non-project areas.

That said, there’s always room to learn, so seeing some of the things you’re writing about is really educational. I’ve been taking some of it back to the group to talk about in our weekly staff meeting (which is both project and non-project discussion). Keep it up!

There is still a small difference, that might (or might not) make a difference, and I hope that I have managed to convey it.

Do we focus on the responsibility to raise the event?
Do we talk about problems or about solutions?
Do we free management from asking about the status?
Does management get the needed information, to enable you to grow?

I hope that there are some tricks that you can experiment with and see how they work in your team.

First, our teams are already highly communicative. If there’s something blocking, then generally speaking, relevant folks on the team already know – before stand-up happens the next day. When someone needs help with something over the course of the day, they ask for help. The stand-up is there to bring it to the attention of the people who don’t already know so if there are additional people interested in or capable of helping, they can follow up after the stand-up. For the folks that can’t help or are already mired in higher-priority things to do, their time isn’t held up and they can get about their business.

Second, the folks I work with are pretty highly competent. I trust them to get things done the right way. Do mistakes get made? Sure. Everyone makes mistakes. Do problems sometimes get solved “the wrong way?” Again, sure, sometimes, but that’s going to happen. The important thing is that we learn from these mistakes and grow from them. (These things get reviewed in retrospectives and, if changes need to happen, those change get prioritized as new work items.)

If everyone is involved in every decision every step of the way, it turns into a “How many engineers does it take to change a light bulb?” scenario. Or micro-management, which is worse. Involving relevant people at the correct time is the key to success and effectively managing time.

Using your IT example, what would normally happen on my team(s) would be that the folks encountering the problem would figure out how to characterize it and come up with some possible solutions. If there’s a clear winner that will help us get our jobs done and not be detrimental long-term, that’ll just happen. If there’s a question on which approach to take, though (maybe some cost/benefit trade-offs), the team member(s) with the issue will immediately seek assistance from other members on the team who might be able to help. That smaller “inner team” will determine the best solution, execute, and let the rest of the team know what the solution was. That communication could happen in any appropriate form – during a staff meeting (not stand-up; stand-up would be “we unblocked this issue” but not the full detail on the resolution), on the wiki, via email, etc.

And, of course, if no solution was reached, then the mention of a “blocking item” gets made at stand-up and relevant folks can stay behind after that to discuss the issue while letting the rest of the team get on with things. That means it never goes more than a day without relevant people getting involved.

This mechanism works really well and has the benefit of addressing the problem before we have to get everyone in the room for a status meeting.

If something sits on the “blocked” list for more than a couple of days, we get more people (and/or management) involved to get the issue unblocked. And, of course, you don’t have super-long sprints (maybe one-or-two-week sprints?) so the longest anything can go with the “excuses” is one sprint duration. After that, the blocking item becomes re-prioritized and handled in a more direct fashion as a first-class work item.

I think it’s two different ways of accomplishing the same thing – addressing risk earlier, coming to better solutions faster, and helping the team to grow and become more self-managing.