Meetings? We don’t need no stinkin’ meetings?

There seems to be no set standard for development meetings.  Some groups complain about being ‘meetinged to death,’ while others complain about a lack of communication, direction, or group cohesion.  Given the two options, it is generally agreed that overcommunication is much better than undercommunication.

One of the more innovative approaches to cutting down on meeting drain is the concept of the ‘stand up meeting.’  This is were all participants (except maybe senior citizens) stand for the duration of the meeting.  Amazingly, during this process, nobody seems to have long weekend stories to tell the group, and answers and discussion points become more concise.

Normal development meetings ought to serve the following purposes.

  1. Communicate transparency from development to corporate.
  2. Communicate direction and prioritiziation from corporate to development.
  3. Communicate present-status and next-step planning regarding a project.
  4. Promote team-workload communication among team-members.
  5. Six month employee review.
  6. Deployment rehearsal.

More on these later…

Mike J Berry
www.RedRockResearch.com

Why should Corporate Strategy be important to us in Development?

We code, right!?  We code, and play Warcraft.  Why should we know or care about corporate strategy?

Well, the answer is that most programmers probably don’t really know what their organization’s corporate strategy is.  If you do, you likely have an outstanding manager who has learned that part of their responsibility as a manager is to communicate executive directives back to Development.

A company that performs good ‘Strategy Management’ will do two things:

  1. They will broadcast their corporate strategy to all employees so that everyone can be on the same page.
  2. They will establish measurable metrics throughout the organization to determine how close everyone’s efforts are to the decided strategy.

When this happens, an effective plan is for the Development department to adopt their own ‘Department Strategy’ that supports the Corporate Strategy.  Then look for ways to measure how effective they are at pursuing that strategy.

For example, if your team has to report total hours for the week, reporting could be enhanced to include how many hours each programmer spends on each project.  Then each project can be placed into separate ‘strategy categories.’  Then, time can be measured for each project worked on during the week, and a summary comparison can be presented to upper management showing that the Development department is ‘following corporate strategic goals’ by spending a proportional amount of time on projects that are aligned with various corporate strategies.

If you are a manager and do this before you are asked to, you may even earn yourself a few stripes.  Kapish?

Mike J Berry
www.RedRockResearch.com

What is Software Portfolio Management?

What is Software Portfolio Management, or SPM?  They never taught us about this in college.  This is when you are reading your email in the morning from an unhappy customer who wants new feature X when suddenly your phone rings and the VP of Sales wants to know when you will have an install ready for a customer Y whom you never heard of before and then all of the sudden the CEO walks in and announces that your team needs to start on pet project Z.  Sound familiar?  Enter SPM…a solution to stop the madness.

Here’s how it works.  Your Executive Staff meets every two weeks.  You produce a list of all the hours available that your programmers collectively have for the upcoming two weeks (minus vacation, etc).  You produce a second list of ongoing projects, pending projects, and then you offer up the floor to whomever wants to request new feature X, Y, or Z.  They get to justify their request to the whole Executive Staff, preferrably on paper, and then the whole staff decides when to start on the new project, and how to prioritize it.

This way, project requests get presented and evaluated against the opportunity cost of the other projects, and not based on urgency or theatrics.  There’s a little more to it, but this basically describes an effective solution for an age-old problem.

Mike J Berry
www.RedRockResearch.com

« Previous Page