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!

Don't lose control of your backlog

Have you come across a Technical Story Syndrome yet?

My product team is new to Agile, and in the early going developers fell in love with the formal user story definition. So much that everything they embarked on had to be first defined in this format. Before long my backlog filled up with stories literally like the one below:

  "As an XYZ developer, I want the benefit of a standardized API for storing (caching) items in the DC, as well as transferring (syncing) required items between the DA & DC, so we can improve development time by reducing the number of specialized APIs required."

For a typical Product Owner with background in Product Management this simply would not make sense, whether (s)he will care to admit it or not. An even better test, is showing this story to your customers. See if this interests them. Would they pay even a dollar for this feature? If not that's a sure sign we are dealing with the so-called technical story.

Developers will often insist that these technical stories help to make the product better. The problem with these stories however is that they cannot be ranked by the Product Owner in relation to other stories on the backlog, and if they cannot be ranked they cannot be ever worked on.

One way to deal with this is recognize the need for some proportion of team's capacity to be allocated to technical debt and simply include these technical stories there. In the beginning of the project this may involve some technical stories for building the plumbing, or the foundation of the product, later on the focus may shift to refactoring, performance optimization and defect resolution.

In my case I've created one technical debt story for each sprint, moved the technical stories underneath it, asked the team to budget for up to half of the available sprint capacity, and delegated to the team the decision on what needs to be tackled as part of this story (plumbing, refactoring, optimization, defects) and what has to wait till future sprint. Of course this is just a general guidance.

Once I placed a technical debt story at the top of the list, I was able to easily navigate my backlog and rank all the user-facing stories. Back in control I am!

In pursuit of the user story purity

As Product Managers we are accustomed to answering calls for better requirements, or better-written user stories as they are known in the world of Agile software development. It’s hard to argue with the logic behind this. Scrum teams can more efficiently groom their backlogs, decompose and size user stories and ultimately come up with better fitting winning solutions that keep our customers happy and revenue flowing. 

Let’s take a look at one approach meant to raise the bar with this. A scrum team was instructed to re-visit stories on its backlog using the following WHO, WHAT, WHY and HOW framework.

·      “WHO” … this speaks about the importance of defining the end user for the requested capability.

·      “WHAT” … the approach argues it’s important to define WHAT in terms that all scrum team members understand.

·      “WHY” … if you don’t frame the WHAT in a WHY, different scrum team members will each interpret a different reason, which will lead to very different solution approaches… “As a car operator I want a cup holder in my car so that I can store my loose change in it for tolls” is different than “I want a cup holder in my car so that I can drink my beer while driving”.

·      “HOW” … should simply stay out of user story definition, i.e. left to the team.

I have to say some of the discussions around user story descriptions were quite enlightening as they helped everyone on the team better understand the need and the scope of what’s requested. On the flip side, I've also encountered what seemed like recursive looping, where the scrum team having quickly agreed on WHO, endlessly circled between WHAT and WHY in the search of ultimate answer.

Take for example this wild goose chase:

• As a middle-aged daily commute driver I want a cup holder in my car so that I keep spare change there to pay for my tolls.
• As a middle-aged daily commute driver I want easily accessible place to store change in my car so that I don't scramble at the tollbooth.
• As a middle-aged daily commute driver I want a convenient, stress-free way to pay for my tolls so that I can enjoy my ride
• As a middle-aged daily commute driver I want to enjoy my ride because the life is short

… You can see where this can lead J 

At the end of the day PO defines the requirement in the form of Agile user story, based on his/her knowledge of the market and application domain. Time boxing these discussions is all it takes to ensure your team spends just enough time to understand well enough what needs to be done to be successful.

Roundtable with Ken Schwaber

Last week I attended a roundtable and presentation by Ken Schwaber, one of the two original Scrum process developers and signatory to the Agile Manifesto. He reminds me of Steve Jobs – same black sweater with round neck, grey hair sprinkled here and there… somehow this image adds to projected credibility and I wonder if Ken is aware of this.

A few takeaways...

1) Scrum team is all about the team, not the individual. The way Ken drove this point across brought smile to my face however - he essentially appealed to the virtues of socialism, how irrespectively of the talent and abilities everyone should be rewarded equally. So, everything I've heard in my childhood was not that bad after all, just Agile way of doing things?! hehe… I just can’t imagine this philosophy really taking roots in the American culture.

2) I found Ken’s way of talking to the audience about Product Owners (POs) refreshing, particularly in the room filled mostly with developers. For example, Ken points out how scrum teams he interviews often complain that POs don’t write good enough user stories for them. Ken concedes that writing user stories is not necessarily the biggest value POs bring to the table. He states it’s the team who should write, or rewrite if necessary, the story, as long as it still represents what PO believes is a market need. POs should maintain focus on bringing the voice of the customer to the table. They define release vision for the team and ensure backlog prioritization reflects it, often making high impact tradeoffs based on the information available to them at the time.

3) Finally, Ken is questioning the whole notion of scrum team’s commitment to deliver a given number of user stories during sprint planning sessions. He reasons that all too often people interpret this commitment as a guarantee to deliver… irrespectively of quality, which takes us all the way back to the world of waterfall planning. What Agile strives to ultimately achieve in software development is to take out the false idea of being able to plan the unknown – the time it takes to innovate. Ken suggests replacing the term “commitment” with “forecasting”. Contrast: “Team Jedi commits to deliver user stories X and Y” vs. “Team Jedi forecasts to be able to deliver user stories X and Y”. In my experience I found teams, particularly recently formed with limited history of working together, tend to err on the conservative side of committing to fewer stories precisely because of the fear of not delivering on promise. The notion of forecasting may help free us from that mental cushion we learned to use over the years, to pad our effort stimates in traditional waterfall project planning.

