Keeping the batch size small

I am reading the book called Lean Startup by Eric Rides and one particular idea resonated well with my recent experience.

I noticed a pressure coming from around me to lengthen our 3 week long sprints (if only we could add one more week we could complete more valuable complex stories) and/or lengthen our release by adding one more sprint (we need more compelling release content). While different arguments are used to justify these calls - its all boiling down to attempts to increase the size of our our "production batch".

By now my intuition strongly points me to keep the batch size small. I know it will help to keep the level of waste down. However in the heist of debate I sometimes look for ways to describe why the small batch size is important, in simple layman terms.

Here is the story from the book that I found helpful.

The guy placed the bet with his daughters that it will be faster to fold 100 letters, place them in envelopes, seal and affix a post stamp by doing one envelope at a time (small batch size of 1) vs. folding 100 letters, then stuff 100 letters in envelopes, then seal 100 envelops, then affix 100 stamps (batch size of 100). The guy won the bet as the girls didn't at first realize the increased cost of dealing with larger batch size (e.g. keeping a stack of 100 envelopes from falling to the floor) and the cost of making a mistake when it gets magnified by the size of the batch (e.g. incorrectly folded 100 letters that don't fit into envelope - all 100 have to be redone instead of just one).

Falling back to the old habits

Just as I thought I've mastered truly agile approach to product management, I noticed myself slipping back to old bad practices: not delivering user value that can be validated by the end user at the end of the sprint.

My scrum team has recently delivered a large epic over several sprints. While I helped the team to break down the original large story (epic) into smaller stories that could fit into each sprint, I could not convince myself to demonstrate what the team has developed at the end of the first sprints to our customers. I doubted our team's work, while instrumental in laying the foundation for the ultimately delivered value, would generate enough interest or even appreciation among our end users.

On one hand, the ground work delivered at the early stages is just too low level (think of plumbing) for many end users, often lacking visible end user facing benefits. On the other hand, I was wondering if prematurely exposing incomplete value package would expose flaws in existing products customers may be unaware of and cause them to doubt what they have instead of appreciate what's coming.

I also noticed I am not alone facing the pressure to concel my yteam's progress, and skip the end of sprint demo. Other Product Owners sometimes tend to avoid showing incomplete features, hoping instead to delight customers and get rave reviews for well thought out, polished features shown to customers at the end of several sprints worth of effort.

Doesn't this push us back to the old dark age of waterfall?

What do you do to avoid falling into the same trap?

Collaborative Efforts Drive Innovative Results

Here is a blog (published at CA Communities web site) that includes the interview with none other than... me! :-)

http://community.ca.com/blogs/innovation/archive/2012/09/13/collaborative-efforts-drive-innovative-results.aspx

Product Launch (3 of 3): Quality vs. TTM

The not so trivial challenge of "secrecy vs. openness" is further complicated by the collision between our genuine desire to keep improving the quality of the new product at the expense of launch delay with the business critical time to market pressure. Inevitably executives/investors and sales want the product released sooner while the product team needs more time to add features and address any known defects.

While the differences between consumer and B2B markets affect product launch strategies, at the end of the day I have to agree with Eric Ries who advocates in his book ‘The Lean Startup’ - a methodology for continuously testing your assumptions as you bring new products and services to market, whether in a start up or in a traditional large software vendor company. A few chapters in and this is already resonating... The Lean Startup methodology is all about that - getting early versions of the product (what the author calls the ‘Minimum Viable Product’) into customers hands and empirically validating (or refuting) your assumptions about what they want, rather than spending months designing and building something that misses the mark...

I used to wonder how can the big companies (that seem to be taking calculated risk in introducing something really new to the market, like iPad for example) take the plunge and launch their products early enough, let alone earlier than expected. Just imagine new Windows OS came out earlier than planned simply because Microsoft wanted to get early customer validation… 

Product Launch (2 of 3): User Communities

I would like to share here one possible way to achieve some balance between non-piblic nature of pre-launch activities and much needed openness with as many existing or potential customers in order to validate product development progression toward desired release objective. This can be done with the help of a controlled user community.


As a Product Manager you can invite your customers, partners and employees from the front lines, who deal directly with your customers, to participate in the collaboration around new product release under development. Compared to traditional beta programs this approach does not have to be limited to a short span of time between code freeze and launch dates, and it offers access to broader more representative audience.

It's important that Product Managers control who gets admitted to this community. Restricting the membership to customers who accept the terms of your collaboration program can help set the expectations for both parties as well as offer you some protection for non-disclosure and other related legal liabilities stemming from using the product version that has not been officially released and is not yet formally supported by your company. In many cases existing beta programs can be leveraged with already available beta agreements providing all the necessary legal coverage needed.

An online user community is a great environment where the product team can collaborate with customers, partners and internal cross-functional teams around ongoing development, exchange ideas, feedback and comments, etc. 

As a Product Manager you will need to take the lead as a Community Manager, not only for administrative tasks, but more so to ensure steady membership growth and participation by members. Community Managers seed valuable content attracting more new members and stimulating healthy discussions and debates, while discouraging negative unproductive behaviors. Some valuable content that can be contributed includes posting questions from development team, surveys, sharing screen mockups, diagrams, invitations to webcasts for end of sprint demos and links to recorded presentations. If all goes well, over time, your community will mature and provide invaluable reality check for the product team, as well as early adopter reference platform.

Product Launch (1 of 3): Secrecy vs. Openness

Out of many Product Management domains I am particularly fascinated about one: figuring out the right time for launching a new major product release developed using Agile methodology.

How do we balance between secrecy and openness? What's the best way to harness the power of our customers' curiosity about upcoming product release with our desire to build the product in close collaboration with its ultimate users? We can't be secretive and open at the same time, or can we?

Agile software methodology calls for continuous collaboration with our customers, rigorous end of sprint validation and re-balancing of backlog priorities from sprint to sprint to achieve optimal alignment with the latest market needs. Yet, it's hard to resist the desire to follow the footsteps of proven winners like Apple who design and develop their products under seemingly impenetrable clout of secrecy. 


So how can we as Product Managers strike the right balance between open collaborative approach toward our customers and desire to deliver that magic moment of unveiling groundbreaking, amazing, new product?

The cars with missing wheels

In pursuit of breaking down a user story to make it fit within a sprint, scrum teams are often challenged to find the right way to do this. At the end of the day a story should still deliver a verifiable value for the customer and if this cannot be established we have a tell tail sign of trouble.

Consider a user story asking for a car to have wheels so it can travel over a paved road. Reducing the scope of work by breaking this story into four stories, one for each wheel, is one sure way to release a car with a missing wheel. A better approach is to break out a story for alloyed wheels or plastic covers to give a nicer look to the wheels, but ensure the car either has wheels or not at all.

As Product Owners we should help our teams to decompose user stories the right way. We know that those breakout stories (that lessen the scope and size of the original story) left for future sprint(s) will live their own lives on the release backlog. They may be trumped by other stories competing for our time and attention and ultimately stay behind and not make it into a released product.

Just say ‘No’ to the cars with missing wheels!