An Ocean of Plastic - #FrameworksForSocialGood

On March 18th, the body of a curvier beaked whale was retrieved from Davao Bay in the Philippines. The cause of death - starvation and dehydration as a result of ingesting ninety pounds of nylon rope, plastic bags, and other plastic objects found stuffed in the animal’s stomach!

A month later and a half a world away, a pregnant sperm whale was found dead off the coast of Sardinia. In this poor animal, marine biologist retrieved nearly fifty pounds of routine plastic products - fishing nets, fishing lines, flip flops and plastic bag, pipes, plates and drinking cups!

"These tragic stories are not isolated or freak occurrences but a series of troubling statistics that point towards growing global problem - our oceans are becoming clogged with plastic detritus and debris." said Carlton Nettleton, Chief Product Owner at Applied Frameworks.  "Something needs to be done about this complex global problem because the status quo is untenable.  If we do nothing, and continue along our current (mis)use of plastic, the oceans are going to become a plastic soup."

Since 1997, when the Great Pacific Garbage Patch was first discovered in the North Pacific gyre, our awareness of the amount of plastic clogging our oceans, and its impact to marine life, has grown.  Here are some data points meant to shock you about the severity of the problem:

  • 8,000,000 metric tons of plastic is dumped into the ocean every year, that is the equivalent of one dump truck stuffed full of plastic being dropped into the ocean every minute.

  • Today, the Great Pacific Garbage Patch is nearly three times the size of Texas. In the last twenty years, four other garbage gyres have been discovered increasing the amount of the ocean’s surface covered with plastic trash equivalent to the land area of the continental United States.

  • Over 700 species of marine animals have been documented to consume ocean plastic - 90% of all sea birds, 50% of sea turtles and approximately 10% of whales and dolphins have all ingested plastic. If you have eaten seafood recently, chances are you ate plastic.

  • More then 50% of the plastic junk in the ocean today has been deposited there within the last twenty years. Yet, our efforts to recycle this garbage remains less than 10%. It is estimated that by 2050, there will be more plastic in the ocean than fish!

"When Carlton shared the impact of this problem with me, I knew we had a unique opportunity to help others see what we were seeing." said Jason Tanner, CEO of Applied Frameworks. "Over the course of the next three days at Scrum Gathering Austin, we are going to use our expertise with frameworks to help raise awareness of this problem, explore why we do not do more to resolve this challenge and inspire action. Based on the the guidance provided by the conference attendees, Applied Frameworks is going to make a charitable donation to a non-profit dedicated to helping clean-up the oceans."

Come visit us at Booth #600 to learn more about this problem, share your perspective, commit to making a change in your use of plastic and inspire others to change their behaviors.  Each day, we will be exploring a different elements related to the problem of an ocean of plastic to gain deeper understanding of why this challenge is so hard to resolve.

  1. May 20th - What Lies Beneath: in order to understand any complex problem, it is important to explore the issue from a variety of perspectives. Help us go below the surface to identify the various factors which contribute to the accumulation of plastic trash in the ocean.

  2. May 21st - Pains-Gains Map: to devise a lasting fix to a complex problem requires a deep understanding of the aspirations and fears of the human actors. Take time to explore the lives of plastic consumers, i.e. ourselves, by identifying what benefits and pains we could experience if we use less single-use plastic.

  3. May 22nd - Buy A Feature: there are number of interesting proposals that address the plastic contamination of the oceans from the mundane, banning straws, to the high-tech, deploying autonomous garbage drones. Help us identify which of these solutions are most appealing to you, and we will make a charitable donation to help rescue the oceans.

If you cannot make it to Scrum Gathering Austin, we will be scheduling a few on-line forums to allow you the chance to participate in this project and help understand why this problem is not getting resolved.  In the meantime, learn more about this problem, recycle the existing plastic found in your home, think of ways to reduce your use of plastic and share your direct action using our hashtag #FrameworksForSocialGood.

