Product management professionals are always looking for a way to get to market faster.  One common-sense way to do this is to build less prior to market launch.  So what’s the least you can possibly build?

Minimum Viable Product.

Except, it’s not that simple.

In the lean startup world, minimum viable product is the smallest possible product built to test a hypothesis and to achieve “validated learning.”  If the experiment is to test conversion rate on a landing page, the landing page would qualify as an MVP.   But no-one is paying you for a landing page.  As a commercial product, a landing page is not viable.  Marty Cagan writes:

I refer to that that as an “MVP Test” so that people don’t confuse an experiment with a product.

A more “viable” interpretation of MVP is a very narrow product that solves a specific problem really really well.  An example I think of in this category is Dropbox.  Dropbox solves the problem of sharing files across machines really well, and is viable commercially as a product consumers will purchase, but requires additional features to fit into the enterprise.  Dropbox launched Dropbox for Business to address these needs.

What about Minimum Marketable Featureset?

How well do you have to solve the problems you’ve identified?  This is a solution space question, not as relevant for the problem space.

An interpretation of MVP I’ve seen frequently is the smallest collection of features to satisfy the happy path.  This often is enough to demonstrate the product to prospects and to install it, but may lack some of the administrative capabilities and exception handling that a client might expect in a robust product.

This is a challenge entering an established space within enterprise software.  Enterprise buyers frequently purchase from a feature checklist known as a Request For Proposal (RFP).  RFPs are written to ensure the enterprise addresses all the needs of all the stakeholders in the purchase.  How will your offering stack up if you respond to an RFP with the limited set of features in your narrow MVP?

It’s difficult to identify and isolate market problems that people will pay to have solved, but that’s not all there is to product management.  Thinking of the solution space, they’ll only pay you if the product you offer solves enough of their problem(s), and solves them well enough.

People don’t want to buy a product that doesn’t solve their problem.  So should you talk about where your product is going, or what it does now?

Another way of asking is: how much of the problem do you need to solve, and how well, for that solution to qualify as “enough” to your buyer?  Perhaps the answer to this question is what defines “viable.”

How much is Minimum in the Enterprise?

As Eric Reis states, “probably much more minimum than you think!”  Jesus Rodriguez put this differently: “The Enterprise Minimum Viable Product: Focus on Viable Instead of Minimum.”

If at all possible, create your own product category.   If you’re going into a crowded space with existing vendors, there are RFPs and expectations.  If you’re creating the first widget of its kind, while there are always substitutes, there aren’t as many expectations about what your widget will do.  You can define what that entire kind of product does.

Most companies can’t or won’t do this.

If you’re going to market in an established space, you may be able to sell a differentiated product to early adopters, without adding many of the frills.  But to gain market share among the early majority, you’ll need enough features that the early adopters will provide enthusiastic recommendations of your product, and you’ll need enough functionality to meet expectations about the “table stakes” features–things a product in that category couldn’t possibly not have.

Minimally Robust Product

I perceive a continuum.  On one hand, the mere ability to conduct an experiment is the least possible “product” one could build, but is so minimal that it’s not sold or bought.  On the opposite extreme, is the product with every possible feature and is fully “done” (impossible, of course).

How Much Minimum Is Viable

In a mature product space, to appeal to early and late majority buyers and to achieve satisfaction, I propose that you must reach past “minimum marketable” and “minimum viable” and reach what I call “minimally robust.”  Criteria for this might include:

  • It has to solve key problems, well.
  • It must meet the basic needs that buyers won’t voice, because they’d never assume a product wouldn’t solve them.
  • It must be stable, implementable and administerable.

Identifying the features that meet those criteria is the fun part!  It’s different in every product category.  You’ll need to talk to people.

Where to Go from Here?

Once you have a product in market, how do you prioritize what to build next?  Here are a few questions to ponder:

  1. What features will impact the highest percentage of your product’s client base?
  2. What features will help your implementations and support teams from an operational standpoint?
  3. What features might help you solidify a narrower path through your product, that can address a more granluar problem that people will pay to solve?
  4. Are the features your clients are asking for all over the map or targeted in certain area(s)?
  5. Are the features your clients are asking for validating your vision for the product or suggesting a different direction?

