Braving the DevOps Frontier

“There’s gold in them clouds!!” – The gold rush for business value and pace of change is on and the latest golden child is DevOps. That delicious portmanteau of Development and Operations. But much like the Wild West, our rush to charge into this brave new frontier, blending two disciplines that have been separate for decades, is not without issue.

The Good

  • Developers must take ownership of their code all the way into production
  • Ops staff embrace the pace of business and the rhythm of feature delivery and business change

The Bad

  • Dev Teams are starting to drift away from a long-term strategy for their software design, embracing the expediency of delivering features ASAP
  • Ops Teams are losing a means of vocalizing when business and development decisions put the organization in a precarious solution, because they are seen as being obstructionist to the new way of life

The Ugly

  • The critical role of quality assurance (QA) can sometimes get lost in the continuous development and delivery shuffle. Where is the dedicated and intentional effort to fold a thorough and professional examination of quality fit into the DevOps equation?
  • Although development teams have been moving incrementally toward agile and lean startup strategies for years, operations teams are very much finding themselves behind the eight ball. There is a significant shift in mindset, skills, and tooling required for these groups to come up to speed.
  • Development teams have a sizable knowledge gap as well. Although my family has trouble grasping it, it is not true that if you ‘know technology’ then you are equally adept at all things technical. Many developers have lived in a “if it compiles, then it’s good” mentality for much or all of their careers. They’ve never really needed to understand the production world…until now.

DevOps and the overall shift toward Development teams and Operations teams working together to deliver business value early and often is a good thing. Developers becoming aware, sensitive, and ultimately responsible for operationalizing their code, is a good thing. Ops folks partnering with the developers to deliver new and ever-changing business features is also a good thing. But if in an effort to embrace this new normal, we lose all of the uniqueness that a proper Development, QA, and Operations disciplines offer us, then we’ve swung too far to the latest extreme. Teams need to come together as partners for business value delivery, but not at the expense of long-term strategy and robust quality.

The Long Game

Great read from the founders of Yipit, on the long hard road to become and overnight success:

So, it’s now February of 2010, over two and half years since we started, and we have yet another idea: build an aggregator for the early but quickly growing daily deal industry. The idea was sound, timely and right up our alley since we had been doing local deal aggregation for the last 9 months.

And, in just three days, everything changed.

We launched the new idea in a three-day scramble, got some initial press, users loved it, and four months later raised $1 million from amazing investors. A year after that, we’ve raised $6 million, made real revenue, attracted hundreds of thousands of users, and recruited amazing people to join our team (we’re hiring! join us!). And, best of all, we’re just getting started.

I really liked the raw honesty of this post.  I just quoted the happy part – 2.5 years in.  But there’s also this part:

“So, what do you do?”

Ugh. I hated that question.

The truth was that we were trying to start a new venture but we hadn’t really made any progress.

Anyone with a struggling startup can relate to this.  I’ve felt this same awkwardness explaining what we do – not so much because we’re struggling but because BPM isn’t exactly a buzzword for the masses or a great conversation starter at social events.  But I’d much rather be telling people about what we do at BP3 as a BPM services firm than, say, a dating site (not that there’s anything wrong with that!).

I’ve noticed when I explain how we started BP3, people have assumed that we only left Lombardi at the moment IBM acquired the company.  Not so.  We started BP3 about 2.5, almost 3 years, before IBM acquired Lombardi.  An investor would probably call that being “early”.  It wasn’t about the acquisition or potential acquisition.  It was about starting a company that could be the best BPM services firm we could be.

That 2-3 years was great formative time for us to build our reputation, our culture, our team.  It takes a long time to build the foundations for success – especially when you’re bootstrapping – but people don’t always remember how long it takes.  All of a sudden, it looks like success and they wonder how it materialized out of the blue.  But we’re in it for the long run, and we always were.

In closing, congratuations to Yipit on their “overnight” success!


Related posts:

  1. Integrating a Startup
  2. Seven Austin IPOs this Year?
  3. A Couple of My Favorite Services, Bought

Scientific Method and Startups

It is just hard to see how this news, courtesy of Steve Blank, could possibly be bad news:

Today, the National Science Foundation (NSF) – the $6.8-billion U.S. government agency that supports research in all the non-medical fields of science and engineering – is changing the startup landscape for scientists and engineers. The NSF has announced the Innovation Corps – a program to take the most promising research projects in American university laboratories and turn them into startups. It will train them with a process that embraces experimentation, learning, and discovery.

The NSF will fund 100 science and engineering research projects every year. Each team accepted into the program will receive $50,000.

I feel sure that some will nay-say.  But Steve Blank has documented on his blog how the government has fostered a startup ecosystem before in his Secret History of Silicon Valley series, and this has some of the same feel to it – but with the added impetus of a better way to wrap scientists and researchers brains around the concepts of startup formation.

As a process guy, I’m really impressed with how much the process of “starting up” has been improved upon in just the last decade – and Steve Blank and Eric Ries and others in the Lean Startup movement are behind much of it (too many contributors to name in one post – because it really is a collection of ideas from many people and companies). I’ll continue to follow along as it informs our own growth as a “startup” consulting firm, but also because there are interesting cross-pollination opportunities with the process improvement work we do.

Congrats to Steve Blank, the NSF, and everyone else who was part of making this I-Corps program come true.

Related posts:

  1. Ash Maurya Reconciles Customer Development with Web Apps Business Realities
  2. A Process for Teaching Entrepreneurship?
  3. Startup Lessons Learned Conference

What BPM Can Learn from the Lean Startup

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.

Waterfall: Known Problem, Known Solution

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

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.

Unknown Problem, Unknown Solution: Lean Startup

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”



Related posts:

  1. Lean Startup SXSW: Introduction
  2. SXSW 2011 day 2. The Lean Startup Phenomenon
  3. Lean-Agile for your BPM Delivery