Since the beginning of the SXSW-interactive conference, I’ve posted a few times about the Lean Startup sessions and hinted that they might apply to BPM.

Heading into the IBM Impact conference, this feels like the right time to talk about the Lean Startup as it relates to BPM – it provides a decent segue to the topic we will speak on at Impact – “Keeping the Business in BPM“.

Let’s Review What the Lean Startup is All About

It turns out, I’ve written about this before.  But I think it is time to return to the subject with a little more perspective.  The premise behind the lean startup is embodied really well by three charts (click on this link, slides 20-22).  I’ve given each idea my own poor rendition here in the blog since I don’t see a good way to embed a single page from a SlideShare presentation.

Known Problem, Known Solution: Waterfall method

First, Waterfall development techniques were designed around situations when we know the problem really well, and we also know the solution well, and simply have to make sure we deliver a quality result.  It should be no surprise to anyone in the BPM space that this does not describe the typical BPM / Process Improvement project.

Known Problem, Unknown Solution: Agile Method

The second slide shows an innovation over the first: that when the problem is known, but solution unknown – a different technique is required to solve the problem:  Agile development. There have been many proponents of an agile approach to software development, and it is arguably the most accepted methodology among software engineers.  This does not mean, however, that it is always practiced, or practiced well, nor has it infiltrated all IT projects.

Lean Startup: Unknown Problem, Unknown Solution

The third slide shows yet another innovation: when the problem is also unknown, the solution is unknown.  At this point, we can’t rely on just documenting the requirements or interviewing the known user base.  We have to apply what Steve Blank coined as “Customer Development” – getting out of the building and talking about our problem hypotheses with customers.  When we get our hypothetical problems and hypothetical solutions in front of customers and discover we’ve “missed” the market, we “Pivot” – that is, take the lessons learned, and adapt what we’re doing to find an addressable market we can actually build a business around.  Essentially, the lean startup keeps iterating and pivoting until it finds a business that it can scale (or until it runs out of money).  Once it finds something to scale, the problem is no longer one of “searching” for a business model and solutions, but one of scaling an operation.

The coupling of the Customer Development process with the Agile Development process has been coined the “Lean Startup” by Eric Ries and others.  Why do we call the problem “unknown”? Perhaps you think of course we know what problem we’re attacking – the startup company was formed to solve this particular problem.  That sounds good – but actually startups only THINK they know what their business model will be.  Google thought their model was search.  But it was really targeted advertising delivery, based on Search and alongside search.  Small startups pivot often, but we’ve also seen large companies pivot – as IBM did when it moved to really emphasize its services business.

How is BPM Like the Lean Startup?  “Problem: Unknown”

Some readers should already be seeing a connection between the Lean Startup and BPM.  But it helps to really spell it out.  First, I propose that when you start a BPM project, you only have a hypothesis about your problem and solution.  This is what we mean when we say the problem is “unknown” – that we have a hypothesis but it isn’t proven yet.

How do we know that BPM suffers from this “unknown” Problem situation?

Because the biggest risk to budget, or even success, of BPM projects, is getting the requirements wrong.  As I often tell our team: “No, you’re not going to get good requirements up front for this project. And if you do, they’re probably wrong.” We have to approach projects with an open mind toward how requirements will evolve.

Already, most BPM practitioners approach the solution as an “unknown” or “hypothesized” solution.  This is why, for example, successful BPM projects typically have an Agile, or at the least iterative, approach to BPM development – it allows opportunities for course correction with the Business, getting closer to the “right” solution over the course of several iterations.

BPM Takeaways from the Lean Startup

But, the other side of the coin is that we BPM practitioners need to adopt some of the methods of the Lean Startup and Customer Development:

1. We need to “get outside the building”. For the IT folks developing BPM solutions, this means going outside the IT labs and seeing how the “Business” really operates.  Talk to them.  Observe them.  Read between the lines.  Get their feedback on prototypes and early releases.
2. We need to employ more A/B testing in our solutions. Don’t assume we’ve designed the right improvement to the process – prove it!  A/B testing is de riguer in software circles, but not inside IT shops, and not in process improvement methodology.  But it should be.  I’ve only seen one BPM endeavor really embrace A/B testing – and it was a great success.
3. The unit of progress is learning. This is a core principle of the Lean Startup.  While we’re searching for the right problem to solve, and the right approach to address it, learning is what we want. An A/B test that shows we didn’t move the needle as we wanted to is a success if we have learned a better path forward or avoided a costly dead-end.
4. Shift to Value-Based Delivery over Plan-Based.This means that we have to re-prioritize work throughout the project – to always keep the Delivery team focused on the highest value work.  The plan is your hypothetical plan.  Don’t stick to it when the facts dictate otherwise.
5. Get the Business and the Technical Team working together. Seriously.  Put them in the same space. Or the same room.  Make them part of the same team.  Make it the dream team.  Because when you get the leadership and team right, everything else gets easier.