There are plenty of questions to think about, but the first one to solve is how deep and wide you need to go before putting a product in a paying client’s hands.

Share this:
facebooktwittergoogle_plusredditpinterestlinkedinmail


We product people seem to really like the canvas!

In the circles I populate, there are three canvases which have gained some traction.  Wait, make that four.

In the modern software development movement, the business model canvas was the forerunner, from the work of Alexander Osterwalder on business model innovation in 2008.  His work suggested that by collecting the nine critical elements of a business model on one page, it would be easy to consider, challenge, modify and iterate on those business models in order to find new ways of delivering value.

Delivering value and innovating is what product managers do, so in our community there have now been a few spin-offs of the original canvas.  Let’s see if we can decipher each flavor from the other:

  1. Business Model Canvas – The original, from Osterwalder’s work.  Intended for use at any type of enterprise.
  2. Lean Product Canvas – Adapted for Lean Startup.  The unique elements on this one are Unfair Advantage, Problem and Solution.
  3. Product Vision Board – Roman Pichler’s vision board for scrum product owners captures the vision statement, target group, needs, key product features, and value.  Pichler offers an extended version of this canvas to capture more of the product management scope of responsibility, which contains competition, channels and price.
    1. Pichler also offers a more detailed, in-the-weeds Product Canvaswhich emphasizes individual epics / user stories and Agile UX artifacts such as user flows and wireframes, in order to give a more complete, low-level vision of the product. Although its name resembles several of the others listed here, its focus is at a different level.
  4. Product Canvas – Shardul Mehta, the Street Smart Product Manager, offers this canvas adapted from the business model canvas which considers things like Existing Alternatives, Key Stakeholders, Early Adopter, and adds back in the Key Partners and Resources that Lean Product Canvas took out.

Each offers a modified set of factors to depict, but provides a way to review them in a single-page overview for easy adaptation and consumption.  Since the business model canvas is licensed under Creative Commons, we can expect to see more of these over time as people put more thought into what works for their organization, and some percentage of those people make their adaptations available.

Not to be outdone, Applied Frameworks has just released the Applied Frameworks Product Scorecard.  This is a version of the traditional product scorecard–which usually shows a number of metrics with red/yellow/green indicators for overall performance over a period of time–recast to visually resemble the business model canvas!  This one might be useful for annual planning, offering a little more room than is typically available on product scorecard templates.

Which one is the best fit for you?  Let us know in the comments!

 

 

Share this:
facebooktwittergoogle_plusredditpinterestlinkedinmail

What is Interaction Design?

Smartphone screens are small.  Very small.

Because they’re small, there’s no room for unnecessary information.  For this reason, interaction design–the design of exactly what is necessary for a user to flow through the system to accomplish a goal–is of primary importance in mobile. Because many mobile consumer applications also have web components, the discipline has also bled over to the consumer web.

Enterprise software?  You’re not out of the woods either.  Since your product’s user base are all users of consumer products and mobile apps, they’re starting to expect the same targeted experiences in their enterprise products.

It’s tough to compete out there in the world of mobile apps.  Last I counted, there were 254,129 coupon apps available in the app store.  (more or less)  Why would someone choose yours?

UX Diagram

 

Source: http://www.flickr.com/photos/pveugen/3182820590/

Marty Cagan wrote this week to suggest that the biggest risk to a product team isn’t value proposition or pricing, but rather, it is the design of your proposed solution.  Traditional product management focuses on the problem space, defining product requirements and focusing on P&L, but to be frank, this is one of the biggest flaws with traditional product management.  Traditional product management doesn’t focus enough on the solution space.

Product owners deal in the solution space.  They generally spend time decomposing stories, ensuring proper implementation and ensuring the next most important items are at the top and ready.  They aren’t trained in interaction design either!

Cagan has long argued that many first attempts won’t be successful and that iteration is mandatory, so iteration should therefore be accelerated.  The definition of “work” is important here.  Many apps will do a job, but users will over time gravitate to the ones that provide the best interaction design.  Just ask Myspace.

Invest in Design

Cagan’s latest post encourages investing in the design of the solution early:

I argue the major risk facing most efforts is solution risk.  Discovering a solution that is compelling to customers.  A solution that your customers will choose to buy and use……

Look, if you can discover a solution that your customers love, then you can tackle the risks of monetization and scale.  However, without that solution, the rest of your work is very likely going to be wasted.

Cagan’s post has been in my head since last Friday.  Then this morning, I observed that venture capitalist Mark Suster wrote thoughtfully about the importance of user testing in “How to Avoid a Common Product Mistake Many Teams Make“:

The single biggest mistake most product teams make is building technology for what they believe the user would want rather than what the actual end-user needs……We live in world of choice and yet paradoxically as humans we generally want fewer choices. We want less complexity…….don’t take my word for it. Do actual usability testing and make sure to include users not from your ordinary circle of friends or similar cohort.

What you assumed was “novice functionality” will likely be too hard.

Enterprises have for years been insulated by forcing employees to use clunky phones with full keyboards and phones with a Start button.  With the increase in bring-your-own-device, however, enterprise software is beginning to fall under the same pressure that has led to the disruption of many consumer applications.  Those just entering the workforce won’t tolerate poorly designed software, because they’ve grown up around great user experience.

They’ll replace your bloatware in a heartbeat.

Stop Making Users Explore

I was excited to read this article today advocating that designers “Stop Making Users Explore” — rather, design so that the user’s goal is easily accomplished without having to actively learn your product (emphasis added):

The fact is, people in big companies are forced to work with dozens of complicated products every single day. The introduction of a new, complicated product does not instill in them the desire to spend a lot of their day exploring it. It tends to make them sigh resignedly and figure out if there is some way to avoid learning the new system until it goes away and is replaced by something else.

The only way to make a product that people at work want to use is to make a product that is so obvious and easy to operate that they don’t feel like they have to explore it. They can just jump in, share a document, send an email, or do whatever task it is that they wanted to do originally. They shouldn’t have to explore anything to do their jobs.

Remember – as Steve Jobs said:

Design is not just what it looks like and feels like. Design is how it works.

If you’re lucky enough to have a product owner, be sure someone’s minding the UX store.

Share this:
facebooktwittergoogle_plusredditpinterestlinkedinmail

Can a Product Roadmap De-Emphasize Dates?

In a recent post, I wrote about Selling roadmap items.  To communicate “what’s coming” with Sales, Product uses an internal roadmap–and if not carefully formatted, this document may convey more certainty than is accurate.  One of the strategies I suggested is to publish a product roadmap without dates:

A tactic I’ve seen some agile shops apply is to omit all dates from roadmaps.  Instead of a roadmap, they show a prioritized high level feature backlog, which includes more detail for immediate features and less detail for more distant future features.  Some may even include dates on the top item or two which may be at a detailed level of planning.  This eases the conversations around items beyond the short term (about which there are the fewest “unknowns”).

This week, Simon Cast of ProductTank and MindTheProduct wrote about this suggestion at length, in a post titled Roadmapping Without Dates.  In this post, Simon describes why his product roadmap software, called ProdPad, omits all dates from product roadmaps.  The rationale is pretty solid and echoes the theme of the suggestion I’d posted.

Simon explains that too much granularity in the roadmap makes a document more of a project plan than a product roadmap:

The granularity turned out to make it very hard to manage. Not because of complicated UX but because, suddenly, you are managing a single idea on a day to day basis, shifting them around changing their “delivery length”. It was very Gantt-like and more about project management than product management.

He describes in a nutshell the primary problem with including dates in a roadmap, especially dates that are far out in the future:

As Martin pointed out, the point at which a specific date is added to a roadmap is the point at which everyone but the product manager believes the item in question will be delivered. Too often,it doesn’t matter how you caveat the date, it becomes gospel. Suddenly, you are judged on whether you meet the entirely fictitious dates. The judgement, unfairly, doesn’t take into account changing priorities, the cyclical nature of product management, or the fact that it is non-linear.

