Beyond Scrum - Summary: The Cargo Cult of Scrum

During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they've arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas—he's the controller—and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land.  ~  Richard Feynman

Summing it Up

Scrum wasn't a bad thing when it started.  The Internet was a new medium, Java, ASP/.Net were new platforms, and we had a long way to go and a short time to get there.   I'd venture that nobody knew where software came from, and Agile arose in response to the death marches that so characterized "waterfall" development.

Well it's been 10 years and agile and Scrum have given us lots of software - all delivered but much of it staggeringly mediocre.  Scrum is clearly a cult -- with certified scrum masters and the enduring belief that the software would suck less if only you could somehow have been more agile!  The no true Scotsman rule applies: Scrum didn't fail you and your team -- your team failed Scrum...

Enough already.  We can take the lessons that Scrum taught and evolve to a better way to deliver / offer / present not only functional but exquisite software.  Let's wrap up the rest of the pieces.

The New Rules

The most basic rule of software development is that software projects are first-and-foremost projects, and the body of knowledge that we've gathered running all kinds of projects in all kinds of other disciplines needn't be left behind just because it's software.   The Project Management Institute is way ahead of the curve on this, and doesn't waste words (or letters) in calling the Project Management Body of Knowledge the PMBOK.  The principles here really are timeless, and while the PMI does love its own language the rest of the cult artifacts are kept at bay.

From that basis there are some other guidelines that we might follow to produce better software for this new millennium.  Rather than try to spin up a new cult, let's look at the science underlying software development:

• Time -- really is nature's way of keeping everything from happening all at once.   If you try to give Time more meaning than that you are asking for trouble by bending the concrete to fit the abstract.    The more you bend the worse-off you are, so all development is trying to focus on the smallest increments possible.  The goal is then to come as nearly as possible to these ideals:
  • Builds (per Spolsky) should be instantaneous at the press of a button.
  • Deployment should be continuous (hello Jenkins!)
  • Availability should be continuous.  Stakeholders should be able to try and run "the latest" from a standard source at any point in the project.
  • Checkpoints should match external milestones, not periods on the calendar.   Once upon a time Sales Sonar was released by Innovadex at the American Coatings Show on a June 3.    Our audience was assembled -- no other dates on the calendar mattered.

• Information -- should be universally available, subject to access and security constraints, and instantaneously available as it is needed.   So:
  • Software check-in happens when software passes tests and reviews -- not nightly or weekly, but continuously.
  • Status and project information is available everywhere (thank you Yammer/Campfire/Basecamp/JIRA/Skype...) and updated continuously.
  • Meetings take place virtually whenever they are needed -- for screen sharing, planning or status updates.   Pair programming is the rule here -- the old rule of "one office per developer" may have been fine for reducing interruptions, but it's terrible for collaborative software review. Team meetings are great for human bonding and comradeship; using the morning Scrum status meeting as an attendance-check is idiotic.
  • Product design updates happen continuously with requirements drafted and rolled into the project for specific checkpoints.   There's no reason to try to cram Design solely into Scrum Sprint Planning meetings, and (perhaps unlike in the Chrysler Payroll days) Product Management is an organizational activity that happens continuously, not just on Sprint Planning Meeting day.

As noted in the conclusion of my last post -- if you believe these in these ideals and you strive to follow them, then you are on another, better path and calling it "Scrum" doesn't make it so.  Scrum is a cargo cult spawned off of sound PMI principles.   Stick to the PMBOK.   Use technology to compress Time and distribute Information. Seek in all things to build great software.  It's hard, but beautiful software is one of the most exquisite and ennobling things of our time.

"The impossible missions are the only ones which succeed."   ~ Jacques Cousteau

Beyond Scrum - Tools and Techniques

We want to create create software, not only for business benefit but because great software is one of the artistic hallmarks of our age, and truly great software (Stephen Wolfram's Mathematica, and Ivan Sutherland's Sketchpad (1963!) are two of my favorites) is the artwork of our time.

Scrum and the current vestiges of Agile will get you "deliverable" software, but they are not enough to get you GREAT software -- there's too great an emphasis on serviceable delivery, and not enough on the countless subtle enhancements that take you from d e l i v e r a b l e to insanely great!.   I'm sure that the two aren't mutually exclusive, so let's talk about how we make the quantum leap.

We've started with what's wrong, so let's gather it all up and set it to right.  If we peer a bit deeper into ideas behind Scrum, we can take it beyond the dreadful manifestations of those ideals:

• We need great communication, so that every stakeholder has the latest information to make the best decisions. We also need team huddles so that everyone stays connected, heart and soul, to what the team is creating.
  • We do not need a morning attendance meeting where everyone recites a mantra

• We need leadership to evolve our vision as we understand it better
  • We do not need consultation

• We need wisdom that embraces not only the "what" and the "how" but the why

Communication:

We start with communication because communication is both the yin and yang of great projects:

• Metcalfe's Law says that the value of the customer base we reach grows on a power-law, and N*N is vastly better than N.
• Amdahl's Law, though, says that we get diminishing returns as we add to the development team, and intra-team communications are the bottleneck
• The formula for communications channels:  n(n-1)/2 also gives a second-order equation for why things get exponentially harder with larger development teams

Scrum has some fine ideas if your scope is limited enough that you can complete it with a team of 6-9 developers.  Its communications limitations doom it for larger projects, and it's not too hard to show that they fail in the 6-9 developer range as well. Given the power laws that both costs and benefits follow it should be pretty clear that "morning stand-up meetings" that leave no written record just don't make sense for anything much more profound than "Chrysler Payroll."   In the Two-thousand-teens, here's a better, broader approach to communications:

• Chat -- Yammer,  Campfire or Hipchat provide asynchronous, logged communications -- the kind of essential but non-imperative chats that cooperating developers have every day.
• Meetings -- Skype, Google Hangout or Apple Facetime are all good ways to electronically do screen-sharing and 1:1 or 1-many meetings.
• Electronic "Standup" meetings -- Update software like Status Hero takes away the need to get everyone together in person at any time, and logs and archives the results
• Screen Sharing -- Remote pair programming used to be a tough slog, but faster Internet and sharing tools make modern pair programming almost as good as being there. Skype is de-rigeur for sharing in the 2010s, and all Macintoshes come with a fantastic screen sharing application.
• Source code control -- Subversion has fairly universally gone over to Git in the 20-teens
• Source code socialization -- Github and Gitlab (for do-it-yourselfers) provide the social side of code management
• Wikis -- Basecamp and Jira are widely used.   Basecamp is more social, Jira is tech-ier
• Requirements -- JIRA and Rational rule the roost here.
• Deployment -- GoCD and Jenkins are best in class here.

We want a heartbeat for the project, and these are examples of far better tools to achieve it.   We still want live and up-to-date developer status, and here Status Hero logs and tracks the latest. Jira and Rational keep our developer requirements, git holds the source code and Github/Gitlab track code reviews and social access to the code.  We deploy continuously with GoCD or Jenkins, and Jira or Basecamp track the social side of project management.

Our team and software are continuously integrated and routinely stay up to date.   As a leader you need to ensure everyone stays up on Status Hero, but in 2015 standup status meetings make about as much sense as "personal tape drives".   Better communication tools and continuous integration "are the new tape."

Leadership:

Scrum routinely (in both good and bad senses of "routinely") delivers mediocre software because it completely abdicates the leadership function in software development.  Scrum Masters are said to have "power but not authority" -- in truth they have neither.  They can guide a team but the developers don't report to the Scrum Master, and when the hard decisions that determine great software need to get made there is nobody tasked with making them.

Steve Jobs is the shining light in this field, and he was the Vince Lombardi of consumer device software.   He was Lombardi for good because he was absolutely tyrannical, and nobody ever had to wonder "where the buck stopped."   He also had the vision, will, skill and personal magnetism to hire remarkably talented people to work under his yoke.   He was also the Lombardi for evil, because if you try to manage like Steve Jobs and you want anything like Steve-Jobs-results, then you better have all the talents and gifts Steve Jobs had.

Lombardi was a curse when I was growing up, because his Super Bowl victories created a legend that glossed over his psychopathic coaching tactics.   That legend was embraced (and those tactics adopted) by scores of Lombardi-wannabes who 1) didn't have his skills, and 2) were coaching kids and not playing for professional stakes.   In that post-Lombardi era lots of kids were driven brutally in pads on hot summer days by sadistic wannabes who adopted his drive without gaining any of Lombardi's other skills.

One of the greatest flaws of Scrum in the Jobs-era is that the leadership gap left by the "Scrum Master" role is often filled by Product Owners who adopt Jobs' micromanagement obsession without having any of his remarkable vision.   It's a miracle if such misguided and misled teams ever ship anything.

Great software requires both management and leadership and creates a breathtakingly difficult position to fill:

• Technical enough to keep up with insanely fast-paced technology advances
• Managerial enough to take fingers off the keyboard and be "chairman of the bored" with occasionally-necessary paperwork
• Visionary enough to see magical solutions and articulate enough to make the team see them too

Nobody teaches such wizardry; Gandalf, Yoda and Harry Potter may have grown into it but mostly such leaders are born into it.

Wisdom:

Simon Sinek captures a really important message in his book (and accompanying TED talk) "Start With Why."

• If you try to tell a development team "what" to do, you'll chase in circles because any sufficiently interesting software technology moves too fast for development managers to keep up with it -- if you're a manager and you understand it enough to recommend it, then it's already been surpassed by something better.
• It's modestly better to try to tell your team "how" to do it, but this fails as well because just as "no battle plan survives contact with the enemy", no good implementation approach survives first contact with customers.

Let's let Sinek tell the story:

Starting with Why is the magical elixir so often missing in software development.  The great wonder of modern development tools and technologies -- the tools listed above, coupled with modern ecosystems like Java, Rails, Hadoop and the emerging Angular++ JavaScript world -- is that you can start with why and if you take what the tools and frameworks give you, you can evolve the "how" and "what" while keeping to schedule and budget.

I've done this before -- with Chris Russell (reporting to Larry Ellison) at Oracle, for Sandy Kemper at Perfect Software, and for Bruce Ianni at Innovadex.   Scrum isn't the answer, but it's a start.   If you take Scrum, replace the Scrum Master with a real leader, drop the silly Standup attendance check and add tools to manage the creation of different levels of advancement, integrated but all on their own timeline then you don't have Scrum any more. In 2015 the answer is so much better, richer and more evolved than just Scrum...

"Do business as if you were playing a game.  Have fun, know the rules, and when it's time make up your own..."  ~ Guy Laliberté - CEO Cirque du Soleil

Beyond Scrum - The Evolution of Software Development

It might have seemed unkind to sack Scrum and Agile development methodologies in my previous post.  After all, they are an improvement on the time-honored "Waterfall" method. Few know that their predecessor Waterfall was itself based on a mistake, a mistake so appalling that even it's inventor, Winston Royce, wrote in the paper that delivered Waterfall to the world:

“I believe in this concept, but the implementation described above is risky and invites failure.”

The bar was low, and Scrum and Agile methods easily cleared it.  We can't forget, though, that they were the products of their time, and many of the things they took for granted may have applied only during that tiny sliver of Internet-bubble time.    Let's take another look at the implied software development environment of the approach that I wrote up last time (paraphrased):

• We’re all co-located...
• We don’t know how to write requirements...
• Our leader doesn't work here / is a consultant...
• Our entire team are newbies, so we'll
  • let everyone own all the code
  • track performance daily with check-ins and velocity
  • eliminate any concept of seniority