There is more to it than just this… But if we can just pick up these four things for our BPM projects, we’ll make dramatic progress on improving the process of BPM. It takes leadership to drive these behaviors – but I hope that leadership just needs a little bit of encouragement through education and familiarity with the concepts behind the Lean Startup.

I’ll see many of you at Impact – in our session, I’ll touch on the whys and hows for a business-driven technical team.  And if you read this blog, you’ll have some of the underpinnings behind my part of the talk.  Of course, Lance and Reid have a few interesting points to make too!  Wednesday, April 13, 3:15PM to 4:30PM, In the Venetian – Murano 3205 room: “Wells Fargo – Keeping the ‘Business’ in BPM”

Interesting blog from Austin’s own Ash Maurya “The Fallacy of Customer Development“, which is really an essay to explain that if you’re developing a web application, rather than enterprise software, you need to apply a different approach to customer development to really get the valid feedback you need.

It’s an interesting adaptation of the customer development process outlined by Steve Blank in “Four Steps to the Epiphany” (I’m partly partial to Steve Blank because several of my friends went to work for epiphany).

But I also find it interesting to follow the development of processes for startups, for customer development, for the lean startup.  Following Steve Blank, Eric Ries, Ash Maurya, and Jason Cohen gets you pretty far along the path to understanding this school of thought.

Most have heard the term “white space” as it refers to business processes. In short, white space are all the things which happen outside the standard process; workarounds effectively. Most of this is un-captured “hidden” work that impacts the overall process capability in a non-favorable way. Identification of this white space is exactly what process analysis is all about because it is within this white space where you often find real root-cause issues that create variation in how well the process is performing. Just one example would be when you have a standard process defined at a given level and use that standard as a point of measure, yet some steps are being done differently to compensate for regulatory changes or system deficits. This is a pretty common pattern we have all seen.  The upside is that finding this white space is more straight forward because you are analyzing a living, breathing business process. Notice I say straight forward, that doesn’t necessarily correlate to easy.

There is another situation however which is far more elusive, and ultimately far more vast than white space. I think of this as delivery ”Dark Matter” in that it really resembles what we have come to learn exists in the universe. Dark Matter is matter that has real effects on everything out there but is not highly visible, the mechanics are relatively unknown in so much as to what effects one might expect by its presence, and measurement is relatively non-existent. However, you can validate its existence quickly by being in the throes of a BPM project. No matter how well-formed a delivery and risk plan are to a particular BPM delivery program you will no doubt experience unexpected, and sometimes violent failures in one form or another while you are in the actual delivery phase of a project. Here is the big difference between the white and dark: you can analyze a process for white space because it is in existence/tangible or more specifically it is running; but unless you are in the real construction situation of a solution, you can’t identify dark matter’s effects on delivery. Everyone can brainstorm all the possible challenges which might arise, work out mitigations and the like but as long as you are rooted in documentation and not the visceral experience of delivery you will not be able to capture all of it with high confidence.

Compounding this problematic situation is when mitigations and controls start being applied liberally into the project before any actual experience is garnered! Consider this, you are increasing the mass of the project with more controls to mitigate risk thereby increasing the energy required to deliver. Eventually, this competition results in pure inertia. Nothing can move, nothing can proceed because the sheer weight which has been built on the project cannot be overcome. In the race for risk aversion of this elusive dark matter a project can be overwhelmed and brought to its knees before it ever has a chance to deliver value to the business in which it was chartered. Good news is that you avoid dark matter failure effects, bad news is that you almost always avoid success.

Up next will be an important notion to help successfully deal with the dark matter, “Value-Added Failure”.  A successful failure sometimes gives you the greatest returns!

Every so often, a conversation builds to critical mass and demands an in-person meet-up.  Eric Ries pulled this show together, and I have to say there is some great video, and there were some great presentations to browse to get to understand better what you can do with a lean-startup approach.

