Agile and Scrum versus the God Complex

Let’s Fire the MBA Bean Counters

For over ten years I have been questioning the viability of rigid process management methodologies and was ridiculed for ‘not getting it’. I have presented the scientific evidence around complex adaptive systems, the benefits of Systems Thinking, the heuristics of human decision making, as well as workplace psychology in terms of people motivation. I was and am still told that businesses are not interested in scientific evidence but in Return on Investment only and my response was and is that this is wrong. Customers and business people don’t care about ROI at all, therefore executives should put financial aspects as second priority as well. I have often complained about the short term financial perspectives forced upon businesses by stock market analyst expectations and the ubiquitous bean counters. Doesn’t anyone realize that this is why we have a ‘jobless recovery?’ But slowly, it seems that the tide is turning. I suggest that you read Car Guys vs. Bean Counters: The Battle for the Soul of American Business, in which Bob Lutz, the former Vice Chairman of General Motors, argues that to get the U.S. economy growing again, we need to fire the MBAs and let engineers run the show. Read an abstract in this TIME article.

BPM and the God Complex

BPM is sold to these bean counters as a top-down control methodology to reduce costs. As a way to define all the processes of a business in detail, it is weighed down by an immense governance bureaucracy that stops it from getting off the ground. I have asked often for proof that it does and I can only state once again that after 20 years of BPM implementations there is no statistical proof that all-out BPM is good for a business. People who do BPM as a fully blown methodology to turn a business into a predictable entity suffer from what economist Tim Harford calls ‘The God Complex’. They arrogantly think that they have it all under control and that innovation can be encoded into processes. Harford writes for Financial Times the ‘Undercover Economist’ column. Like me he describes the economy as a complex adaptive system that can’t be analyzed and fully understood. He proposes that the markets are far too complex and unpredictable to be controlled by expert opinions and says: “I’d like to see many more complex problems approached with a willingness to experiment.” In his latest book Adapt: Why Success Always Starts With Failure he suggests that we need to learn to make better mistakes by improvising rather than plan. He presents his perspective in this great TED talk: Trial, error and the God Complex

Process Evolution at the Edge of Chaos

There are those who claim that a huge BPM government bureaucracy represents process maturity and supposedly provides business agility. Excuse my French but that is pure BS with no evidence whatsoever. One can formalize change processes, but one cannot enforce innovation. I am not against BPM as a management principle that focuses the minds of its managers and employees on customer outcomes and helps them to structure their organization accordingly. It is a viable way to organize a business. But BPM must be no more than the organizing context on top of the adaptive complexity that the economy and the business represent. Everything else is a stranglehold of bean counters or shareholders. Businesses show the most innovation and dynamics when they are operating at what Stuart Kaufmann first called ‘at the edge of chaos’, that phase-transition from an unordered to an ordered structure — like water turning into ice crystals. Dynamics are only productive if they are sufficiently guided by goals. Order them too strictly and you kill the ability to innovate. The same problem does exist in software development.

Agile and Scrum for Software Development

In 1995 Jeff Sutherland and Ken Schwaber presented a formalized Scrum process for the first time to the public. In February 2001, Sutherland, Schwaber, Kent Beck, Alistair Cockburn, Jim Highsmith and Mike Beedle, and others, drafted the Agile Manifesto as a Declaration of Independence from the inflexibility of waterfall development. According to Sutherland, Scrum builds on the theory of complex adaptive systems in nature, “to deal with physical reality where things are often not linear, not simple, and not predictable. Scrum — by virtue of its iterative and incremental nature — mimics the biological instinct to survive through constant adaptation.”

Bursts of Innovation

While Charles Darwin assumed that evolution was slow and gradual, he did however not assume that the pace of change was constant as there was no fossile evidence. In 1972, evolutionary scientists Stephen Jay Gould and Niles Eldredge proposed a “punctuated equilibrium” meaning that long phases of genetic stability were interspersed by rapid bursts of change that resulted in new species. Genetic innovation to create a new species is not constant, but driven by a change in outside conditions that enforce adaptation for survival. Sutherland says, “When enough mutations occur in multiple parts of an organism, the system shifts to a higher plateau of functionality.” If seen as a methodology and not a mindset, Scrum can’t guarantee success, but it does push to assess progress and direction on an ongoing basis. That enables many small changes that result under guidance in these bursts of change that have the potential for substantial innovation. See my post on ‘The Complexity of Simplicity.’