All in all, the presentation was educational and inspiring. Thank you, Ken. It was great to hear your perspective on how Scrum is being adopted by other teams, and see you striving to keep abreast of our changing world and how people embrace the change. After all, as you suggest - Scrum is really about understanding and managing the change!

P.S. I look forward to reading my signed copy of Ken’s recently published “Software in 30 days” book.

The guilt of not doing it all

I recently had a privilege of spending a few days with a large group of highly successful, talented managers and I asked them one question: "How do they deal with the pressure or even a certain sense of guilt of leaving something undone when they realize that certain things on their plate are not as important as something else?" Below I share some of the answers I collected along my own ideas inspired by this encounter.

• Minimize time spent in reactive mode
• Schedule time on your calendar to work in reactive mode, specifically to work with email. Communication tools such as smartphone, instant messaging and email are the most common sources of reactive mode of operation, so restrict times when you allow yourself to access and use these tools.
• Try to avoid sending emails off hours. This will only encourage others to operate and expect you to work in reactive mode.
• Prioritize, prioritize, prioritize. 
• Maintain a list of priorities on a regular basis
• Focus on what you can finish in a day
• Force yourself not to jump to action right away when tasks appear on your plate, artificially push them off, let them either earn the right to be worked on or gradually fade off your list.
• Recognize false urgency by examining and understanding who and in what way will be impacted if you don't do this
• Take a risk, learn to say NO
• Just because someone invites you to a meeting you don't have to accept. Decline and see what happens.
• If you find yourself in a conference call that goes nowhere, your contribution is minimal/questionable, and you are multi-tasking on something else, excuse yourself and hang up.
• 2-5 minutes before the end of a scheduled conference call, remind participants that time is running out and hang up when the time expires. 
• Delegate whenever you can, even if you don't have direct reports
• Learn to recognize which tasks can be matched with someone in your organization who can accomplish them.
• For repetitive things that routinely get onto your plate, seek to adjust the process
• Share with your leader, manager, mentor. Be open and honest. Seek advice.

Difficult customers?

Not letting occasional unconstructive snaps from our customers rattle us and keeping communication channel open (friendly, forgiving, etc.) in the grand scheme of things will serve us best.

For starters what we hear will broaden our horizon and may teach us new things or let us connect the dots in our head in a new way.

Not everything customers ask us to do is best for our product. Listening to customers doesn’t have to automatically translate to action. It's all about acquiring as many data points as we can, even if these are low quality data points. ...just keep fishing.

Finally, it's not uncommon to see highly critical, skeptical customers eventually turn into most vocal and passionate advocates of our products, thanks to not giving up on them at some point.

Realize how others perceive you

Considering we don’t really change personality-wise over the years, it comes as no surprise that our communication style often remains essentially the same as we grow in our careers. I recently realized however that the role we play in the organization has a great impact on how people interpret our messaging. Consider how the same brisk but honest statement from junior engineer “we have to do better, our UI is too clumsy” would come across very differently from a senior manager...

Have you noticed how as people move up the organizational ladder their written communications become sparser, particularly when addressed to multiple recipients, ultimately disappearing completely or becoming outsourced to professional aids? Could this be driven by the fear of being misinterpreted?

Are we there yet !?!

With almost any sufficiently important project executives (or investors) want to keep a close eye on the progress made. As the project nears completion and the product launch looms ahead tensions may raise as uncertainty of successful outcome builds. See if you recognize this inquiry Product Managers may be responding to near the project end:

"As the owner of the backlog, how do you evaluate the priority? Do you have things such as must have vs wish for? Each time I have released a new product to market, there are always more things to do...it's a universal constant.

What I am looking for is a report that tells me how much of the backlog is customer driven/validated (required to be competitive in the market) vs. what folks desire. If we had a report that could provide insight into the health of the offering....not sure what metrics I would want to see, but I am sure I would like to know if the epics we started out to build, are creating the value we envisioned (i.e are market ready)."

 
In traditional requirements management, requirements are often categorized at 2-3 levels (e.g. Must/Important/Wish or High/Medium/Low). In Agile we are taught to rank them (user stories) from 1 to N, so if you have say 100 requirements ranked from 1 to 100, you may have only 10 show-stoppers - requirements that you believe absolutely prevent you from launching your product, or you may have 80 show-stoppers. In one case you are very close to be able to confidently launch your product, in another case you are probably quite stressed out.

So how do you know when you are truly ready to launch? Are you getting closer to that point, seem to be standing still or are actually drifting away?

Agile forces us to worry less about "launch readiness" in favor of most efficient utilization of available resources. In other words, as long as our teams (fixed resources) always focus on top priority (as defined and adjusted by Product Owners in timely fashion) issues there is nothing we can do... other than recognizing when we are not ready to launch.

There lies one challenge many Agile projects have to deal with: when the launch date is "artificially" fixed in advance the product team is like an airplane crew forced to land irrespectively whether the landing gear is down or not, without regard to weather and airstrip conditions. Should the crew be able to decide when is the right moment to touchdown, or in response to 1st class passengers "Are we there?" just strap on the seat belts and hold tight?

So in recognition of the need for transparency, how can we indeed bring more clarity to our progress on the final approach, without causing unfounded panic in the main cabin? :-)