Steve Blank has one of the best overviews with links to all the important content.  And here’s a link to the stream of his talk.  You can find almost all of the presentations on slideshare with the sllconf tag.

Maybe I relate to this conference effort because we put on the bpmCamp unconference earlier this year.  Mainly, I applaud the effort to build momentum and credibility around some really great frameworks.

Steve Blank’s blog has a series of posts regarding the entrepreneurship courses he and his colleagues are teaching at Stanford and Berkeley.  The thing that jumped out at me is that it sure reads like there is a process for teaching entrepreneurship.

Maybe that shouldn’t be surprising.  But it was already eye-opening for me to read the process-oriented approach Steve advocates for developing your business model (aka “Customer Development” , good read on wikipedia by the way), and a process for product development that is highly complementary to this (Lean Startup, advocated by Eric Ries among others).  But it looks like Steve is cracking the code for how to teach entrepreneurship.  Of course, proof will be how well the entrepreneurs who take his classes perform relative to peers who do not attend these classes, and how many other entrepreneurs adopt the techniques Steve is advocating because they’ve heard about them from his students or writings.

Til then, we can apply our own subjective judgment to assess.  So far so good.

I’m tired of waiting. I think I’ve been spoiled by the pace of Web 2.0 and I’m no longer patient for each major release of enterprise software.

In a world where we can receive application updates to SaaS applications daily, weekly, quarterly, I’m tired of waiting for enterprise software to release major upgrades every few years.  In particular, BPM vendors, of all enterprise software companies, should know that continuous improvement is a better method than the big-bang release.  They should be embracing incremental improvement techniques, just as their customers should when deploying BPM solutions.  Why do they talk the talk and fail to walk the walk?

Every BPM vendor (every software vendor!) should read Steve Blank’s Manifesto for Customer Development. Steve Blank and Eric Ries writings should be mandatory for software developers in the BPM business.  Heck, their articles should be mandatory reading for people deploying BPM software as well.  The traditional “product development” model consists of four phases:

1. Concept / Business Plan
2. Product Development
3. Alpha/Beta Test
4. Launch / 1st Ship

And Steve Blank rips the heart out of this process:

The first hint lies in its name; this is a product development model, not a marketing model, not a sales hiring model, not a customer acquisition model, not even a financing model (and we’ll also find that in most cases it’s even a poor model to use to develop a product.) Yet startup companies have traditionally used this model to manage and pace not only engineering but also non-engineering activities.

So.  Off to a good start.  So what are the problems?

1. Focusing on a finished product instead of minimum feature set.  Lots of resources are going to be wasted on features that won’t matter to customers.  Those resources won’t then be available to invest on features that DO matter to customers.  Guess what?  Software vendors have finite resources.   These prioritization decisions matter.
2. Founders or Executives hand-off responsibility for validating the vision.  Marketing and Product Management now own that, and Sales.  The founders and executives aren’t hearing directly from customers which features are buying criteria.  Founders and top execs need to hear customer feedback in order to know when the ship needs to be righted.
3. Engineering becomes so focused on their ship date execution plan, they become immune to outside input, or changing the plan, except to move the ship date further out, or cut features.

In another article, this time on GigaOm, Mike Speiser argues for the power of Continuous Improvement.  Well, he’s preaching to the choir with me, because as a BPM practitioner I’ve been advocating continuous improvement for most of a decade.  Mike argues that often the reason people (and businesses) languish at a mediocre level of performance is simple:  they lack a good feedback loop.  Without timely feedback, they can’t tell if their actions will produce exceptional, average, or mediocre results.  The learning cycle is too long to take hold.

A fantastic example of what can go wrong in a big organization:

Let’s say you’re a mid-level executive — a GM or product manager of some sort. More than likely, you’re measured by how well you interact with and present to your manager and senior executives. Consequently, you optimize to managing the bureaucracy (your boss in particular) rather than delivering the right product or service to customers. And so does your boss, and her boss, and so on and so on. Here the only thing that you’re practicing and perfecting are your brown-nosing skills. How can you expect to learn in an organization with that type of feedback and incentive system? How can such an organization, by extension, possibly produce excellence?

The most telling quote of all:

The organizations that produce excellence are those that continuously improve. The more granular and frequent the improvements, the better.