Is Your Value Statement Valuable?

I was recently coaching a colleague who was looking for some guidance on proper story structure.  I reminded her of the “As a <user>, I want <goal> so that <value>” format.  That led to a discussion of the <value> portion of the story because so often, the value statement is either omitted or doesn’t represent true value.  I gave her the following example:

As a banking customer, I want to pay my bills online so that I don’t have to send a check in the mail.

In the above statement, eliminating the need to send a check in the mail does not reflect the true value, rather it is merely a restatement of the goal of paying bills online in a different form.

Upon closer inspection, the value of this user story could be any number of things such as:

  • Time-savings – it takes longer to write a check, find a stamp, and mail the payment

  • Speed of payment – the customer may not want to wait the additional days it takes for the payment to be received and processed

  • Monetary-savings – if the customer has many bills to pay, they may not want to pay for stamps

  • Better record-keeping – paper records are laborious to manage, take up space, and are more easily lost or destroyed

Simon Sinek, author of the well-known book, “Start With Why” encourages readers to begin with the end in mind.  One approach for deriving intended value is using the 5 WHYS technique whereby you continue to ask WHY until you reach a root cause, or in this case, a root value statement.

  • I do not like to pay bills by check.

    • WHY?

  • It is inconvenient.

    • WHY?

  • It takes too long to mail in and process.

    • WHY?

  • I often misplace my paper bill or my checkbook.

    • WHY?

  • I carry the bill or checkbook with me in a purse, briefcase, etc. or move it to a different room with the expectation that I will have time to pay it and then I don’t get to it.

    • WHY? (does this contribute to it taking too long to process)

  • By the time I mail the payment, I am never sure if the payment will arrive and be processed on time.

In the above example, this particular customer values speed of payment, however by using the 5 WHYS questioning technique, another value was identified. The customer wants to eliminate the uncertainty of when a payment will be received and applied.  In reality, the processing time itself may not be long once the payment is received, but from the customer’s perspective, the uncertainty of when it will be processed equates to long processing time.  Although the customer may also desire some or all of the other benefits listed above, by gaining an understanding of the primary value desired by the customer, the Product Owner can more effectively prioritize backlog items.

As you create new stories and evaluate existing stories in your backlog, be cognizant of the value statement.  Does it simply restate the goal or is the true value reflected? Is the value to the customer indeterminable because the story is not written in the voice of the customer?  Your customer is your why.  You need to determine their why.

Vertical Story Slicing Takes the Cake!

One of the challenges I continually observe Scrum teams struggle with in their Agile adoption is the concept of vertical story slicing. As described by Wikipedia a vertical slice “refers to a cross-sectional slice through the layers that form the structure of the software code base.” For example, a simple vertical slice would encompass the data access layer, the business logic layer (a.k.a. middleware layer) and the user interface layer.  A vertically sliced story should also encompass the testing that corresponds to the functionality being delivered.

Vertical slicing is intimidating to teams when they first experiment with it.  Even teams that understand it conceptually often struggle with decomposing their stories small enough while still achieving a vertical slice.  Consequently, teams revert back to their old habits of creating user stories that are horizontally sliced. For example, they’ll define one story to create a web service, another story to create a database table, and yet another story for testing. These so-called stories, are actually tasks.  Horizontal stories typically do not meet a well-formed story structure of “As a <role>, I want <functionality>, so that I can achieve <value/outcome>” and they don’t meet the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).

During one coaching engagement, I received feedback that the team was frustrated because their new Product Owner wasn’t being effective.  The acceptance criteria in the stories were vague and insufficient. The team had previously been operating without a Product Owner so the initiative was being led by what could be considered an architect or technical lead.

I joined one of the team’s backlog refinement sessions to observe firsthand what was happening.  It was readily apparent that the Product Owner was indeed not being effective, not due to incompetence, but because the stories in the team’s backlog were not vertically sliced.  The team was working on an initiative that involved significant technical complexity. The team had become accustomed to working under the guidance of the architect/technical lead who was creating horizontally sliced stories (in reality, tasks).  Furthermore, the development team was working with new technology so they were heavily dependent upon the architect/technical lead to guide them in how to implement the tasks. The new Product Owner had substantial business expertise but because the stories were structured horizontally and the Product Owner could not write detailed technical specifications, the perception was that the Product Owner was not competent.

Working with the Product Owner, we applied some of the common story slicing patterns listed below to define vertically sliced features and stories for building a data dashboard and launching detailed reports from the dashboard.


  • Workflow steps

    • e.g. steps to checkout at an online store; enter billing address, enter shipping, address, enter payment information, etc.

  • Simple/Complex

    • e.g. ship to single address vs. ships to multiple locations

  • Business Rule Variations

    • e.g. process transactions in states that don’t collect sales tax vs. states that do

  • Major effort

    • e.g. add to shopping cart, add to wishlist, etc.

  • Operations (Create, Read, Update, Delete)

    • e.g. Add item to cart, view cart, update items in cart, remove item from cart

  • Variations in Data

    • e.g. show shipping dates for Amazon Prime vs. non-Amazon Prime customer

  • Variations in Interfaces

    • e.g. mobile, tablet, PC

  • Defer System Qualities

    • e.g. performance, logging, etc.

  • Happy vs. Unhappy Path

    • e.g. enter credit card info, credit card is expired

Here are some abstracted examples (so as to not disclose any proprietary details) of how we translated some horizontally sliced stories to vertical slices:


  • Modify universe to add data element X to SQL query

  • Build a table to store dates and date ranges

  • Create a job to pull data into a database

  • Convert data to use new data model

  • Create a new endpoint on the existing web service to return a static list of filter options


  • Show business metric A in a pie chart with prior year annual totals

  • Show business metric A in a pie chart with current year annual totals

  • Show business metric A in a line graph with prior year totals

  • Show business metric A in a line graph with current year totals

  • Report A – Display demographics section

  • Report A – Display business metric A line item details

  • Report A – Filter by Date

  • Report A – Filter by Location

In the above vertically sliced examples, the Variations in Interfaces pattern was used to slice stories into pie charts and line graphs.  These stories were further decomposed using the Variations in Data pattern to delineate between prior year and current year as well as the different sections of Report A.  Another pattern of splitting by Major Effort was used to define filtering capabilities in Report A by Date and Location.

Vertical slicing allows teams to demonstrate incremental progress thereby increasing transparency.  Just like no self-respecting dessert lover would accept a horizontal slice of cake that might be missing the top layer of icing or the yummy filling in the middle, stakeholders appreciate seeing a pie chart or the first section of a report in a Sprint Review versus fragments of Java code for a web service.

Unfortunately, I have observed resistance to vertical slicing by teams because they are more concerned about management optics.  It’s easier to “hide” the lack of progress when stories are more technical in nature or there are a lot of stories (that are really tasks). Even if the team falls short on its commitment, they still appear to have successfully delivered the bulk of their work in that sprint.  While their concern is understandable if the organization’s leadership is too heavily focused on metrics that don’t emphasize value delivery, for a team to be truly Agile, they must be willing to be transparent, experiment, sometimes fail, inspect, and adapt. Any team that doesn’t experiment, doesn’t occasionally fail and most importantly, does not deliver tangible value, is not Agile.  If your team is struggling to define acceptance criteria, it cannot effectively test a story, or it cannot validate that it meets the definition of done, evaluate how your stories are sliced. Allow your team time to experiment and practice with vertical slicing and pretty soon your team’s stories will take the cake!

Confessions of a SPC Cheating on the Scaled Agile Framework

I’ve developed a knot in my stomach. I feel like I’m about to cheat on one of my early Agile loves – SAFe. It’s just exploring, right? Well, maybe… maybe I’ll go back, but then again maybe not. I guess I won’t find out until I try, right?

I am a SPC, a Scaled Agile Framework Program Consultant, and I’m going to a Scrum@Scale class next month. Not just any Scrum@Scale class, but one taught by Jeff Sutherland. [insert giddy giggles…]

Jeff isn’t the only draw.

I’ve been a SPC for almost five years and was on the team that explored how we might be able to implement the Scaled Agile framework at a former employer. In fact, I may have been the very first Product Managers who was certified as a SPC. It was a big deal and I was very excited about it. Who doesn’t love the SAFe Big Picture?

That Big Picture was a huge draw for us to evaluate SAFe in the early days of our Agile transformation. It was a natural extension of what we had recently accomplished by adopting Scrum. There it was; a recipe book for how to build software at scale in our large, complex environment. For that reason, SAFe took hold in the organization.

As Jeff and the team at Scrum, Inc. have aptly pointed out, not all companies, and certainly not all Scrum implementations are the same. I would add that as you mature along your Agile journey, the recipe book that was once comforting might now feel a bit restricting. I’ve heard it from some of our customers, “…we really like parts A and C of SAFe, but D and F feel like overkill and unnecessary.”

Additionally, I have recently been working with Scrum teams that don’t build software, but need to scale beyond the single Scrum team. Although those smarter than me may disagree, SAFe doesn’t quite feel right in these instances either. Scrum has expanded beyond the domain of software, and we need to find ways to scale that fit.

And this is when I started to explore...

Let’s inspect and adapt not just how we apply Scrum and other Agile methods, but how and why we should scale. My interest in branching out as a consultant and coach, and even as a SPC, is to explore how we might help those that don’t quite feel that popular scaling frameworks like SAFe “fit.” The lighter weight, modular, fractal structure that we see in Scrum@Scale may be just the right approach to scale an organization.

Stay tuned. In about a month I’ll let you how it goes. Meanwhile, anyone want to cheat with me?  Scrum@Scale with Jeff Sutherland, November 8-9, Durham, NC

Registration Link


Letting Go of Blame

Every year I try to attend training. Last October, I participated in Christopher Avery’s The Responsibility Process Intensive in Munich. I approached the workshop as an opportunity to improve my coaching. Surprisingly, the workshop profoundly improved my personal life as much as my professional life. Christopher shared that many people come to the workshop to help others with responsibility, and usually leave realizing they first need to improve their own understanding and practice of responsibility.

The first key to taking responsibility is awareness. When something goes wrong, I have become much more aware of how I react. Christopher explains that we naturally respond to something that upsets us by laying blame. “Who did that?” “It’s his fault.” And so on.


As you can see in the image of The Responsibility Process model, Lay Blame is the starting point. Christopher’s training provides tools to mentally navigate from the bottom to the top – to Responsibility. Now that I am much more aware of my response, I can let go of blame faster. Further, since my response is natural, I forgive myself for being there, even for a moment.

Why does this matter? I have two children, my son started college and my daughter started 10th grade this year. We have an active household, and occasionally things go wrong. When they do, blame comes very easily, but doesn’t help. “I can’t believe you didn’t mow the lawn!”  I was angry. I asked my son to mow the lawn last night. But yelling doesn’t help, and could upset him, too. Instead, I let go of blame and consider what I could do differently to request and obtain his help. By letting go of blame, I completely avoid anger. I’m happier and he’s happier. With a clearer head, I can spend energy on a new approach.

I’ve seen the same scenario in my work. “Scrum won’t work because management won’t support dedicated teams.” Blaming management doesn’t improve the situation. And getting stuck in blame won’t lead to a solution to the team’s problem with focus and commitment. Letting go of blame provides the clarity to explore solutions.

To learn more about The Responsibility Process, I encourage you to download the first chapter of Christopher’s new book or to register for his upcoming workshop in Raleigh.