• We’ll code in sprints that last from 2-4 weeks each
  • it’s only payroll
  • if its something big we’ll just have the sprints go on forever
  • everything can be fit into a 2-4 week sprint
• We'll deliver software at the end of each sprint.
  • the software doesn’t have to be great, just delivered

These assumptions might have been been fine for Internet-bubble days, but in 2015 and beyond we can do better.  We won't throw the (Scrum-)baby out with bathwater, but that implied Scrum environment is no longer valid for software development teams today.

"The real voyage of discovery consists not in seeking new landscapes, but in having new eyes." ~ Proust "Form follows function" ~ Ludwig Mies van der Rohe

Let's start with some new assumptions and our development approaches will follow:

1. The development team is distributed.   EVERY team is distributed, even if they are co-located!   Work-from-home vs. work in the office.  "Morning people" vs. Evening (or 2:00AM) people, "flu season."    The first rule of new development is to have everyone on the team work in the best environment for them. The second rule of software is to enough eyes, all bugs are shallow. We will need great collaboration tools for software review and pair programming.
2. Timely delivery is nice, but compelling delivery captures markets.    The Apple App Store is a microcosm of the software industry overall: your software might not have 1.5 million applications competing with it, but you surely have competitors and (as Bill Gates and Mark Zuckerberg can confirm), in large and small winner takes all.   If you write software you better be ready to put a ding in the universe, otherwise you and your "snowflake" will disappear completely.
3. Different components have different delivery schedules.   The transition to microservices is well underway, but until that transition is complete we will be writing software with widely varying levels of granularity.   Form and schedule follow function -- let the software determine it's own best delivery schedule.
4. Timing?  Long sprints and short sprints are false timings -- in 2015 we deliver software continuously (with Jenkins, and increasingly with Docker) and take advantage of the heartbeat that the regular old workweek gives our teams.
5. Fast-Track everything that can be fast-tracked.   The Project Management Institute has the right idea here - serialization is the enemy of compelling, continuous delivery.
6. "Pull" development beats "push".   Pull has revolutionized manufactured components, why shouldn't it also revolutionize conceptual ones?   If you want compelling delivery (per point #2), then you need a buy/sell market where the customer has the right of refusal.

These are the rules -- software has come a long way since the days of Chrysler Payroll.  Let's move forward...

"Scrum programmers are destined to code Scrum sprints for the rest of their lives, and thereafter." ~ John Repko (after Bertrand Meyer)

 

Fighting the Last War — Software Development Beyond Agile and Scrum

"If you don't show Kansas, Oz isn't all that special." 

~ Frank Decker, on adding a dystopian LA backstory to the movie Demolition Man

"Generals always fight the last war"

~ Edward P. Warner (1934)

1. The Scientific Revolution Ahead

For the next Jonas Salk to be a mathematician we need to use new tools to provide a mathematical focus on previously unsolvable problems.  Software lies between that vision and the practical world we live in, but software has long been a gap that has kept mathematical insights from becoming real world solutions.   We have 200,000+ clinical trials' worth of data in storage, but what use are they if you can't search them, analyze them for results and plan next steps from there?   "Big Data" is a catch-all term for the new kinds of analysis that are tailored to massive or genomic data sets, but our software deficiencies only start with wrestling the data.   The world ahead needs two things:  1) a way to channel the myriad human communications  (spoken, texted, emailed, webbed, blogged, fitbitted, jawboned and more) into an Interstellar-tesseract library for review,

and 2) a better way to write the tools and applications that we'll need to navigate and draw wisdom from that tesseract.

2. The World We've Come From

It's said that "generals always fight the last war," so it shouldn't be surprising that while big data tools are new, our software development approaches are still the ones we developed when "the internet changed everything."   Extreme Programming and the Agile Manifesto got us started, and the backsides of the manifesto authors is an appropriate image for how that manifesto suits us now in the Age of Analytics.  Time will make fools of us all, but the principles from 2001 read like platitudes now -- they are not wrong, per se, but a lot has changed since 2001, and we can choose better rules today.  Let's start with some things that have changed:

• Teams are more likely to be distributed now.   Daily stand-ups will have a different flavor when no two people are on the same continent or in the same time zone, rather than the same room.
• Web development has matured.   In the late 90's everyone was a "web newbie."   The game had already changed when David Heinemeier Hansson released a video building a weblog in 15 minutes, and even that is almost 10 years ago now.
• Web tools have matured.   Java, .Net, Rails, Python and PHP are old hat now, and RCS got replaced by Subversion and then Git as the tools raced ahead even faster.
• Communications tools are richer now.   By now most developers have video-conferenced with Facetime or Skype or Lync, IM'd with Yammer or Campfire, wiki'd with Sharepoint or Basecamp, and done code reviews through Git (or read the sordid code history with Git Blame).
• The competition to your software is a lot greater than it was then.   The godfather of agile methodologies, Extreme Programming (XP), was introduced in 1996 by Kent Beck when he was working on a Chrysler payroll project.  Chrysler payroll?   Not exactly the hair-on-fire environment that Jamie Zawinski lived in at Netscape, much less edgier parts of Facebook or Google.    Kent Beck 1) had an internal audience 2) who had no competitor software to choose from, and 3) couldn't effectively decline to use his software on release.    Apple iStore now has 1.5 million iPhone apps, available for review and updated continuously.    Kent Beck did great work, but the iStore represents a massively more competitive environment than he faced in Chrysler.

According to Conway's Law, modern software designs match the communication structures of the organizations that built the software.  Cobol mainframe software was thus the product of The Organizational Man age.  Here I'll posit Repko's corollary, which states that modern software methodologies match the prevailing organizational mores of their era.   Thus it was that 2000-era technology mores that gave us Scrum:

• Here in Payroll...
  • We're all co-located, so we'll improve communications with morning stand-up meetings
  • We don't know how to write requirements that are a) rigorous enough to be developed swiftly, nor b) flexible enough to stand the test of time, so we'll have a Product Owner that we can rap with on a daily basis
  • Our leader is a consultant who doesn't work here, so we'll define the role of Scrum Master and (like our consultant) that role will have power but not authority
  • Web development is new and Java is even newer, so our entire team are newbies.   We'll handle this by
    • letting everyone own all the code -- easier to spot problem-children, and to rebalance the team if we have to "cull the herd"
    • tracking performance daily with check-ins and velocity (what other profession monitors itself daily?)
    • eliminating any concept of seniority -- if nobody knows anything about web or Java, what's the benefit of seniority?
  • We'll prepare code in sub-projects called sprints that last from 2-4 weeks each
    • it's only payroll -- it's not like we're building an operating system or air-traffic control
    • if it were something big like an operating system, we'd just have the sprints go on forever
    • we don't have any functionality (like architectural advances) that can't be fit into a 2-4 week sprint
  • Our goal is to have deliverable software at the end of each sprint.
    • the software doesn't have to be good (or compete with a dozen similar apps on the iStore), it just has to be deliverable

It's not that I don't like Scrum -- it is easily grasped, it provides a structure to software projects, and it's a positive step forward from the Waterfall software development approaches that preceded it.   It is, though, the product of its times and environment, and competitive-market communications and advanced analytics software needn't be saddled with Internet-bubble-Chrysler-payroll software practices.

While better than nothing, many of the "agile" practices that comprise Scrum don't make a lick of sense anymore.   Their era has passed, and as much as people still bow to Imperial Science of Scrum and its Certified Scrum Masters, late-90's-payroll approaches just aren't going to cut it in 2015.

Scrum is the development methodology of the last war.  A quick note about the image at the header of this posting.   Many readers might suspect that the Pearl Harbor attack on December 7, 1941 may have been a turning point in naval warfare -- the specific point at which aircraft carriers (with their bombers and torpedo planes) became THE capital ship for Navy planning.   Some with greater perspective might even flag the earlier Battle of Taranto (Italy) of 11-12 November, 1940 as that turning point.  In fact we're approaching the anniversary of that turning point, the warfare revolution of its day, which came far sooner.

US General Billy Mitchell came out of World War I with the belief that his aircraft -- 1920's-era biplanes seemingly little-advanced beyond what the Wright brothers flew at Kitty Hawk -- could sink any ship of any navy, and he pleaded for a chance to prove it.   His bombers did surprisingly well in early tests, and so he was presented the ultimate challenge:   The Ostfriesland -- pride of the WWI Germany navy, due for demolition but still thought by many (stop me if you've heard this before) to be "unsinkable."   In an earlier effort, US Secretary of the Navy Josephus Daniels smugly proclaimed:

"I'm so confident that neither Army nor Navy aviators can hit the <ship> when she is under way that I would be perfectly willing to be on board her when they bomb her!"

Good thing he didn't.  He would soon discover the truth of Victor Hugo's words "No army can stop an idea whose time has come."  When the paradigm shifts, you're either on the right side of the shift or you are lost to history.    The first bomb fell at 12:17pm on that day 94 years ago -- July 21, 1921.  The 6 bombers came at two minute intervals, with the last bomb falling at 12:27pm.   The new era of warfare dawned just 13 minutes later, when at 12:40pm the mighty Ostfriesland slipped beneath the waves.

It's time to change the way we write software, and I'll write about that new paradigm:

Beyond Scrum -- The Evolution of Software Development

in my next posting.

 

Pathways

"Without [taking a process perspective of business], business improvement efforts amount to rearranging deck chairs on the Titanic.”

~ Michael Hammer & James Champy, Reengineering The Corporation

In the Beginning: Reengineering the Corporation

Back when I was a newly-minted MBA, client-server computing had already passed it's sell-by date but the Internet as we know it was yet to be born, so when I left school it was to do business-process consulting at Booz Allen & Hamilton. Process consulting was the province of McKinsey and Booz, Bain and BCG, but Hammer & Champy's Reengineering the Corporation jolted the business world when it came out in 1993. With Reengineering new rules emerged and lots of businesses started dabbling with reengineering.

Those days were not such a great time for Oracle Corporation; in fact Oracle nearly went bankrupt in the early '90s. Seeking a new executive team, Oracle CEO Larry Ellison hired Ray Lane from Booz Allen, and thence began the Oracle takeover of Booz's Information Systems Group: Ray Lane hired Robert Shaw, both hired their lieutenants who in turn hire their lieutenants, and in short order Oracle had about 40 new managers from Booz Allen, including me.

But what were we to do? To a new MBA it was obvious: Oracle had a lot of "hot" accounts that needed serious, young, suit-wearing professionals to keep Oracle from being thrown out of them. We were just the ticket, and a Business Process Reengineering (BPR) consulting group was born inside Oracle. The remarkable thing about BPR at Oracle is that, as misplaced as we were in a purely-techie company, we got really good at it! We started with Hammer & Champy and then wrote our own rules from there.

Our run as reengineering superstars was bound to come to an end, and did so around 2000 for a variety of reasons:

• Oracle V6 was leading-edge product and the Oracle Applications built on it didn't always work right. Oracle V7 and Smart Client apps were a much sharper effort, so our target-market of enraged clients and accounts simply dried up.
  
• Reengineering itself got a flood of new practitioners, who discovered that even if they didn't know what they were doing they could always just drive a bunch of layoffs and (courtesy of the same information flows that made our reengineering efforts) the organization would survive somehow while the consultant basked in the glory of the cost-savings.
  

Reengineering's death couldn't come a moment too soon, but many of the new reengineering ideas were good ones and are even better today in the advent of Advanced Analytics. The business world was so chastened by "reengineering" that many of these approaches were actively forgotten. Their rebirth has come -- from outside the business world. In 2015 it's time to ask: "Is there a doctor in the house?"

Pathways: Advanced Analytics and Healthcare

