Steve Neiderhauser

Musings about Strategy, Marketing, and Product Management

Should people working in software layers have a theme song

 

A story needs to be valuable. We don't care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.

This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we're serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it "right"); but a full database layer (for example) has little value to the customer if there's no presentation layer.

― Bill Wake

 

Riffing on Wake’s cake metaphor, I wondered if people who are working in layers could be playfully coaxed to those tasty vertical slices through a theme song. Perhaps we play the song at sprint demos. You know, to fill up the space where the team normal shows working software.

Try eating only the frosting on a cake and see how quickly you develop a sweetly sick feeling. So I felt that the sweetly sick song MacArthur Park would be apropos for all layer lovers.

Listen to these lyrics: 

MacArthur's Park is melting in the dark

All the sweet, green icing flowing down

Someone left the cake out in the rain

 

I don't think that I can take it

'Cause it took so long to bake it

And I’ll never have that recipe again, oh no

 

This is a 60s song so let me translate the lyrics to Agile:

 

The customer’s love for your product is melting

During integration your sweet, sweet tests flow from green to red 

When a market storm rolls up on us, we couldn’t deliver the cake fast enough 

 

The cake’s features are no longer valuable to our customers, and we don’t think we can take it 

Takes a long time to bake a whole new cake

We missed a major market opportunity, and we’ll never have that chance again, oh no


PS. Note to self. Never again read Mike Cohn's book User Stories Applied while watching American Idol.

April 28, 2013 in Product Management | Permalink | Comments (0)

ScrumMaster Checklist

If you're a ScrumMaster and have ever wondered if you could be doing more during a sprint to help your team, you may consider Michael James checklist for ScrumMasters.

April 24, 2013 in Product Management | Permalink | Comments (0)

Agile Product Owner Workshop in 15 Minutes

A concise and visual description of the Agile product owner role.

April 20, 2013 in Product Management | Permalink | Comments (0)

Distributed Scrum Primer

Pete Deemer created the Distributed Scrum Primer, the primer shows distributed teams how to practice Scrum.

One key is communication. And with disturbed teams poor communication places a larger tax on the software project. Why? Because if you spend more time trying to transmit an idea, you spend less time creating working software.

Pete describes a richness scale. The higher a communication method is on the scale, the greater the communication value.

 

NewImage 

 

April 19, 2013 in Project Management | Permalink | Comments (0) | TrackBack (0)

Scrum Patterns

Jeff Sutherland describes two Scrum patterns.

"Yesterday's Weather" is powerful because it limits planning time and helps the team finish their work and achieve their goal.

"Yesterday's Weather," how does the pattern work? When the team is planning for the next sprint, simply look at the number of story points completed in the last sprint and pull in that amount of work.

April 10, 2013 in Product Management | Permalink | Comments (0)

What is Marketecture

Cutter explains Marketecture in this blog post.

My favorite tip? Create a compelling story that shows the architecture's benefits.

April 10, 2013 in Product Management | Permalink | Comments (0)

Sprint Demo as Market Research Method

Roman Pichler describes how to put on a product demo that elicits market research from users and stakeholders.

If the customer provides sweetly faked praise, "Those drop down menus look wonderful," you may want to ask some powerful questions.

What changes would you like to see?

What key features are missing?

Does our working software still align with market conditions?

April 10, 2013 in Product Management | Permalink | Comments (0)

The Brilliance of Blake Snyder

Like the rays of the sun, the more condensed the words, the more powerful they are.

Blake Snyder shines in Chapter 3 of his book Save the Cat Strikes Back like a super nova. In this one chapter he lays out the three acts, describing them as Thesis, Antithesis, and Synthesis, in a clear, concise, and clever way that could spring only from Blake's genius.

The rivers of Blake's understanding flow together in this chapter, gifting you with the wisdom of story structure. 

Go ahead! Read the chapter, watch the movies, write your story.

April 02, 2013 in Creative | Permalink | Comments (0)

Kano Survey

Ever wonder how customers feel about your product. Knockout Surveys gives you the power to perform Kano Analysis.

March 29, 2013 in Product Management | Permalink | Comments (0)

How to Run a Retrospective using Constellations

Luis Concalves has written an article about a team exercise call "Constellation."

Using games or exercises to help teams reach higher levels of performance is a key part of an Agile leader's job. Leaders also let the system reveal itself.

It is in this act alone, where the team observes the system, that the largest change often occurs.

March 27, 2013 in Product Management | Permalink | Comments (0)

What's The Future of Business

In What's the Future of Business, author Brian Solis makes the case that designing remarkable customer experiences is key to avoiding digital darwinism.

"Experience is everything now." -- Brian Solis

Although, this is a book about more than user experience design. Brian writes about innovation, brand, the hero's journey, and Google's ZMOT.

And he does it in an engaging and visual fashion. He uses diagrams to enlighten readers, and cartoons from Gapingvoid are sprinkled throughout the book like powdered sugar. 

Given the rate of technology change and its disruptive nature, Brian uses case studies to show concepts in action.

I enjoyed the Burberry case story. Here's a company that has been around since 1856. To survive for 150 years in the competitive retail space requires constant innovation. Angela Ahrendts, Burberry CEO, eloquently captures the company's brand vision.
 
"You have to be totally connected with everyone who touches your brand."
 
