The Agile Executive

Making Agile Work

Posts Tagged ‘Ken Schwaber

Balancing Agile – Guest Post by Alan Shalloway

with 3 comments

A fascinating difference exists between Agile and Business Service Management (BSM). Agile emphasizes continuous flow of value to the customer. In contrast, BSM focuses on the business – it aligns the deliverables of IT to the enterprise’s business goals. Subtle that the difference might be, the two methods evolved along quite different lines in spite of the common denominator – dealing with software.

In this guest post, Alan Shalloway – Founder and CEO of NetObjectives – discusses the implications of focusing on the business as distinct from focusing on the customer. His discussion is part of  a few thought-provoking threads he weaves around the Agile Manifesto. Alan perceives the Manifesto a product of the times. He thinks aloud whether today’s circumstances require a revised manifesto.

Alan is a man of passion. While I do not always agree with him, I have a lot of respect for his quest to find the deeper truths. Furthermore, I always learn from him. Whether you agree or disagree with the opinion Alan articulates in this post, “listening” to his thoughts is well worth your time.

Here is Alan:

The Agile Manifesto was a watershed event that has forever changed the landscape of software development.  So profound a positive impact of it has had, that few challenge whether it was actually correct.  Manifestos are often  a statement in reaction to something prevalent that needs changing.  This makes them very topical and temporal – and the exact intention needs to be restated when the landscape against which it was drawn has changed. The Agile Manifesto[1] states:

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.”

At the time of its edict, this was profound and well stated.  Too many software teams were:

  • Following a process dictated to them from outside their team
  • Managing according to an extensive set of artifacts that recorded where they supposedly were well before software existed
  • Were given a set of requirements to meet with little opportunity to discuss real needs (note, points 3 and 4 in the manifesto address this point in two ways – first recognizing that customer collaboration is necessary to discover their true needs and second that it is essential to take advantage of newly discovered information)

The manifesto represented a new paradigm from which to work – one in which the team would have better control over its destiny and where it was recognized that one had to make incremental, iterative movement towards one’s goals – both in discovering the true goal and in implementing it.

Unfortunately, the perspective from which the manifesto was created, or at least the methods which first followed the manifesto, have been extremely team centric.  Not a surprise, given the paradigm at the time gave development teams too little say in their own methods.  The impact of this has been, not surprisingly, success at the teams and difficult beyond the team. It is almost axiomatic now that companies will have successful team pilots only to bog down in their enterprise agile adoption efforts or even revert back to earlier methods.

I say “not surprisingly” because several things have been left out of the agile manifesto.  These are:

  • The role of management
  • The role of process
  • The role of planning
  • And indirectly, the role of guiding principles

It could also be said that the driver for agile development is misplaced.  I do not believe “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  This makes software groups customer driven, not business driven.

There is a subtle, but important difference. Basically, conscious or not, the Agile Manifesto is driven with a team-centric view of satisfying customers – business and management play mostly secondary roles. Unfortunately, there is a significant difference between customer driven and business driven (see the figure entitled Alignment with Vision of Business to the right).  This is not apparent at the team level (the team is supposed to satisfy the customer).  But definitely at the business level. Not surprising, however, since the manifesto is a team perspective it states things in terms of customer value.

Ironically, it is the over-focus on the team, however, that is robbing teams of one of their greatest tools.  Clearly any method must have respecting people and providing those doing the work the ability to choose how they do their work. But this does not mean that process isn’t essential or that attending to certain laws of software development is optional.  Rather it means that process can’t be imposed on teams since to do so would both rob them of respect and almost certainly be the wrong way to do things – who knows more about how to get work done than the people doing the work themselves?

But “Individuals over process” as the first line has come to be called, makes it sound like people are it.  I do not think so – and I think this mindset has caused a lot of damage in many ways.

There is great evidence that the best approach is not merely get smart people onto a team and have them figure out how to solve their problems.  They must be properly equipped to do so.  Just being smart doesn’t mean you can solve the challenges facing you.  This should be readily apparent, but in many ways, the Agile community has mostly ignored it. Actually, there is not really an Agile community any more – there are factions that have significantly different beliefs.  For example, XP has long recognized the need for technical practices in Agile while the Scrum community is only just starting to get into what these are.

However, except for the Lean/Kanban community, few Agilists seem to espouse discovering and following the laws of product development flow (or even recognize their existence).  This, in my mind, has led to the low rate of success in scaling Scrum to the enterprise*[2]. Ironically, it is the over-focus on people that leads many in the Scrum community to assert this lack of success is a lack willingness to take the effort to improve. This is not surprising – if it’s up to the team to succeed, then when they don’t it must be something wrong with the team or their management when they fail.  I think not. I think it is the lack of understanding of the principles of software development flow.

These laws are not new.  Don Reinertsen, in his iconic book Managing the Design Factory lays out much of the rules of product development.  His more recent book The Principles of Product Development Flow: Second Generation Lean Product Development he lays out 175 of these principles.

To me, true respect for people means that one must equip them with what they need to get their job done.  Our thinking in the Agile community should change from “People over process” to one of “People times process.[3]This phrase emphasizes that if either are low, you get a low productivity.  Process does not ensure success. But a poor process requires heroes to succeed.  We’d like good, motivated, well-intentioned people to be able to succeed.

Our new agile perspective needs to include an understanding of what teams need to know to do their work. This opens up a role for managers to actively help teams get their job done and to coach them when they have challenges or lose their way.  While I will always be thankful for the Agile Manifesto, I am looking for a Business Agile Manifesto that will expand the focus from the team to the entire enterprise.



[2] Ken Schwaber, iconic leader of the Scrum community has said that “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.”

[3] I first heard this from Don Reinertsen.  Before that I used to say “People plus process.”


Extending a True Epiphany

with 2 comments

In Agile Software Development with Scrum, Ken Schwaber describes a true epiphany he experienced as a result of his 1995 meetings with DuPont’s process control experts:

They [DuPont’s process control experts] inspected the system development processes that I brought them. I have rarely provided a group with so much laughter. They were amazed and appalled that my industry, system development, was trying to do its work using a completely inappropriate process control model. They said system development had so much complexity and unpredictability that it had to be managed by a process control model they referred to as “empirical.” They said it was nothing new, and all complex processes that were not completely understood required the empirical model…

… I realized why everyone in my industry had such problems building systems. I realized why the industry was in such trouble and had such poor reputation. We were wasting our time trying to control our work by thinking we had an assembly line when the only proper control was frequent and first-hand inspection, followed by immediate adjustments…

Based on this insight, I have since formulated with others the Scrum process for developing complex products, particularly software systems.

Fast forward to November 2009. During a lovely dinner in Boulder with Dean Leffingwell, we got into the subject of connecting Agile with ITIL. This conversation really registered with me. I actually recalled how years ago Ray Paquet characterized IT as a “continuous manufacturing” process. If you accept Ray’s premise, the chain {DuPont –> Scrum –> IT} is quite intriguing.

Re-reading Software Evolution recently, I was struck by the observation Tom Mens makes in the Introduction:

… due to the fact that the activity of software evolution is a continuous feedback process, the chosen process model itself is likely to be subject to evolution.

I can’t help wondering whether Tom’s observation applies to IT. If so, what are the implications with respect to IT operations and system management?!

Opinions please!

Four Principles, Four Cultures, One Mirror

with 8 comments

Click here for the slides of my keynote presentation today in Agile Roots. The following key points are made in the presentation:

  • The Agile Manifesto principles are considered timeless.
  • Application of Agile can create cultural duality/conflict. The core culture of the organization that rolls out Agile is not necessarily aligned with the Agile culture.
  • Successful application of the Manifesto principles needs to build on the strength of the specific core culture – Control, Competence, Cultivation or Collaboration – in the organization rolling out Agile .
  • Schwaber’s 75% failure rate estimate corresponds to attempts to change the core culture of an organization as part of the Agile rollout.
  • Success does not necessarily beget success in Agile rollouts. The interplay between scale and culture poses serious challenges to scaling Agile successfully.
  • The Agile infrastructure places a practical limit on the scope of the Agile rollout. Constituencies that are not able to use a joint Agile infrastructure are not likely to collaborate.
  • The fine points of one Agile method versus another are far less important to the success of an Agile implementation than cultural subtleties of the target environment in which Agile is applied.
  • Good Agile tools are likely to induce behavioral changes without necessitating major cultural pushes.


leave a comment »

Readers of Software Craftsmanship might recall the association made in the post between Beautiful Software and the Cluetrain Manifesto. With the 10-year anniversary of the debut of the printed edition of the Manifesto, Simon Owens interviewed three of the four authors. The book and the interview are not about software development – they are about the Internet. Yet the profound relevance  to Agile software development is nicely captured by Simon in one short sentence:

The writing stresses the need for authenticity above all else….

The imperative need to have authentic conversations with your Agile teams and key stakeholders is highlighted by Ken Schwaber in a recent interview on AgileCollab, as follows:

I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it… The intention of Scrum is to make [their dysfunctions] transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.

Better heed the good counsel of the Cluetrain Manifesto authors and Ken if your Agile software is in trouble. Backlogs and burn-down charts are no doubt important. But, they are no substitute for authenticity.

Written by israelgat

March 28, 2009 at 7:56 pm