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.

Patterns

  • 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:

Horizontal

  • 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

Vertical

  • 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
 

SatSSAFe.png

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.

Poster_Responsibility-Process_Web.jpg

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.

 

The Scrum Alliance Problem We’re Not Solving……Yet!

As of today, the Scrum Alliance identifies 322,157 people as Certified ScrumMasters (CSM). You can find 66,813 people identified as Certified Scrum Product Owners (CSPO), and a number of people have both certifications. Although the anemic number of Product Owners relative to ScrumMasters raises some questions, the more serious problem is the drop-off in people reaching the next level. Only 3,943 people achieved the level of Certified Scrum Professional.

This is not a small problem. This is an order of magnitude problem! And we need to solve it.

We need more people with three or more years of Scrum experience and demonstrated initiative to continue learning.

We need more people who have learned how to be successful leveraging Scrum to increase organizational value. And we need them to continue their success and to help others achieve success.

We need more Scrum coaches - both enterprise coaches and people striving for the new team coach certification. We need organizational change experts or, at the very least, people who have been through at least one change experience and have learned what works.

And we need more trainers. The 191 trainers and 80 coaches aren’t getting any younger. At the current rate of growth of CSPs, we may have a shortage of certified trainers and coaches within five years.

So, if you agree that the Scrum Alliance does have an important problem to solve, you may be wondering the same thing as me…What’s going on with the hundreds of thousands of people who haven’t reached CSP yet?

Could the certification be too hard to achieve?

The answer is subjective. To apply, people must:

  • Be a current holder of an active CSM, CSPO or Certified Scrum Developer credential.
  • Have at least three years of Agile/Scrum work experience within the past 5 years implementing Scrum in any role.
  • Gather and submit 70 Scrum Education Units (SEUs) from the past three years.
  • Invest $100 to apply and $150 when approved.

And people get a head start - 16 SEUs from the CSM class, up to 24 from CSD, and/or up to 16 from CSPO - and those certifications could have been earned more than 3 years prior to submitting the application. All other SEUs need to be earned within 3 years of the application.

So, over 300,000 people meet the first requirement. Based on membership statistics, over 150,000 people meet the second requirement, assuming they continued to apply Scrum after their classes in 2012 or earlier.

Perhaps the SEUs present a challenge?

  • Up to 45 SEUs may be earned from Scrum events like gatherings, local user groups or other Scrum Alliance events - 1 hour of participation = 1 SEU.
  • People can earn an unlimited number of SEUs working with CSTs, REPs and coaches. People can apply their initial training for this category. 
  • The next category is up to 15 SEUs at events outside the Scrum Alliance - like Agile conferences or other training.
  • People can also volunteer to provide non-compensated Scrum services for up to 15 SEUs.
  • The next bucket of up to 15 SEUs is independent learning - reading a book, preparing a presentation, watched a training video, writing a blog post or article, almost anything could apply.
  • The last category of up to 15 SEUs is other collaborative learning.

My subjective assessment is that gathering 70 SEUs isn’t too hard. So many activities qualify for credit that getting involved and continuing to learn in multiple ways seems very possible for most people.

Could the certification lack value?

Objectively, the market perceives relatively low value. A quick (unscientific) Monster.com search yielded 57 jobs for CSP compared to 1,432 for CSM and over 1,000 more for Product Owner. Further, while the number of CSPs continues to grow, the rate is nowhere near CSM or CSPO growth, which leads me to believe potentially qualified members may not perceive a lot of value either.

Subjectively, the value far exceeds the effort. For at least the short term, the CSP designation distinguishes people within the Scrum Alliance as high achievers. In the long run, CSPs will advance to team and enterprise coaching certifications and/or Certified Scrum Trainer. Beyond the extrinsic value, completing the Scrum professional certification provides intrinsic value - achieving the next level of personal mastery. 

Could the membership lack awareness?

Based on the people I meet in my CSM and CSPO courses, I observe very low awareness about the Scrum Alliance certification path and I make time to discuss what people can do next. In the past year, we collected additional qualitative and quantitative data that also shows relatively low awareness in the community. The upside - people ask a lot of questions about what to do next once they learn about CSP and the more advanced credentials.

Now What?

The Scrum Alliance community, particularly the certified trainers and coaches, as well as current CSPs, needs to increase CSP awareness and encourage more people to apply for CSP. We also need to reach out to organizations, particularly human resources, managers and other people who plan hiring and write job descriptions to explain the different credentials and the value of CSP (and the coaching designations).

And we need to offer help to navigate the journey. While the CSP FastPass program exists to provide extensive in-person and online training, one-on-one mentoring, group discussions, SEU tracking and application assistance, we continue to assist CSP candidates outside the program. If every trainer and coach helped one person a month in 2016, we could triple the number of new CSPs compared to 2015 and nearly double the total number of CSPs globally.

Let’s Go!