Working with Salesforce, Angela created a Social Enterprise she calls "Burberry world."
 
Burberry Heritage + Connected Customer + Visions for Brand Embrace + Culture + Technology = Burberry World.
 
Why is Burberry World important? Seventy percent of the company's workforce is under 30. And many of its new customers represent younger demographics. They are the digital natives, the people who grew up with mobile and social media. They expect to communicate in this fashion, with this language.
 
Ahrendts offers advice to any company wishing to remain relevant. "To any CEO who's skeptical at all, you have… you have to create a social enterprise today. You have to be connected with everyone who touches your brand. If you don't do that, I don't know what your business model is in five years."
 
Not every company has a leader such as Angela Ahrendts. To lead a similar revolution, perhaps you will go on the hero's journey and be challenged by threshold guardians. These guardians spring to life to test you, to see if you have the courage to move past them and to higher levels of awareness.
 
In fact, the author shows you how to use "The Hero's Journey" to bring about change in your company and create great customer experiences. 

March 25, 2013 in Product Management | Permalink | Comments (0)

Four Principles of Low-Risk Software Releases

Jez Humble, Continuous Delivery expert, tells us how to release software into the wild. His four keys to doing it right:

  • Low-risk releases are incremental
  • Decouple deployment and release
  • Focus on reducing batch size
  • Optimize for resilience

March 12, 2013 | Permalink | Comments (0)

Sprint Demo as an Agile Market Research Method

Roman Pichler enlightens us about the sprint demo -- Just what is the best way to orchestrate a demo. Hint. Make sure you invite the right people.

You want more than the Scrum team, the team that worked on the product. You want actual stakeholders. You want real customers.

March 04, 2013 in Product Management | Permalink | Comments (0)

Minimum Viable Product

I've worked with some product people who find it challenging to think in terms of a minimum viable product. The minimum that provides value to a customer and lets you collect valuable feedback.
 
Brad Montgomery explains that we may want to replace "Minimum Viable Product" with the concept of a "Minimum Working Thing." Brad's advice in a nutshell:
 
"Build something really small that works, and let your customers start using it. Pay close attention to what they do and how they use your minimum working thing. They'll guide you the rest of the way."

February 18, 2013 in Product Management | Permalink | Comments (0)

Emphatic Word Order

Roy Peter Clark Clark provides eight strategies that can strengthen your writing. One tool is emphatic word order. Placing a word at the end of a sentence will emphasis the word more than hiding the word in the middle of a winding sentence.

Here's an eloquent description of the tool.

“There is sometimes an extraordinary force in some particular word, which, if it be placed in no very conspicuous position in the middle part of a sentence, is likely to escape the attention of the hearer and to be obscured by the words surrounding it; but if it be put at the end of the sentence is urged upon the reader’s sense and imprinted on his mind.”

February 01, 2013 in Creative | Permalink | Comments (0)

Agile Estimating

Determining the size of an Agile project can be a bit of a paradox. On one hand, planning poker is a remarkable tool, yet when there are hundreds of stories on the backlog it's too time consuming to determine the size of a project. That's where affinity estimating joins the planning party. 

Even with Agile, you need to spend some time and effort to determine the project size. I've created the following guidelines for estimating Agile projects. 

  • Product owner provides clear vision about product to people who will give estimates.  A product vision board will help convey the big picture.
  • If needed, product owner could create story board to show the product's workflow.
  • Product owner may already have high-level product backlog or can work with team to create one. A user story workshop is one way to create stories with the team.
  • Team will use affinity estimating to estimate a large backlog (affinity estimates work best with 20 or more stories). Teams that have been together a long time and are familiar with product will provide better estimates.
  • The goal of affinity estimating is to provide a rough estimate of a project's size. Will the project take 3 months, 6 months, a year?
  • Team reviews features and asks, do these features need new infrastructure or can they work with our existing framework? In most cases, new architectures will increase risk and size of project.
  • Estimates larger than a month should be broken down into smaller stories.  The estimation error on a month is too large to risk.
I suggest using rolling wave planning and creating a product roadmap of only three to six months. Anything longer and you are creating WIP. You'll lose the advantage of replacing projects with features the customers really want. And that's what Agile portfolio management is all about. 

January 30, 2013 in Product Management | Permalink | Comments (0)

When You're Agile, You Get Lean

Charlie Rudd has written a world class paper showing how Agile is based on Lean principles.

Agile does a great job of reducing work in progress. There are no 100 page requirements documents. Instead we embrace user stories -- or just enough, just in time requirements.

January 26, 2013 in Product Management | Permalink | Comments (0)

»

About

Popular Posts

  • What Makes a Good CIO
  • The On-Demand Brand
  • Presentation Secrets of Steve Jobs
  • How to Think like Leonardo
  • Proof -- Marketing's Rocket Fuel
  • Hooked - How to open your story
  • Product Platform Performs for Google
  • Stealing Fire from the Gods
Add me to your TypePad People list
Subscribe to this blog's feed

Blogs

  • Silicon Valley Product Group
  • Dan Pink
  • Moving from Me to We
  • Tom Peters
  • Seth Godin
  • Church of the Customer

Categories

  • Creative
  • Film
  • Marketing
  • Music
  • Product Management
  • Project Management
  • Science
  • Sports
  • Strategy
  • Web/Tech

Archives

  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012