The Core Principles of Scrum

Scrum was originally defined as a project management approach for very skilled people who don’t excel under strict guidance and are unable to utilize their creative abilities. What is interesting is that Scrum principles are virtually identical to the requirements of empowerment: Authority, goals and means!

  • Define work goals clearly by the intended outcome for the user.
  • The team interacts and discusses results with the user not management.
  • Teams are autonomous in work estimation, assignment and measurement.
  • Management doesn’t interrupt the team during a work cycle.
  • Management provides means and removes obstacles.

Nothing in the above definition says that this will only work for software development or engineering projects. It can and should be utilized anywhere. And I do not see the culture as a prerequisite.

Scrum as a Business Management Approach

I am fortunately not the only one and most certainly not the first one to promote such dynamics also for business strategy and management. Steve Denning is a bestselling author and thought leader in leadership and innovation. In The Leader’s Guide to Radical Management (Jossey-Bass, 2010), he shows that the future of management needs five fundamental shifts in terms of the firm’s goal, the role of managers, the way work is coordinated, and turning from value to values and from command to conversation. Denning says: “Traditional management has failed. To deal with a radically different marketplace and workplace, today the whole organization must be focused on creating a stream of additional value to customers through continuous innovation. This reinvention of management reflects an application of Agile/Scrum thinking to the whole organization.”

How Agile is LEAN?

There are some similarities of Lean to the concepts of Agile and Scrum. I see it however as firmly rooted in manufacturing and not for people-to-people interaction. It is still way too rigid and top-down driven. In particular I object to the proposals of motivating people with money for financial performance. It is scientific fact that this doesn’t work. Lean proponents also say that at first all the excess people ought to be fired. That is the worst way to start anything. Who is excess and why? What is well positioned in Lean and should be embedded in the Business Architecture is the concept of Value Streams. And by the way: Plan-Do-Check-Act is not a scientific method!

ACM Enables Agile and Scrum

Along the lines of my above convictions I created software to empower the people of a business to execute their processes transparently but at will. In 2009 at a WfMC meeting we decided to name such an approach ACM — Adaptive Case Management. Focused on knowledge workers only, I was not satisfied and continued to push for a more global, holistic business perspective for process management. Some progress seems to come about in that direction. So is ACM a concept, a problem domain, an integrated solution, a market fragment or even an ‘UN-solution’ as Keith Swenson suggests? It certainly was pitted against BPM for a while, which is both a business management concept and a market fragment. The conflict is not about products but about management concepts and therefore fundamental. Therefore it can’t be resolved. ACM follows the same ideas as Agile and Scrum and not the Tayloristic control illusion. We even do have a Scrum template in our ACM platform that we use for our inhouse Product and Application Lifecycle Management. Some say that ACM requires a change in culture, but as always I like to turn these ideas upside-down: ACM empowers the executive to bring out the best in his/her organization without enforcing processes or enforcing changes in company culture!

References, resources and interesting blogs:

http://www.targetprocess.com/blog/2008/11/agile-software-development-and-complex.html
http://agileconsortium.blogspot.com/2011/01/complex-adaptive-systems.html
http://theagileexecutive.com/category/complex-adaptive-systems/