A better Roadmap Format

Simon shared an image of the roadmap used in ProdPad, and I like it a lot.  It resonates with a problem I’ve been wrestling with: I believe that a roadmap format which shows no difference in likelyhood of early items vs. late items is often responsible for mistrust and miscommunication between product development and sales & marketing.  Agile organizations deliver value by being able to shift priorities as more learning takes place.  Why not embrace the flexibility?

I’ve also been working on a roadmap concept, a sketch of which I’ve included below.  I have been churning over several objectives which I tried to address in this concept:

  1. Certainty in the immediate term.
  2. Progressively lower degree of certainty into the future
  3. Phrasing to encourage discovery around problems and features imagined for later development.
  4. Inclusion of proper language to be used with prospects and clients around the features.

The following sketch was developed with those objectives, and with input from a product roadmap I spotted during a tour of Daxko’s Atlanta offices and with a few words from Will Sansbury:

Roadmap idea (1)

Some thoughts about my sketch:

  • First, you’ll see that this is depicted as more of a backlog than a roadmap.  It’s easy to shift the dividers between segments up or down quite easily, which is especially useful when managing a portfolio of products and having to shift capacity across product roadmaps.
  • The fact that the order is descending by priority is important.  This means that as people scan down the list, if you’ve done a good job of ordering the most important things first, many of the “most important things” will resonate highly.  If items aren’t getting traction with prospects, perhaps they should be de-prioritized.
  • The answer to prospects’ questions of “When?” for items down the line should be met with discussion.  How important is it to the prospect?  This might be a great conversation for the product manager.  Perhaps it’s more important than understood.  Perhaps it’s an item that can be raised in priority should a deal be feasible.  This should be a trigger point for a conversation, NOT a question that should be dreaded or dodged.
  • Items planned for the current quarter (Q) are planned, measured and sized.  This suggests confidence that what’s planned can actually be achieved.  Since priorities in the short term should NOT drastically change, language around these features can reflect certainty.
  • Items in the following quarter (Q+1) are thought through to a good level of detail, but they aren’t measured or sized.  Language around these items should reflect likelyhood, with the caveat that priorities may change.
  • Finally, items beyond next quarter (Q+2 and beyond) are written with less clarity, and also not sized or measured. Here the language suggests these are under consideration, and prompts the internal consumer to probe into that area with the prospect or client.  Items beyond next quarter often ARE guesses which will become more confident with more input, so it makes sense to provoke that input earlier rather than later.

What do you think?  Can this kind of tool help to get product and sales working on the same page?  What would you add or remove?

Share this:
facebooktwittergoogle_plusredditpinterestlinkedinmail

Roadmap

Are you selling slots on your roadmap?

One of the problems B2B software companies struggle with is the proper application of a product roadmap. Sales teams want to know what’s coming up in future releases, so they can appeal to customer problems the product will solve in future releases.  This form of “selling the future” carries the risk of enticing the customer with a feature that never arrives, or arrives later than expected.  Both of these negative outcomes can naturally cause problems for the company after the deal is signed.

Some teams sell only features in (and appeal to problems solved by) the current version.  This mitigates the risk of false promises, but puts the company at a disadvantage to competitors who have (or are willing to talk about) more features.  Once a product attracts competition, and in particular once the market is mature enough that companies submit detailed RFPs, it becomes more and more difficult to sell only what’s currently available.

False Promises

False promises are common.  Product management presents a roadmap showing features along an estimated timeline, but this looks suspiciously like a schedule of commitments without proper context.  And any account manager who shows the roadmap in document format is at risk of presenting it without context.

In agile software organizations, a significant dichotomy exists.  On one hand, agility supports the ability to respond to opportunity.  Responding to opportunity frequently results in re-prioritizing the roadmap, which by definition delays whatever was previously in that item’s place in line.  On the other hand, many sales organizations want as much of a committed feature schedule as possible, so they can sell deals that include language that delivers revenue at the time of feature delivery.  Why not wait until the features come out?  One of the primary reasons is that this locks the customer in to a solution now, which establishes switching costs should the customer consider moving elsewhere later.  For recurring revenue products like SaaS software, this is a significant aid in locking down future revenue.

Mike Cottmeyer points out the risk:

If your company is in position that it has to sell features it doesn’t have to stay viable, you are taking a huge gamble that you’ll be able to deliver………Failure to have a strategy for dealing with estimates when they are wrong is bad management. Having a well groomed backlog, keeping teams together over time, aligning teams with business units or products, holding teams accountable for establishing a stable velocity, will all help make estimates more accurate over time. Nothing is going to help if we can’t deal with the reality of an oversubscribed product delivery team.

Expectation Management

Once you get past the needs assessment and high level vision conversations, you’ll get down to brass tacks in the RFP and the statement of work.  At this point, you need to be very clear about what the product does today, versus what you project it will do in the future.

This is critical in either of two outcomes:

  1. Your buyer may change his mind, identifying that required capabilities aren’t in your product.  In this case, you have avoided a feeling of misrepresentation by your buyer.
  2. Your buyer may choose to proceed anyway, given that they don’t actually need all the “required capabilities” right away.  In this case, you gain the opportunity for a healthy relationship and possible reference if your product solves the immediate problems well and you continue to improve the solution.

Thinking in terms of the Kano model, you won’t get references to help you cross the chasm if buyers discover any basic attributes aren’t met.

Approaches to resolve

A number of tactics can help to bridge this gap.

  • If you’re demonstrating anything besides the product you have in production–for example, a prototype–be clear with customers before signing a contract about what is in the product now, and what is a planned future capability.
  • Be clear with sales about what is committed by engineering, and what is simply estimates.  This will help sales to avoid mistakenly committing to something that isn’t a sure thing.
  • Clearly communicate that items promised in error will not influence the roadmap.  Once it’s clear that false promises will be problems for the salesperson, fewer of them will be made.
  • Include clear language on roadmap documents that indicate features are subject to change or total omission.  Here’s language from one company’s roadmap:

And what are those caveats? As is usual I have to sound my standard note of caution. These plans are our best estimate at this point in time for what we should be able to do in 2011, given our resources and our understanding of the technology landscape in which we operate. Any dates given are estimates. Any functionality we describe in this roadmap, especially the further out it is, may be postponed or cancelled altogether. We strongly advise our customers not to make firm plans based on what they see here: in an industry such as ours, things can change very quickly and we have to react just as rapidly to new opportunities that may present themselves.

  • A subtle cultural tactic is to be cautious about when it’s appropriate to use the word “slipped.”  The word “slip” assumes something is later than planned, which implies it was planned for a certain date.  If you’re in an agile shop and your engineers have done T-shirt sizing of a rough story idea without detailed analysis, they may have projected a rough completion date.  But in that case, assuming they haven’t “planned” or estimated that work in detail yet, it’s not “Scheduled” In that case, it is best to use some other term that doesn’t suggest “schedule slip,” so you don’t imply an engineering shortfall.
  • A tactic I’ve seen some agile shops apply is to omit all dates from roadmaps.  Instead of a roadmap, they show a prioritized high level feature backlog, which includes more detail for immediate features and less detail for more distant future features.  Some may even include dates on the top item or two which may be at a detailed level of planning.  This eases the conversations around items beyond the short term (about which there are the fewest “unknowns”).

What other tactics and techniques do you use to manage the conflict over selling roadmap items?

 

Image from Stock Xchng.

 

Share this:
facebooktwittergoogle_plusredditpinterestlinkedinmail

As we kick start 2013, our product management team is working out our voice of customer plan for the year.  We recognize that last year, while we made sporadic customer contact, it was primarily sales driven and we were too engineering focused.

Why are Customer Visits Important?

Customer visits help ensure that we build products that customers value.  They help ensure that we understand pain points, that we can properly prioritize which problems to address, and that we know exactly how our products fit into the daily lives of our customers.  They are one of the ways that we can find opportunities for new products and features!  Unfortunately, they’re easy to avoid.  Don’t you want to be using products whose designers really understand you?

What are the key components of a Voice of Customer Plan?

As we set out to plan for 2013, I wanted to think through all the elements of an engagement plan.  I found a great resource in an On Product Management guest post by Christine Crandell.  Crandell suggests that there are three primary types of input to consider.

  • Customer-initiated activities
    This is feedback that is often captured in CRM and customer support systems (e.g. customer complaints, feature requests etc.) and should be integrated with product innovation ideation and idea management capabilities.
  • Company-initiated activities
    These are typically sales and marketing related activities ranging from individual sales calls, to focus groups, user groups and customer advisory boards.
  • Engagement activities
    These are company initiatives explicitly designed to get targeted feedback on products and product direction. These include product management led focus groups, beta programs and customer feedback portals.

We already have a process for gathering input from sales engineering and implementations teams, which touches on both the “Customer-initiated activities” and “Company-initiated activities” categories.  Admittedly, those processes can be improved, however we are able to check that box for the time being.

Because we were completing buildout of several products in 2012, It’s our engagement process that has been a bit lacking.  Thankfully, we have buy-in on change at the executive level.

Our Plan for Engagement

At this time, we are primarily focusing on improving what Crandell calls “Engagement activities.”  We’ve setup a Feedback portal on UserVoice, and we’ve decided to take a three-prong approach to Voice of Customer as follows, ordered from highest volume to lowest:

  1. Client Calls – We’re thinking about making one call per sprint, composed of either follow-up calls to existing clients with whom we have relationships, sitting in on a sales demo/call, and including win/loss if available.  Finding out what prospects thought of our offerings and of the market, all in a bite-size chunk. Ideally, each product manager would do one of these in each two-week sprint, giving each of us 24 per year.  New contacts can be turned into warm contacts for future input on features and for many other purposes.
  2. On-Site Visits - Being aggressive, we’re asking for one travel opportunity per quarter, in which we’ll visit several clients in the same area.  This will be a mix of shadowing and interviews, in order to give us high volume qualitative input.  We intend to feed this high-volume anecdotal information into our persona program.
  3. Conferences - We hope to attend at least one industry conference.  This will provide an opportunity to hear from clients of our competitors, to hear the questions the community asks experts in breakout sessions, and of course to hear the content of the sessions themselves.

Voice of Customer

As we mature our product management organization, we feel like this is a good start to VoC.  What might we need to think about that’s not listed here?  Is this too aggressive?

Share this:
facebooktwittergoogle_plusredditpinterestlinkedinmail

Good to Great

I reread a classic recently, and (only partly) because I haven’t posted enough recently, I want to share some of the book’s most important lessons.

Good to Great by Jim Collins paints a picture of what it takes to move a company from being a good company to being a great company.  Collins describes a “Great” company as one that far exceeds the overall stock market for an extended period, specifically by about 7 times over a period of 15 years.  Though this definition is a bit narrow, it’s difficult to argue with that measure of success.

Since this book is a must-read, I’ll summarize some of the key topics of the most impactful chapters (to me) here.  For more, pick up a copy!

Lessons

  • Starting with the right people turns out to be even more important than the line of business itself.  The lesson here is that hiring is probably the most important thing you do.  One can’t teach work ethic or values, but one can teach skills.  This idea resonates with me because I’ve worked in both large, failing companies with corrosive cultures, and smaller enterprises with uplifting ones.  The culture makes all the difference.
  • Don’t ignore inconvenient facts.  Facing up to the truth–even if it means drastic changes–is one of the things the best companies do.  Ignoring problems only delays the pain, and usually makes it worse.  Investment in repairing issues keeps people reassured that things will be taken care of, which by itself is of great value in culture support.  Further, a culture that welcomes and takes issues head-on is one in which people continue to try do their best; to support this, it’s important that leaders react appropriately to issues.  Making it uncomfortable for managers to raise issues leads to ignoring them, which creates a downward spiral.
  • Stay in your hedgehog.  Companies did best when their activities stayed in the intersection of (1) passion (2) ability to excel and (3) profit.  Yes, it’s a Venn diagram.  Staying “home” avoided costly waste of resources on less fruitful activities.  The hedgehog concept, as this intersection is labeled, is not only the secret to growth, but it’s also the secret to self-actualization and–as I cover elsewhere–to personal branding.
  • Invest in technology accelerators targeted to helping the business advance, rather than technology for technology’s sake.  Technologists like to learn and implement new technologies, but great businesses shepherded this enthusiasm into tech that supported business goals.

There are a few other topics, and of course the book covers these in great detail with surprisingly deep research.  There is no acceptable reason why Good to Great should not be on your bookshelf!

 

 

 

 

Share this:
facebooktwittergoogle_plusredditpinterestlinkedinmail
30. December 2012 · 3 comments · Categories: Agile · Tags: , ,

In June of 2012, I gave a presentation to the PMI Agile Interest Group in Atlanta about my team’s journey from using Scrum to more of a Scrumban process.

Why move to scrumban?

The State of Agile Survey 2010 by VersionOne supports anecdotal evidence: Scrum is the most popular agile methodology.  It would be natural to ask why a team that started with that practice moved to Scrumban, or anything else for that matter.  Three items emerged in repeated retrospectives that led us to shift gears:
  • One of the issues was was the additional stress around completing open stories by the last day to avoid “failure.”  Along with the pressure of solving new problems in the course of true R&D style development, the team felt pressured to (1) take shortcuts to complete work early enough, and (2) shortcut testing to close the story and claim the points.  Regardless of the percentage of stories completed by sprint’s end, we determined that the average velocity over most three-sprint periods remained roughly the same.
  • A second problem was the team spent a full day or more (out of 10) doing detailed tasking, in order to come up with estimates that led to incomplete stories and stress at the end.  We also recognized that when starting a new story mid-sprint, we’d have to revisit the initial conversations anyway, when details were invariably forgotten.  Also, based on the previous bullet, that the reliability of the projections wasn’t high to begin with.
  • A third problem was that with a group of stories to complete, each team member started on a different story at the same time, which prevented collaboration and led to lack of focus.

What was the result?

Based on all of the above, we decided to abandon the first-day tasking sessions and do the detailed planning for stories just-in-time.  Further, we decided to only start one story per pair, when the pair was ready to work on it.  This we determined was what many call “scrumban,” a blend of the timeboxed ritual of scrum with the flow management of kanban.  This meant we maintained the iteration barriers, biweekly demos, standups, and retrospectives that we conducted with scrum.  Because biweekly demos kept happening, the fact that the mindset was vastly different wasn’t immediately obvious to other stakeholders, but what we stressed was meeting deliverable dates.
The team responded well to a clearly painted vision and a target date, as long as it was reasonable.  The team did not respond well to being chastised for failing to complete specific stories in specific sprints which were not tied to a release.  Coincidentally I spent some time with another team in Q3 of 2012 and discovered they too were struggling with some of the same problems, primarily unnecessary frustration around the inability to complete every story within sprint boundaries.

Does Product Management Care about Scrum vs. Scrumban?

I argue that Product Management can manage Agile better under Scrumban than Scrum, because there’s less time-sensitivity around the product owner’s need to be present in the room with engineering.

Here’s how it helped us:

With robust engineering practices around test-driven-development and especially behavioral-driven-development, the product owner’s information was captured during story elaboration when a feature is started.  The team thinks through all the scenarios and details one or more stories to support them, with all scenarios for each story captured in English-derived Gherkin.  The team then gets to work and calls the product owner when the software is able to pass those specifications–and obviously, when questions come up. This process allows ample time for the product owner to engage in expectations management throughout the organization, requirements gathering, customer development, and all the other fun things a product manager is responsible for…..like meetings :) Long term, velocity also improved by 20%.  That also makes Product Management happy!

Share this:
facebooktwittergoogle_plusredditpinterestlinkedinmail