Its worth reading that one twice.  Three times.  Now.  If you’re a BPM vendor, and you have an enterprise version of your product, ask yourself if this statement applies to you, your team, your product, your organization.  You may be saying to me right now- but we’re on version 5, version 6, 7, version 10, of our BPMS – so clearly we believe the gospel of continuous improvement.  But I say to you, how long was the development effort that led to this latest version?  Why was it more than 3 months?  Why is there a “major version” at all rather than a series of incremental improvements that migrate customers from old to new?

Many of the BPMS vendors are now providing SaaS or ASP oriented BPM solutions – at least for modeling and collaboration, if not for execution.  These solutions seem to get revisioned on a frequent and substantial basis, much like the majority of web applications and “Web 2.0″ out there.  I would now like to challenge the assumption (presumption) that Enterprise software can not be similarly improved.

What’s wrong with the traditional product development model for BPMS vendors (my observations):

1. There are large sets of features that languish without improvement for many years.  A mediocre feature was introduced in 2005, it was never revisited, except, perhaps once to fix a bug in 2006.  This “feature” might be something really important to customers:  reporting, versioning, integration with salesforce, etc.  But for whatever reason it never rises to the level of interesting for Product Management, or it gets cut in the interest of making the almighty ship date.
2. There are large swaths of potential features that never get addressed, because the product development team imagines it knows what is going to sell when the shiny new release is finally released.  So, that PDF export you wish you had in product continues to be something professional services had to provide.  That import from Visio the customer wants isn’t available in your otherwise superior product, and the customer goes with another product that does this out of the box.
3. Low priority defects never get fixed.  Why fix them, when the “new release” is coming.  Wait for the new release, then consider fixing these minor things on the new release.  The problem is, the new release will introduce its own set of important issues to fix, it will take time to confirm the minor issues are still issues on the major release, and by the time those minor issues are back on the table again, the answer from engineering will be: this is too low-priority as you’re on the old release – we have a new release coming that will be the one to fix this on.  So, you spend more time waiting for the Next New Thing than you do actually treating it like the tip of your product line.

If your major versions take more than 1 year to ship, you’re doing something wrong.  And that may be generous.  How do I know that?  Apple ships new versions of an operating system every 12-18 months.  That’s a much more daunting task than a new BPMS.  Much larger installed base.  So why does it work?

1. You have to make the investment in automated update mechanisms that work. Think Windows Update, Mac Update, etc.  These programs work.  The changes they propagate have to be *contained* and backward compatible.  But they work. It puts constraints on the engineering team – but they are *good* constraints that these teams ought to operate under anyway.
2. You have to compartmentalize your updates into components or units that can be upgraded without breaking everything else.  Think Apple replacing their legacy development framework with Cocoa – something that they did gradually over the last 10 years, piece by piece.
3. Independent components imply that you have to have good API’s.  If you don’t have API’s defined between the internals of your product that you feel comfortable documenting and publishing internally and to partners, then you should develop and implement such API’s as part of every revision to your product.  API’s provide the lubrication that allows for change in your product without putting unaffected parts of the product at risk.
4. You have to respect data formats.  The data is sacred and hast to be protected.  See #3 – without APIs protecting your data, you won’t be able to change the schema without breaking upstream services.  And you won’t be able to change upstream services without breaking your data.
5. You have to believe in the evolutionary/incremental over the revolutionary.  If developers think they can depart from the past without respecting it, you will get incompatible software and unhappy customers.
6. You have to allow for individual accountability for product.  If people don’t “own” something, they won’t have the appropriate baked-in incentives for improving it. My favorite question to find out if a company is serious about a feature set, is to ask who owns it – who’s your lead developer for this part of the product?  What are their other responsibilities?  How long have they owned it?  Can I talk to them about what they’re working on now and why?  I want to understand their thought process.

I see enterprise BPM vendors talking the talk about continuous improvement.  But I don’t see them walking the walk in their enterprise software offerings.

Interesting tie-in between process and Twitter on GigaOm recently in an article by Jennifer Martinez.  She points out that Biz Stone’s discussion of the future of twitter appears to follow along the lines of Eric Ries’ “Lean Startup“.  Notably, they intend to follow customer usage to figure out what to build around the original 140-character Twitter service in order to create more value.

Its the first time I’ve actually read something that indicates there’s some method (process?) to the madness that is Twitter – and maybe that is new, or maybe that has been the case for a long time and I’m just now becoming aware.

We’ve recently set up a twitter account for those who want to receive tweets of our blog posts (rather than subscribing via RSS for example).  Its @bp3bpm.  It will just be capturing our blog, and perhaps company-news-items at some point in the future.  I’m personally on twitter as well (@sfrancisatx), but I can’t promise to stay focused on BPM on my twitter feed. We’re just providing an alternate way to keep up with BP3, and BPM.  We’ll see how it develops for us.

Jim Sinur wonders allowed whether you can Time Box BPM efforts effectively… and concludes that in some cases you can, in some cases you can’t.  In favor of the “yes” argument:

Benefits flow early and the project sponsors look like heroes. Success breeds success and a BPM program can take off early. Anybody want to say “no” to instant savings?

Indeed, who would want to do that!? And then Jim puts up another strawman for the “No” argument:

What sometimes happens when this approach is taken is that sooner or later a project that implemented benefits may have to give them back to help the overall process. [...]

Not only might it knock out strategic benefits, the conversion costs could wipe out a period of the savings. Why make false starts when you can do it right once?

Well, quite frankly, you can’t do it right once.  That is the false choice in the comparison.  IF you could do it right once, this would be a valid decision tree – but since you CAN’T do it right once (with any reasonable probability), this point doesn’t hold much water for me.

I don’t believe this is a six-on-one-hand, half-a-dozen-on-the-other issue.  Time boxing works – and specifically it works more often than a big-bang deployment.  The point is that since we can’t get a software release right in just one release, the goal is to approach the right answer increasingly accurately across a set of smaller, less expensive releases rather than one big release.

Yes, there is the caveat that you must keep corporate objectives in mind, and that in a future time box, some of the gains in one area may slip in order to achieve a bigger overall gain.  But in practice I have experienced that kind of “back-sliding” as a pretty unusual circumstance.

When giving back benefits did happen, it was a classic case of “squeezing the balloon” – where one group with relatively inexpensive staff optimized their process around reducing hard costs (measurable as headcount).  They neglected that their optimization created additional work for other parts of the organization, where the staff was actually more expensive – and therefore, they increased overall cost to the organization instead of reducing it.  But the increase of cost can be hidden as soft cost – a slightly decreased productivity by a large number of people is difficult to notice via anecdotal or sampling data.

Time boxing is key for creating a pattern of delivering, of being accountable, of having a delivery process that has integrity.  The alternative has a much higher probability of failure.  In this blog, we typically refer to “time boxing” as “Iterative Development” and time boxes as “Iterations”.  But both terms are valid taxonomy.  They’re also similar to concepts in the Customer Development process (generally popularized by folks like Steve Blank and Eric Ries among others).

Recently Austinites (or, some Austinites) expressed frustration (outrage?) that a contract to build a new City website was being filled by a company in California.  Given how many folks there are in Austin who know web design and implementation, and given how many of those might be looking for work at the moment, it just didn’t seem to make sense to send a $750,000 contract to another state for fulfillment.

And so William Hurley started an effort he’s calling OpenAustin.org, where he is promoting a different approach, one he calls “crowdsourcing“.    The idea is to crowdsource the prioritization of requirements, and then the building of the site itself.  Hurley claims that this specific project could be built for 10% of the estimate currently on the table (and, there has been some debate whether the $750k is for building the site, or just formulating the PLAN to build the site).

Several posts have cropped up about this development- on Austin’s Startup Blog, on GigaOm (thanks to Stacey Higginbotham), and again on GeekAustin, and it has a fair amount of buzz in the Austin community.

What I think is interesting about Mr. Hurley’s approach is that he’s essentially saying that a Customer Development process where you quickly iterate on learning what the customer (citizens of Austin, members of the city government) really want, and then prioritize based on their input.  By doing this, they can save a lot of what could otherwise be wasted development effort on features that no one really wants to pay for.  In a sense it is a continuing battle for transparency in the local government that Austin has been waging back and forth for decades.  In this case, we have people advocating for transparency of the development of an important City resource.

We’ve previously commented on Customer Development, which is particularly well-suited to situations where you don’t know with certainty the problem nor the solution.  In the case of the website, it looks like a fair number of people are feeling like the RFP and the Contracting process were done in a too-insular fashion, at a result of increased costs and less alignment with the public.  It will be interesting to see how it shakes out, but I sure like the idea of prioritizing city web dollars using public voices, and local city staffing.