"In the next 10 years, data science and software will do more for medicine than all of the biological sciences together."

~ Vinod Khosla, Director, Founder and Partner of Khosla Ventures

In his book The Agenda, Michael Hammer defined a process as “an organized group of related activities that work together to transform one or more kinds of input into outputs that are of value to the customer.” These are simple words and early BPR practitioners probably never dreamed that such a simple idea could become synonymous with 'mass layoffs'.

But so it has, leaving behind a sometimes-insightful body of work in the process. To bring the magic back we have to start with the definition of another kind of process:

In biochemistry, a metabolic pathway is a series of chemical reactions occurring within a cell. In a pathway, the initial chemical (metabolite) is modified by a sequence of chemical reactions. These reactions are catalyzed by enzymes, where the product of one enzyme acts as the substrate for the next

Pathways in biochemistry are analogous to processes in business, but lack the taint that process reengineering wrought in the business world. Biochemist's ignorance really has been bliss, and pathways have brought lifesaving breakthroughs in the world of chronic myelogenous leukemia that I mentioned in my last post. We will start with Jim Collins' brutal facts then walk through the process, with credits to the National Cancer Institute:

• Prior to 2001, less than 1 in 3 chronic myelogenous leukemia (CML) patients survived 5 years past diagnosis.
  

• In 1960, Peter Nowell, M.D., of the University of Pennsylvania, and David Hungerford, Ph.D., of the Fox Chase Cancer Center in Philadelphia, reported finding an abnormally short chromosome in bone marrow cells from patients with CML. The tiny chromosome was quickly dubbed "the Philadelphia chromosome" for the city in which it was discovered.
  

• Not until the 1970s did researchers learn how the Philadelphia chromosome was formed. In 1973, using new DNA-staining technology, Janet Rowley, M.D., of the University of Chicago, discovered that chromosome 22 and chromosome 9 had exchanged bits of DNA. This phenomenon is known as chromosomal translocation—when one piece of a chromosome breaks off and attaches to another or when pieces from two different chromosomes trade places.

…things start moving faster now…

• In the 1980s, Nora Heisterkamp, M.D., then an NCI intramural scientist and now of Children’s Hospital in Los Angeles, and her colleagues figured out that translocation resulted in the fusion of two genes that created a new gene known as BCR-ABL.

• In 1986, Owen Witte, M.D., and his colleagues at UCLA discovered that this fusion gene causes the body to produce an abnormally active form of an enzyme called a tyrosine kinase that stimulates uncontrolled cell growth in white blood cells.

…A HA! Now we have a mechanism driving growth — the "Achilles heel" for cancer progression! If this highly active enzyme could be suppressed, CML might be treatable. Now we move to the endgame…

• By this time, Brian Druker, M.D., of Oregon Health and Science University, had already been studying tyrosine kinases as possible targets for precisely aimed treatment and he was focusing on CML as a promising disease to study … Because CML has a singular mutation, these researchers targeted this disease and began screening compounds developed by Dr. Lydon’s lab. Eventually, Dr. Druker found one compound, called STI571, that was more effective than others. This compound, which eventually became known as imatinib, would kill every CML cell in a petri dish, every time.

This is the approach that's driving a scientific revolution in healthcare, and can drive a similar revolution in business. The new approach is, loosely:

Here scientific advances were critical, but the path to victory over CML began with "screening compounds." The best-in-class were identified by the screen, chemically modified to enhance the desired properties (tyrosene kinase inhibition), and the winning compound became Gleevec.

We can adopt a similar approach with Advanced Analytics for a new era of business process revolution. Next we'll talk about how AA can drive new approaches to business.

The Path Forward: a New Look at Business Processes with Advanced Analytics

"We approached the case, you remember, with an absolutely blank mind, which is always an advantage. We had formed no theories. We were simply there to observe and to draw inferences from our observations."

~ Sherlock Holmes - The Adventure of the Cardboard Box

