Is Your Program Team Just a Messin’ an a Gommin’?

A long, long, well… long time ago when I was a young man, my Grandma Lossie would get all dressed up and her best friend Gladys would come pick her up for a night out. When I asked those two what they were up to, one of these two south Georgia ladies would always say, “We are just a messin’ an a gommin’!”  It was at this point that I always insinuated they were going out to pick up younger men.  They would cackle, but they really meant that they were messing around doing nothing and having a bit of fun.

Outside looking in, it can often seem like agile teams are “messin’ and a gommin”.  Especially if you aren’t in the value stream yourself.  So make sure you pay close attention, go to demos, etc. before passing judgement.   Here is a partial list of things that I expect a Program Team to do in a larger agile system.

A Program Team (or product owner team) is the second tier in larger agile systems. The following are a set of thoughts for new agile Program Teams that I stand up. I’ll start with a restating of why they exist and move into what these teams do day-to-day.

Making Agile work… a refresher

To make agile work you need:

• Clarity in your backlog
• A team that stays together
• A cross-functional team that can produce working tested software

Two Key Areas

During the day-to-day work, a Program Team has two areas of focus. They create a clear backlog that teams can consume by creating an actionable release plan. They deliver on a release plan commitment.

Delivery

During Delivery a Program Team collectively fills the traditional product owner role by:

• Prioritizing work, making tradeoffs, and reducing risk early
• Providing architectural guidance to ensure longer roadmap views are considered and to guard against overbuilding by building the simplest possible thing
• Giving clear test guidance to simplify automation strategies and balance manual and automation testing
• Providing visual guidance when, and only if, needed for clarity to delivery teams
• Breaking down larger stories to reduce risk early in the release

The Program Team does this in order to hold themselves accountable for the quality of the product, the rate of delivery, and the long-term survivability of the product.

Release Planning

During planning a Program Team provides clarity by:

• Making an actionable backlog that can be completed by the agile teams
• Performing Rapid Feature identification and story mapping
• Defining features and stories “clear enough” as the way to maximize throughput of the Program while maintaining predictability

During Planning a Program Team provides a credible plan by:

• Performing breakdown not to the scenario level, but rather to a level that can fit into a sprint. Remember that during Delivery program team will elaborate on big stories to reduce risk
• Not planning on dependent story points. The only dependencies accepted should be those where the dependency has a track record of consistently delivering on commitments. Any other acceptance really isn’t credible
• Providing architectural guidance to ensure longer roadmap views are considered

Planning and Delivery, that’s what Program Teams focus on every day. Their retrospectives should focus on these areas. Keep in mind that this is a beginning and not an end goal. While this is a rational place to start, most will have problems getting here because they can’t form teams, can’t define an actionable, clear release plan, or they don’t have the ability to produce product with a cross-functional team.  If you are ready to do those things great, if not you just might be “Messin’ an a Gommin” so get help.