Open Community Access to Crowbar 2 Efforts

We’re moving along on the Crowbar2 refactoring work (`/release/rails3anddb/master` branch for now) and it’s time to start making it easier for you to participate if you are interested.

We are planning to start having TWO weekly community sprint meetings.

NOTE: Times can still shift depending on community input! We are trying to a truly global community so we need your input.

The weekly design discussions will be on Tuesdays @ 10am Central (GMT -6). The topics will be relevant to the coming sprint and we expect dialog. The topics will be determined by Greg Althaus based on progress on the refactor. You’re welcome to contact him or the list with suggestions.

The purpose of these meetings is to

  • discuss/resolve design related to the refactor
  • Document use-cases
  • identify issues that need to be addressed in the next sprint

The weekly coordination meetings will be on Thursdays @ 8am Central (GMT -6). We want to respect everyone’s time and will strictly limit these to 1 hour. This meeting is in between our internal sprint review and planning so we have flexibility to adjust our plans based on your input. It is important to us that we make it possible for you to contribute and we need your input to make sure that you are not blocked!

The coordination meetings will be structured as follows (times approximate)

  • Voice & Screencast:
  • 25 minutes for review of current progress
  • 10 minutes for feedback/adjustments on process and workflow
  • 25 minutes for planning of next sprint
  • Online discussion & notes on the etherpads
  • Identification of working groups for further discussion and coding collaboration

These meetings are the primary way that we will be making sure the community is not blocked by our development efforts.

The purpose of these meetings is

  • to synchronize quickly so that we can connect the people who should be collaborating
  • eliminate blocking items for Crowbar contributors

Of course, we will attempt to record and post all of these meetings.

Stay tuned! We will likely announce additional meetings for community collaboration.

PS: These are design meetings, they are NOT Crowbar training meetings. Please consult for links and videos about learning Crowbar.

Please (I’m begging here) consider the psychology of meetings!

It’s an occupational hazard that I go to a lot of meetings.  That’s not a bad thing because my job is a team sport.  Except for rare moments of programming bliss, my primary responsibility is to design, collaborate, and coordinate with other people.

The Problem

My problem with meetings is that we often forget about psychology when we are holding meetings.  I’m not going to go all B F Skinner or DeBono’s Hats on you, but I want to reinforce that we all have DIFFERENT MODES OF THINKING during meetings.  Some examples:

  • Listening to a presentation *
  • Giving/getting status *
  • Designing a product or presentation
  • Negotiating requirements
  • Making collaborative decisions
  • Celebrating success *
  • Giving subjective feedback

Let’s get concrete.  It is impossible to get people to  do design during a status meeting.  Even if you have the same people in the room, the way they behave (taking turns talking, rushing to finish, linear) during a status meeting is fundamentally different from how I would expect them to act during a design session (dynamic back and forth, pausing to reflect, circular)

It’s even worse when you factor in time bound meetings (I added * to them above) for open-ended activities like design, feedback, and collaboration.  If you want to kill ideas or suggestions then ask for them during the closing 2 minutes of a meeting. 

A big part of the solution is to remember how people are framing your meeting. 

  • If you want decisions but need to get people up speed then plan a clear end to the status part of the meeting
  • If you want feedback and discussion then don’t throw in a lot of status or one-way presentations.
  • remember:  Any meeting with a power point deck is a PRESENTATION.  It is not a discussion.

Agile Meetings

One of the things I like about Agile is that there is a lot of psychology in Agile!
The meetings in Agile are planned so that people are in the right frame of mind for the meeting. 
  • Stand-up (scrum) is a time bound status meeting.  It should be tight and focused.
  • Review is a FEEDBACK meeting and NOT a presentation meeting.  I like to have different people talking during the meeting so that it does not put people into a power point stupor. 
  • Retros are discussion meetings.  The must be open ended so people are not rushed. 
  • Planning is a design meeting where new ideas are formed.  People must be relaxed so they can be interact and collaborate.
It’s even more important to understand that the way iterations unwind is part of the magic
  • Reviews reinforce that team member have completed something.  It puts them in the frame of mind that they have closed something and are ready to start on new work.
  • Reviews give feedback to set priorities so that people feel like they know what’s important.  Their expectation is that they are working on what’s most important.
  • Retros build up team spirit.  They celebrate achievement and clear the air so the team can collaborate better. 
  • Retros establish team trust.  Trust is the single most essential ingredients for good design because people must take risks when they make design suggestions.
  • Planning brings together the feeling of accomplishment and purpose from reviews with the trust and collaboration from retros.
  • Planning should empower a team to be in control of their work and be confident that they are on the right track.
  • Stand-up, when planning works, becomes a quick reinforcement of priorities.
  • Stand-up should be status that the plan is on track or lead to a discussion (a new focus) for correction.

If meetings are getting you down then consider what type of meeting your are trying to create and focus your effort on that outcome. 

Oh, and my #1 tip for more effective meetings

Find ways to be collaborative by sharing screens, co-editing documents, or just rotating speakers.  It’s not a productive meeting when just one person has the conch.

Spoonful of Zietgiest

Do you want to have a winning team?  Bring a spoonful of zietgiest to your next meeting!

For me, Zietgiest is about how group dynamics influence how we feel about technology and make decisions.  It’s like meme, but I like Zeitgiest more because of its lower vowel ratio (Hirschfeld = 2:10).

Yesterday, my release team meeting had negative Zeitgiest.  Locally everyone was checking email while the remote speaker flipped through dense powerpoint slides.  It was like watching my divorced aunt’s family vacation slides via Webex.  We needed a spoonful of zietgiest!  That’s how I found myself explaining some of our challenges with the phrase “turd in the punchbowl” and getting people paying more attention to the real work.  A small positive spark and faked enthusiasm changed the momentum.  Yeah, it was fake at first and then become real zeitgiest when the other attendees picked up on the positive vibe.

The idea of seeding zietgiest is critical for everyone on teams.  It’s like the William James expression,feeling follows action: if you act happy then you’ll shake off the blues and start to feel happy.  Yes, this is 100% real.  The same applies for groups.  We can choose to ride or steer the zietgiests.

There’s no reason to endure low energy meetings when you can get out your spoon and stir things up.