The wonder of BPR in its early days was the belief that if you could just draw up the right process — boxes and arrows and swim lanes — all of the business's problems would be solved. In fact, a great many businesses advanced by getting just such basic controls in place. Even though the image of "BPR" is tarnished today, the word did get out and in 2015 most businesses are at least modestly process-aligned. This is progress, but it's only the beginning.

Eli Goldratt, with his book The Goal accurately pointed out the problems with pure process-ness: All process-steps are NOT equal, and the path to the The Goal required us to a) identify the constrained steps, and b) exploit the constraints. This is also a real advance, but it too is not enough. In a world where processes are in place and the obvious rate-limiting steps have been removed, how can we still move forward? Even in our Hammered, Champied and Goldratted world, it's still all too common to hear:

We have processes and we have data. What we can't explain is why both our mean manufacturing cycle times and our on-time delivery rates are dropping!?

This is where Sherlock Holmes' observation above comes into play, along with another observation commonly attributed to Albert Einstein:

"We can not solve our problems with the same level of thinking that created them"

We can go with more boxes, arrows and swim lanes, but these are what got us to where we are now! We don't need more processes but we do need "new eyes" to discover new insights on our challenges. We already have metrics that describe the nature of competition in different industries; these can give us insights into where to look for new wins in existing business.

Let's consider some different businesses, such as high tech manufacturing, aerospace & defense, and consumer packaged goods. Each of these industries has key performance indicators (KPIs) that describe how they are run — at a high level an Aerospace and Defense company might have the same boxes-and-arrows for core Procurement or Fulfillment processes as a CPG company, but the nature of the two business could scarcely be more different and the critical KPIs for those businesses will be different as well. These key KPIs are where we'll use our new tools to start a new search for business advancement.

The following table shows how some major industries compare in the types of metrics we might look at every day:

Table 1. KPIs For Some Leading Industries

Let's consider this new "pathways" approach for a business that we know. "Rocketera" (a fictional company) manufactures embedded circuit boards for the automotive and aerospace industries. They are a skilled high tech manufacturer, but they also have some real business challenges to deal with:

• Their customers are major auto companies and defense contractors — big companies with JIT manufacturing and demanding delivery schedules
  

• Their suppliers are electronics companies in Taiwan and Japan — products are frequently revised and updated and delivery times for the most complex products can be long
  

• Materials management matters a lot to Rocketera — the length of the supply chain, short lifespan of components and the cost of those components makes supply chain monitoring more important in HT-MFG than in almost any other industry
  

• Rocketera targets a gross margin of 25%, and keeping gross margins with Moore's Law-era products means that Rocketera has to cut supplied costs by 30% each year — just to stay in the game!

This is just a sample case, but even with these first rough numbers we have a few obvious candidates for analytics and Advanced Analytics:

• We need better forecasts — here advanced analytics can supplement Rocketera's existing planning system by
  • Reviewing customer order histories to find signals that forecast unexpected orders
  • Tracking media sources on the growth and business prospects of its customers
  • Tracking political trends (as via 538) on key candidates with hawkish or dovish positions
  • Tracking social sources for customer and public opinions on high-profile products or customers
    
• Supply chain tracking is also critical — Rocketera can also update it's planning system by:
  • Reviewing supplier delivery histories to find signals that forecast unexpected delays
  • Analyzing the spot market (or setting up an exchange) for critical components
  • Integrating weather updates into supply chain planning for potentially-delayed shipments

The approach shown here is a general one, but advanced analytics with modern tools gives it a new relevance. Every industry group has it's own set of KPIs that describe the locus of competition, and by focusing on the KPIs that provide differentiation we can ensure that even small changes have magnified impacts. The great promise of Advanced Analytics is that it makes business advances possible — even in (in fact, particularly in) businesses that have already crossed their T's and dotted their i's in process and business planning. Done properly, an agile business can move data to information, and from information to wisdom. Pathways are the next step in business planning.

"The real voyage of discovery consists not in seeking new lands but seeing with new eyes."
~ Proust