Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 517 is very different from my original plan — and pretty cool if I do say so my self.  This week I spoke at ISMA 16 in Sao Paulo, Brazil. I was originally scheduled to open the session, however, the translators were two hours late. The Portuguese speaking speakers were moved earlier so that the conference could get started.  During my wait, I discovered that I could record sessions on my iPhone, therefore, the SPaMCAST 517 is a recording of my talk, titled Product Owners In Agile – The Really Hard Role! If you would like a copy of the slides please email me at SPaMCASTinfo@gmail.com .  

Note:  There is a bit of noise in the audio, shirt pockets might not be the best recording platforms.  


Re-Read Saturday News
Today we continue our journey through Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018).   Today we tackle chapters one and two. They are titled, “A Purposeful Life” and “Gluebot.”  I have not changed the estimate of 20 to 25 weeks, however, Stephen Adams has thrown down the gauntlet by suggesting we can do more than two chapters a week.  We shall see!

Links to the re-read!

Week 1 – Approach and Introductionhttps://bit.ly/2J1pY2t
Week 2 — A Purposeful Life and Gluebothttps://bit.ly/2RZANGh


Conferences and More!
ITMPI Webinar
Virtual
October 31
Register Now: https://bit.ly/2zo8MAV
Webinar:  Agile, Where Agile Fears to Tread

Next SPaMCAST
SPaMCAST 518 will feature our interview with Rebecca Staton-Reinstein.  We talk leadership and the difference between a leader and a manager. You need both!

ISMA 16 Banner

ISMA Banner!

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: (more…)

ACUT isn't all sunshine and flowers.

AUAT isn’t all sunshine and flowers.

Agile user acceptance testing (AUAT) confirms that the output of a project meets the business’ needs and requirements. The concept of acceptance testing early and often is almost inarguable, whether you are using Agile or any other method. AUAT generates early customer feedback, which increases customer satisfaction and reduces the potential for delivering defects. The problem is that implementing an effective and efficient AUAT isn’t always easy. Several complicating factors include:

  1. Having the right technical environment. Pithythoughts strongly argued in his comments (read them here) that acceptance testing without exposure to the true production environment is insufficient to really determine whether the work is “done and that business value has been delivered.” I believe that no seasoned developer or IT pro would argue, however it rarely happens except for new products or for relatively self-contained applications.  For example, consider the expense of having an environment that mirrors production for SAP on top of multiple test and development environments. Environmental compromises are made, and each level of abstraction away from the production mirror increases the risk that what seems ‘acceptable’ might not be in the real world.
  2. Acceptance test cases can be fragile. One of the central tenants in Agile projects is to embrace change. In many cases that change will need to be reflected in the acceptance test cases and criteria. Given that acceptance tests are known for suffering from false positive test failures (they are perceived to be true when they are not) they need to be carefully evaluated as the project evolves or the feedback the team gets from Agile acceptance testing can be counterproductive. Acceptance test cases need to be refactored just like code.
  3. Acceptance Test Driven Development (ATDD) can encourage big upfront design rather than emergent design favored in Agile projects. The development of acceptance criteria can lead the product owner (or other stakeholders) involved in developing the test cases to focus on “how” business value will be delivered technically rather than on the functionality or the “what” will be delivered. Fixing the design too early any project increases the likelihood of rework, and many times is the reason for rejecting change later in the project.  An emergent design allows teams to design only what is needed and then to learn from implementing and demonstrating that design.  Acceptance testing is part of the feedback loop needed to create an evolving design.
  4. Some product owners are unable or unwilling to write acceptance criteria and tests. Many times, product owners have day jobs in addition to their role as the voice to the business, which makes it harder to participate in an Agile team.  In rare cases, some product owners look at the activity of writing Agile user acceptance test cases as being beneath them. I once heard a “product owner” state that writing test cases was an IT job or maybe a clerk’s job – certainly not something he should do. Regardless of whether you are using Agile or waterfall, user acceptance testing is a critical step towards implementation. I find that in these scenarios, generating the proper level of product owner involvement takes a significant amount of time and effort. In the short run, partner a business analyst with the product owner to shepherd the creation of acceptance criteria and then pursue a long term coaching opportunity to change the product owner’s attitude.

Agile user acceptance testing is a method of pursuing feedback from the business early and often by focusing the product owner (and by extension the rest of the business) on considering and then documenting the proof they will need to accept what the project will deliver. AUAT is not easy nor is it free.  There are numerous issues that need to be dealt with to make sure Agile acceptance testing is done correctly.  Without an environment that is as close to production it will be difficult to interpret the results.  Just because you capture acceptance criteria once does not mean you are done, acceptance criteria need to be continually review and refactored just like code.  If the process you are using to generate the acceptance criteria mean that you need to develop the solution too early, you need to step back and take the process more incrementally. Finally remember the word user in the Agile user acceptance testing otherwise you are just doing developer-based functionality testing.  Agile user acceptance testing is not all sunshine and flowers, but the outcome is generally worth the hassle.