Staff Meetings & Agile/Scrum

Forgive me for using such direct language in this reply but this was such an incredibly frustrating post to read.  Also, while I am being direct, because I see these mistakes made all the time and I want to help you out, my response is targeted at your post and NOT at your personally. 

> I think my team would benefit from having a weekly staff meeting but the 90 minute
> format seems like overkill because of the meetings that we already have to support our
> scrum process. 

If that’s what you think then change it.  Especially if you are the scrum-master.  Otherwise, it’s hard to answer specifically as we don’t have a lot of background from your post regarding your environment, feedback you have gotten from your staff, etc.

But I don’t mind saying this is what makes me so frustrated about contemporary implementation of project management processes and continuous improvement processes.

Nowhere in the Agile Manifesto does it say thou shalt hold <<insert meeting here>>, for <<insert duration here>>, every <<insert frequency here>>. 

Rarely does it say you must do anything.  There’s lots of guidance and recommendations though.  Scrum, Agile/XP, et al., are FRAMEWORKS.  You take what is in them at tailor it to your organization’s benefit.  They are there to support the product and/or services you offer.  Not the other way around.  If something is in Scrum, for example, which you don’t see as a fit for your org, then don’t do it.

> Is a weekly staff meeting beneficial in an Agile/Scrum environment?

Only if the weekly meeting has an actual agenda other than having a meeting for meeting's sake.  Why weekly?  You already mention you have daily huddles for 15 minutes and then twice monthly meetings.  What more is this weekly meeting going to give you?  If it gives you something else, great.  But the need for the meeting, other than supporting your CIP/PM frameworks, wasn’t mentioned in your original post.

Internally, meetings have to be considered expenses.  At least in my situation they are.  If I pull my staff into a meeting, they aren’t actively doing the work that brings in the revenue.  They’re sitting in a conference room and not at their desks or in the development lab.    They are otherwise occupied in a meeting and not providing products and services to our clients.  So before I hold a meeting, I ask myself:

-- Why do I need to hold this meeting? (and because Agile says so or because it’s time for the weekly meeting are wrong answers)
-- Who needs to attend?  I mean who really needs to attend?  Can I send # people and they can brief everyone else at the 15 minute morning huddle planning the day’s tasks?
-- What are the goals for this meeting?  The goals must be measurable... so that the task is well defined and you can hold people accountable.  Otherwise you’ll just keep having the same meetings over and over again for the same 'ol s***.

> if so should the part of the meeting where the directs give status updates be skipped

You need to ask why status updates are briefed in the first place?  It could have value, it could not.  This forum doesn’t know. 

Personally, at my shop, we don’t brief status updates at regular meetings where the day-to-day staff attends.  Status can get updated via email, actually talking to people (fast becoming a foreign concept in cube farms), and we use automated methods which show the amount of work completed each day.

With the automated methods, at any point in time, a portal can be accessed and anyone can see a graph of a project’s status from anywhere there is an internet connection.  There’s no need to brief anything to anyone outside of VP level, because anyone who wants to know everything there is to know about one, some, or all projects has live data only a few mouse clicks away.

So to summarize, tailor the frameworks to your organization, just don’t have meetings because it’s tradition or some guidance told you to have one.  Moreover, and your post didn’t address it, approach your meetings smartly.  Get in, get genuine, measurable work done -- which provides a tangible benefit to everyone in attendance, and then get the heck out.
 

Andrew,

I"m head of a software development organization that just switched to using Scrum.  My solution is to have a department meeting every two weeks.  It lasts about 30 minutes, and it includes the kinds of of announcements that you have described above.  I also ask each Scrum team (not individual) to give a very brief update on what they want the other Scrum teams to know.

The scrummasters and product owners also participate in a weekly "scrum of scrums" to discuss inter-team issues.

In addition to those meetings, I hold a staff meeting with my managers.  This is usually not concerned with day-to-day issues, but focuses on things like long-term strategy development.

And O3s of course...

--Rich

Difference in our situation is that I'm the operations team lead with a group of PMs, BAs, and developers. Because of the tactical issues that we support on a daily basis, we hold a 15 minute scrum every day. I then also hold a 30 minute "team call" at the end of the week as a summary of what went well during the week and what is still open that we need to finish up. We also use the team call to plan for the following week as well as to share with management team and allow them to ask any questions they have. Frequently, management doesn't show up so it just ends up being a summary for our own planning purposes and only lasts about 15 minutes. We have a template that I maintain each week for the summary and post it to our groups intranet site for anyone to see where we are at any point in time. It works well for us. I also do O3s through the week with the various team members.

The scrums allow me and the team to remain on top of any issues that have arisen, for the team to see what issues have come up, look for any patterns that help us to prevent issues in the future, and for those team members with expertise in areas to chime in where they can. The team call is, again, just a summary call for the week. And the O3s are, well... O3s...  ;)

Not sure if that info helps you or not, but it works for us. Keeps the amount of meetings short on a day to day basis and prevents me from having to ping various team members throughout any given day to find out the status of the latest round of issues, testing, metrics, standards, or any of the other projects that we are working on.

But that operation will work?

Scrum Process