21 Comments on “Agile and Scrum versus the God Complex

  1. You’re too kind with the “Bean Counters.” These are really, really corrupt.

    Like

    • Mary, thanks for reading and commenting. I wouldn’t go as far as to call them corrupt. I think misguided is strong enough? We do need the bean counting as well but they shouldn’t be running the company and defining strategy. Some of them have saved businesses from being innovative to the grave. So a kind of balance might be ideal. All the best, Max

      Like

  2. I agree BPM has been force-fed to executives and bean counters (big problems have to have big benefits after all…). I’ve was on the BPM software side for a long time and have seen the “God Complex” approach to BPM result in failure and disillusionment. On the other hand, I’ve also seen BPM done agilely with good results. I think you’ve made several important points in your post, but the thing that I take away the most is not that BPM or ACM is superior (different problems have different solutions after all…). It’s that business have to find that starting point, try it, measure it, and keep moving forward (thanks for the TED link). The West was won with agile scouts (after all).

    Like

    • Chris, thanks for reading and commenting. ACM is to me a holistic, user empowered kind of BPM. I don’t see the difference except that the BPMS technology requires a governance bureaucracy and ACM allows the business hierarchy on all levels to interact – executives add objectitves, managers define targets, peocess owners define goals, performers add their skills, and customer add the value perception! Now you have it all transparently in one place and no need to nail down all the processes in a rigid manner. Thanks, Max

      Like

  3. Hi Max,

    I did a short stint in the corporate world from 08-09 after my company was acquired. At the time, I was fascinated by the relationship between BPM and SOA. In particular, the view that SOA was both a technology and a way of doing business. As I understood the concept, BPM allowed for the design of business processes to achieve a particular objective. In theory, the process execution was performed by resources (people, technology, knowledge) provisioned and integrated from a global pool. This view extended SOA beyond the realm of application integration and made it part of the corporate wide effort to transform CAPEX into OPEX. Just curious as to your thoughts.

    Regards,

    Ken

    Like

    • Ken, thanks for reading and commenting. SOA-like data and content connectivity (for example with CMIS) is important because it makes the underlying silos transparent to the business user. If done right the performer can add data and content which is modelled in the repository to the processes on the fly. No IT needed who just supply the backend technology. The key is not in the orchestration, but in the user empowerment. Regards, Max

      Like

  4. Good one Max, and I totally agree.

    One wee thing I’ve found from the practice of Lean & Agile methods is that most starts out with SCRUM then trend towards Kanban – basically leaving even more freedom while finding the ‘time aspect’ of SCRUM to be (partly) superfluous as things cannot get done faster than ‘just do it’.

    As the time aspect was the core of the old school methods it seems small orgs trends towards Kanban faster than the large ones.

    Like

  5. Agree with your closing “. .ACM empowers the executive to bring out the best in his/her organization without enforcing processes or enforcing changes in company culture!”

    IMO this takes nothing away from making available structured processes using BPM where appropriate to manage hand-offs between steps (not mandate how steps should be performed) providing the environment also supports ad hoc “ACM” interventions.

    The end game is to accommodate any mix of structured/unstructured work to the point of allowing individuals to carry out all work as a series of ad hoc interventions if they wish.

    The environment can have background compliance checking/controls at key points to trip up those who overstep organizational boundaries, something Rupert Murdock’s empire might have found useful to have working.

    Like

    • Hi Karl, thanks for reading and your thoughtful comment. An unstructured or unpredictable process can still be partially structured or partially rule controlled. The question is how you organize it and make it available to the right people roles. My proposed way is to use goals and subgoals as organizing entities. People understand those because all our life is organized in little goals. All the best, Max

      Like

  6. Pingback: BPM Quotes of the week « Adam Deane

  7. I find it fascinating that a huge variety of (conflicting) ideas and approaches are all attributed to MBA’s. I assume that ‘MBA’ here means the person with the degree and not the degree itself.

    It seems as though people think that you are handed some sort of rulebook or that in order to walk you have to swear to use BPM (or whatever it is we are railing against at the moment.)

    The reality is that BPM was created by propeller-heads, not the big bad MBAs. Sure MBAs are largely ignorant (and sometimes over-confident) when it comes to technology but software vendors are where these ideas come from. A good MBA program teaches both the rigid top-down approach to project management and the more contemporary view. It doesn’t tell you which is the ‘right’ way.

    Like

    • Hi James, thanks for reading and commenting and I apologize for disagreeing with you. MBA can mean a lot and I know both kinds. The ones who really don’t need the title and the ones that have nothing else to offer. But it really represents a rigid management mindset, aka as bean counters. The rigid top-down appraoch to management and projecs andprocess implementations is REALLY THE PROBLEM! Life is not a project and human interaction is not a process. All I am saying is that MBA’s are using BPM as a cost-control tool which to them is ‘the right way’. Michael Hammer, a professor at MIT more or less invented BPM. Thanks again.
      Regards, Max

      Like

      • C’mon Max ;) – “human interaction is not a process”? That’s a tad narrow definition of “process” I’d venture, more of the MBA/Bean counter – or to be more precise – “industrial thinking” kind of definition or what?

        “A series of actions or steps taken in order to achieve a particular end” is what process is, including putting on shoes in the morning, bantering with friends and whatnot.

        But to loop it back – it’s that precise industrial approach to process that keeps IT back with it’s focus on the Easily Repeatable, predictable, linear and hence not trying to address the Barely Repeatable, unpredictable, ball of yarn processes that most of life and business consist of.

        Like

  8. Hi Max, long time no see. I really like this post. As Scrummaster and Kaizen Adept without the need for structuring everything in my path this really apeals to me.

    Thanks for taking the effort of sharing your thoughts

    Best Regards,

    Erwin Schmidt

    Like

  9. Pingback: The Park Paradigm - The Connected Company

  10. Pingback: Perspectives on Testing » The Seapine View

  11. Looking at the date on this blog I feel I’m coming to the party a little bit late :)
    Someone recommended this post and I’m glad they did, a well thought out logic.

    For me 99% of the time Agile is Lean, most (if not all) the ideas in Lean can be traced back to ideas in Lean. The bit that isn’t is the bit you’ve put your finger on: there is a bit of Lean which is perilously close to BPM/BPR, when people start getting value stream maps out and defining processes.

    I tend not to go in for the Adaptive/Complex systems metaphor, I prefer the Learning concept: its about learning, learning what works, what doesn’t, and true learning implies change.

    Some of the original BPR pushers realised that when things blew up, in a way the whole Knowledge Management movement was started by BPR. People thought they could map processes, “capture the knowledge” and encode it. Turns out things are just more complex than that.

    I sketched out an Agile approach to BPR a few years ago (http://allankelly.blogspot.co.uk/2009/10/agile-approach-to-bpm-bpe-bpr.html). Basically start small. This isn’t going to be popular with vendors or consultants because it denies them the “big sale” – its an incremental approach. (

    Perhaps that’s enough to damn me, if not this next bit is…

    I’ll take issue with your characterisation of MBAs, both as individuals and as courses. I have one, I never push BPM/BPM, I never rigidly define anything. I wasn’t taught that BPM/BPR was good, quite the opposite, I learned it was bad. Most of what I learned on my MBA I find entirely supportive of Agile and much of my practice is informed by things I learned on the course.

    I suppose its like any set of rules which people try to apply without thinking. My MBA didn’t seem to come with any rules. (And that most definitely goes for Scrum – and other Agile approaches but Agile is less well defined there.)

    One thing I did learn after I graduated: techies don’t like MBAs and MBA types don’t like techies. Techies get nervous around me when the learn I have an MBA and MBA-types don’t take me seriously when I say I (used to) code (too much else to do now.) There is a gap here and I still believe there is much for both sides to learn from the other.

    Like

    • Hi Allan, thanks for a balanced comment that I mostly agree with. As always any generalization is bound to be wrong for some of the spectrum.

      If it would be just my characterization of MBA’s I would feel guilty, but it still would not change my opinion that a majority percentage of MBA-educated people have no business or customer acumen. They are penny-pinchers because that is all they know. They have been trained that ‘measure to manage’ is the only way. Measuring is good, but it is not management. Management is about people and setting their goals, giving authority and providing means, while making them feel valued and secure. Planing and accounting are important but they are not management either.

      Much of LEAN, BPM, SixSigma, and other MBA concepts fail to take the real world dynamics and our inability to predict the future into account. Many companies who go under have been perfectly MBA-managed and I propose that often is the reason. Then it becomes a management failure and it is suggested that if the numbers would have been kept better the business would have survived. Survival has to do with adaptibility and not with planning or accounting accuracy. Surely, if you don’t know your cash strapped it will kill you. Having a lot of cash and not investing it into the future (staff and customers) will kill your business as well.

      Rules are also the simple way to manage a business. You set the speedlimit for the dumbest driver and you improved traffic in terms of statistics. All other consequences are ignored.

      Clearly a business needs both: a product or solution perspective in its strategy and an idea how it will make the business money. It is that part where techies often fail. They wonder why no-one comes running to get their wonderful product. MBAs on the other hand will say that the great customer service or the new product features are too expensive and cut into profits.

      We are living in times where cost-cutting (performed by MBAs) is the most common way to improve the numbers. The problem is that it starts a race to the bottom. The race to the top starts with spending money on better customer service and products. That is all I am saying.

      All the best, Max

      Like

  12. Pingback: Software Engineering Management Reading List | ReStreaming

  13. Pingback: Culture in the work place | Binarymist

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 5,327 other followers

%d bloggers like this: