The Agile Executive

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.

Footnotes:

[1] http://www.agilemanifesto.org

[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.”