SPaMCAST 454 – Iteration Planning, QA Leads, Trash or Treasure

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 454 features three columns!  The first is our essay and checklists on iteration planning. Aristotle stated that “well begun is half done.”  While we might argue the half part, planning is required to be well begun and that is important on any measurement scale.

Jeremy Berriault delivers a new entry in the  QA Corner.  In this installment of the QA Corner, we discuss the function of a QA Lead. Check out Jeremy’s blog at the QA Corner!

Gene Hughson anchors the cast with his Form Follows Function blog to the SPaMCAST to discuss the entry,  Trash or Treasure – What’s Your Legacy? Gene begins with the contentious topic of legacy systems.

Re-Read Saturday News

We continue re-reading The Science of Successful Organizational Change.  Steven Adams is leading this re-read.  In this week’s entry, we cover the introduction to Part 2 and chapter 3.  Gibbon’s takes us down the path of strategy and uncertainty. Remember to buy your copy.   

This week and previous installments:

Week 1: Game Plan

Week 2: Introduction   

Week 3: Failed Change

Week 4:  Introduction to Part 1 and Fragility to Change-Agility

Week 5: Governance and the Psychology of Risk

 

A Call To Action

Advertisements

 

Iteration Planning Meeting Logistics: Simple Checklist

Logistics Are Part of All Meetings

Planning meetings are not terribly glamorous.  They are, however, an important first step in effectively delivering value for any sprint or increment.  I have developed a simple checklist for preparing for a planning meeting (we will explore a simple process in the near future).  Agile planning events couple the discipline of saying what will be done and then delivering on that promise with the need to embrace the dynamic nature of development and maintenance.

 

Product Owner Role Problems: Part-time and Overly Controlling Product Owners

Control!

The product owner (PO) role is incredibly important in any Agile effort. The product owner leads, manages and prioritizes the backlog and networks with stakeholders, customers, and developers of all stripes.  All sorts of problems can beset the role. However, most of those problems are either self-inflicted or a result of poor organizational design.  A laundry list of problems based on observation and responses from other product owners include:

1. Product Owners Are From IT
2. Product Owners Are Not Part of The Team
3. Having a Project versus Product Orientation
4. Overly Broad and/or Ill-Defined Product Owner Role
5. Using Proxy Product Owners
6. Adopting Technical and Business Product Owners
7. Allowing Part-time Product Owners
8. Failure of Product Owner to Lead
9. Product Owner with Controlling Personality

The next set of difficulties are:

 

Product Owner Role Problems: Proxies and Split Roles

Accept no substitute.

The product owner (PO) role even when performed as described straight out of the book is difficult.  The role is often even more difficult than it needs to be, with information asymmetries between the PO, the team and stakeholders ranging to ill-defined roles. I asked over fifty product owners about why they thought the role was hard to augment my perception. I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are:

 

Product Owner Role: Impact of an Ill-defined Role and Projects versus Products

Ill-defined Roles Block The Elevator!

As I considered the intricacies and difficulties of the Product Owner role, I was concerned that my perceptions might not be as inclusive as possible. In order to expand my understanding of the role and to test my experiences, I asked over fifty product owners why they thought the role was hard.  The majority responded and I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are:

1. Product Owners Are From IT
2. Product Owners Are Not Part of The Team
3. Having a Project versus Product Orientation
4. Overly Broad and/or Ill-Defined Product Owner Role
5. Using Proxy Product Owners
6. Adopting Technical and Business Product Owners
7. Allowing Part-time Product Owners
8. Failure of Product Owner to Lead
9. Product Owner with Controlling Personality

The product owner role is difficult, and perhaps consistently more difficult than any other role in software delivery.  Part of the difficulty is a reflection of information asymmetries, other difficulties arise because of how we use words or who is assigned to be product owners.  The next two of most common reasons the product owner role is difficult are:

 

Trials and Tribulations of the Product Owner Role

Doing the Product Owner Role Poorly is Like Drowning!

The product owner role is evolving in most organizations. The role has its roots in the roles of product managers, project managers, business subject matter experts (SME) and project sponsors from other methods.  The roles and the responsibilities of the role are critical in any Agile approach to delivering value. The product owner role is difficult, and perhaps consistently more difficult than any other role in software delivery.  The reasons the role is difficult can be traced to several solvable scenarios. The most common reasons are:

 

Scaling Agile: Scrum of Scrums – Barnacles

Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

The idea of a Scrum of Scrums (SoS) is fairly simple. A bunch of people get together on periodic basis to coordinate the work their team is doing with other teams. The SoS helps everyone involved work together in order to deliver the maximum value. The SoS typically use the daily stand-up or scrum as a model. The simplicity of the logistics of the SoS and the overall utility often leads to tinkering with the format to address other organizational needs. Four very typical additions include: