Agile Anarchy

These days Tobias Mayer writes the blog BusinessCraftsmanship and has a new book available in May 2013, The People's Scrum.

[agileanarchy-blog]

Moving On...

Agile Anarchy, as an identity, has served me well these past three years, but now it is time to move on. I am less (upper-case) Agile these days—and perhaps even a little less anarchic. I have discovered more like-minded people these past years, so there is less to challenge, and a more to embrace as this motley collection of artists, right-brain thinkers, social activists, collaborators, and other deviants grow in numbers to collectively confront the outmoded 20th century ideas of how to conduct business.

My new blog, Business Craftsmanship will attempt to take a positive, proactive approach to furthering this cause. Please find me there, and join the conversation.

To end, here is the full list of posts on this blog, in reverse chronological order.

The Robustness Index Running into a common problem, again—deliver fast and maintain quality—a team of developers and I...

The Bully CEO Today I read, and recommended an article by a CEO entitled A Good Place to Work. Reading the article...

How to Write an Agile Job Ad A note to hiring managers and HR departments.Today I came across yet another job ad for a...

Seeking Consent Out of Agile2012 came this tweet, by Michael Spayd: “Inspired by Joe Justice: consensus is...

The Spirit of Change I haven’t had much to say on this blog over the past few months. I’ve discovered that...

Technology meets Literature At the beginning of this year, in collaboration with the publisher, Dymaxicon, I embarked on a new...

Mapping the Value Storm —A hasty post, based on a couple of tweets, and a short conversation at #SFAgile2012.1. Streams are...

Seeking Abundance Like many consultants in the Agile field I have always worked in a very collaborative way, building...

Integrity Test Interesting twitter dialog this morning about integrity. I suggested an integrity test for an Agile...

EuroSTAR 2012, Amsterdam I’m very happy to be taking part in this event. You can read my session descriptions by...

Timebox != Commitment Procrastinating this evening, I got lost in a long stream of tweets about timeboxing, fascinated at...

The Agile Explorer This post is a stream of consciousness, at 1 am, in a hotel room in Indianapolis.I had a...

Team Culture, Project Culture I’ve heard a lot over the years about how Scrum is inadequate for managing large projects—some...

Love your enemies “We don’t just fight against our opponents, we fight for them. This is a moral...

Top 5 Scrum Workshop Dont's There is a great framework for teaching people about Scrum. It is called Scrum. Oddly, many Scrum...

Thoughts on Coaching I wrote yesterday that I’m not a trainer. I am not a coach either (I am specifically not an...

Thoughts on Training I am not a trainer. I stopped using that term a while ago. Some partners I work with still bill me...

How to hire an Agile consultant Advice to clients.Agile is not a prescription. There is no manual. It is not about process, it is...

Lemon Sorbet This is a response to Bob Marshall’s recent post How to Spot a Lemon Consultant. I recommend...

Context Switching: Interactive Game Tried this yesterday at a workshop with business folk, to indicate the pain and confusion developers...

The Why of Scrum I presented this latest iteration of The Why of Scrum at a recent BayALN meeting in San Francisco...

Don't Build Teams In their spiritual classic, Compassion—a reflection on the Christian life, authors Nouwen, McNeill and...

The Soul of Scrum This article extends and refines the ideas presented in Dogma-free Scrum. Scrum was designed...

Paying Off Technical Debt I recently read Jim Highsmith’s excellent post Velocity is Killing Agility! where he writes: the Agile movement...

God is an Agilist I saw a comment on a blog I am subscribed to today—on an old post I had cast from my mind...

Dogma-free Scrum It has long been my concern that Scrum is treated as a process, or a set of things to do, and that the reason...

Scrum Gallery I stopped using powerpoint slides in my Scrum workshops in 2008, shortly after I had created a deck...

Project Management: A Malady Contrary to popular myth, Project Management is not a job, a profession or a career path. It is an illness...

Welcome to Agile Anarchy At its core, Agile is a philosophy, a way of thinking specifically about the work environment, business goals...

[agileanarchy-blog]

The Robustness Index

Running into a common problem, again—deliver fast and maintain quality—a team of developers and I discussed how we might create visibility around this without having to get into long explanations about about technical debt with non-technically-minded people. We came up with the robustness index. Not a new idea, I am sure, but one that is worthy of mention nonetheless.

The business want features delivered quickly. (I am unable to determine exactly why the speed they seek is so important, but that's a longer-term dialog.) The developers want to have a robust codebase in order to write bug-free software, and have a sense of pride and personal satisfaction with their work. These goals are inherently in conflict. Often, there are shortcuts that can be made to deliver the software quickly. This, as we all know, will add to our technical debt, possibly adding new problems, and causing future slowdown. But sometimes the business determines this is necessary, and find it easy to close their minds to the concerns of the developers, viewing, skeptically, their desire to have clean code as "gold plating".

This team uses story points to determine effort. I'm not going to comment on that here—it works for them at the moment, up to a point. The business often push back and say, e.g. that's a thirteen? surely not! and the developers, tired of the same dialog over and over, cave and say, well, maybe it's an eight. And then they rush the work to meet the goals. Yes, I know all of this is riddled with dysfunction, and much work needs to be done before the dialogs become healthier. But remember, this is where they are now, and not well supported by upper management. They need to do something different, and this is their interim solution to raise awareness.

The developers decided to add a robustness number alongside the effort number. Robustness is measure on a scale of 1-10, where 1 is total crap and 10 is the kind of code quality a good developer seeks. So now a story may have multiple effort estimates, each accompanied by a robustness number, e.g. for one story the estimate may be 5-4, 8-7, 13-9. The message being, yes we can do it quickly, and this is what you will get: fast delivery, unstable result. If we do it more carefully (and slower) it looks more like this: greater effort, greater robustness. The hope is that data-loving business people will be moved by the number, whereas they have not been moved by the emotional pleas. The quality and robustness reflects on them, of course, and no one seeks to offer shoddy product.

This is not a solution, merely a way to help understand the risks associated with "being agile", where the term is understood to mean "being faster". The team plans to try this system in their next iteration, so I have no idea if it will be effective or not. I like the idea though, and am keen to see if it has any effect. If I get to follow up with this team, I'll write write an update.

Related post: Paying off Technical Debt

[agileanarchy-blog]

The Bully CEO

Today I read, and recommended an article by a CEO entitled A Good Place to Work. Reading the article quickly, as I sometimes do, given the multitude of blogs I am daily faced with, I concentrated on its core message: Being a good company is an end itself. This aligned with my current thinking. There is so much focus today—especially in the Agile world—on getting product out of the door, and keeping customers happy that we often neglect the greater goal of a purposeful, meaningful work place.

The CEO's tactics to get there however are very much out of alignment with my preferred approach, and my recommendation was met by some of my twitter followers with incredulity, disappointment, confusion, and a raised eyebrow. I defended the article (or perhaps myself!) based on my primary focus, but to be fair, my crtitics were right to object. The CEO acted like a bully, using intimidation and threat to get his way.

Still, it gives me pause for thought, and takes me on another track. Who is really in the wrong in the described scenario? I come down on the executive who was spoken to so aggressively. What does he do? He just takes it, with a yes sir, no sir, kowtowing demeanor. The CEO is behaving in the best way he knows how, based on his (described) upbringing. He is not in the right, by any measure, but worse, he is enabled in his behavior by his employees. And that, right now, is what's interesting to me about this article.

The CEO was unkind, that is clear. Less clear is the unkindness of the executive. It is easy to feel threatened, intimidated and hurt by someone in power. Most of the time those so affected simply take it; they carry the burdon, building up resentment and indignation, and poisoning the enviroment still further. The responsibility for change is not only on the people in power. That's too much to ask. It is on us, each one of us, regardless of position or pay scale. Until we stand up for ourselves, and strive to change our own behavior to support our own ideals we'll continue to perpetuate—and even exacerbate—the existing dysfunction. 

The CEO has a noble goal. And he has a lousy technique for getting there. As employees we can seek to draw such people into dialog, rather than pandering to their anger. Tough job, no doubt, and it runs the risk for us of being fired. The risk of staying however is far more damaging, to ourselves, our oppressor, and to the world.

So thanks Dave Rooney, Ron Jeffries, Mike Sutton and Bob Marshall for confronting me today. It gives me a chance to reflect, and to learn to consider more carefully what I endorse.

[agileanarchy-blog]

How to Write an Agile Job Ad

A note to hiring managers and HR departments.

Today I came across yet another job ad for a ScrumMaster—sadly posted to an Agile online group. Here it is, in its essence. I have bolded the terms that especially jarred, but the tone of the whole thing was seriously misguided. So here is an example of how not to write an Agile job ad.

Our Client is seeking a Program Manager/ScrumMaster within their Marketing team.

Responsibilities The contract Program Manager will drive timely execution of multiple projects. The team operates in an Agile environment utilizing Scrum methodology. The person will serve as the ScrumMaster and lead op mechs such as backlog grooming, sprint pre-planning, sprint planning, daily scrums, and retrospectives. The resource will also be a program manager, with activities such as providing portfolio metrics, such as burn down charts and utilization, communication, risks assessments, and resource planning. The person will need an ability to switch easily between different projects. This position will operate within a PMO which has program management standards and procedures, and where consistency and scalability of process is important.

Tools  • Well versed in a Scrum tool -- Rally preferred  • Microsoft Project, PowerPoint, Excel, and Word 

This ad, like so many others, describes an old-think, left-brain organization attempting to paste Agile on top of what appears to be a deeply embedded command and control culture. The sad thing, however, is not the job posting itself—we can forgive ignorance and misunderstanding—but rather that people calling themselves Agile Coaches (or similar), people claiming to understand the paradigm, will apply for this job. It is sad, and it is wrong. Each time a so-called Agilist applies for a job of this description we perpetuate the myth, and endorse the Agile-as-band-aid mindset.

If you are truly seeking an Agile solution, an ad of this kind will attract the wrong people. You will get exactly what you ask for: compliant people, mired in old-think, who use the term Agile to sell their services without understanding its core values and principles. 

This is an example of how I'd like to see organizations in search of Agile solutions write job ads:

Help! We are struggling. We can't get our software out in a timely fashion, and our workers are frustrated and demotivated. We think Agile may be able to offer some relief. If you understand how to listen, engage people, and reduce bureaucratic overhead, please get in touch so together we may explore possibilities of change.

More generally an Agile job ad would contain three elements:

Admit failure

Express the problem (as best you can)

Invite dialog

That's it. No specifics, no solutions, no directions, no assumptions, and no requirements for certifications, specific skills, or tools! Try it. You may be surprised at what occurs.

[agileanarchy-blog]

Seeking Consent

<✄﹣﹣﹣﹣﹣﹣﹣﹣﹣ This article has been removed. An edited version appears in the book, The People's Scrum, published by Dymaxicon, May 2013. ✄﹣﹣﹣﹣﹣﹣﹣﹣

[agileanarchy-blog]

The Spirit of Change

<✄﹣﹣﹣﹣﹣﹣﹣﹣﹣ This article has been removed. An edited version appears in the book, The People's Scrum, published by Dymaxicon, May 2013. ✄﹣﹣﹣﹣﹣﹣﹣﹣

[agileanarchy-blog]

Technology meets Literature

At the beginning of this year, in collaboration with the publisher, Dymaxicon, I embarked on a new project designed to engage and foster creativity within the software community: 113 Crickets.

"113 Crickets is a Silicon Valley-based literary journal published quarterly. Each issue contains a selection of prose, poetry, and short stories by new and established writers. 113 Crickets embraces its Silicon Valley roots by especially seeking writers from the tech world, and featuring published authors and poets with connections to the Bay Area."

During my travels as an Agilist, to different countries, companies, and conferences I have met many people who are striving for something greater than the day to day drudgery of work, people who are seeking to weave love, faith, art into their lives in a holistic, all-encompassing way. Gone are the days when we talk about work/life balance. It is all life. And today we strive for joy within the workplace, not only outside of it.

The Agile community offers a home to many artists, writers, musicians and philosophers. We are attracted by the spirit of community, the collaboration, the daring, the risk-taking. We share ideas about work, for sure, but we also share ideas about living well, about striving for excellence. We seek beauty and passion in the workplace, and we seek engagement—a quest far greater than the old-think, patriarchal approach of imposing "fun" at work through embarrassing team-building exercises, foosball tables, and company picnics.

This is the age of art, the new renaissance. It is a time for building loving relationships, for seeking collaboration over competition, for exploring outside the narrow confines of job titles and career paths—seeking greatness, and embracing the core human values of community, love, and purpose.

Music, painting, poetry, philosophy are integral elements of Agile software development and workplace democracy. We find we can be engineers /and/ artists, businessmen /and/ craftsmen. Our talents and passions need not be pigeonholed, our minds not bifurcated. Indeed, the apparently disparate elements of our lives can inspire and serve one another, creating a wholeness, a congruity, and a truth that will shine and serve as awakening to others.

The first issue of 113 Crickets featured the inspirational poetry of the Agile coach, Siraj Sirajuddin, and the forthcoming summer 2012 issue includes an interview with poet-coder, Liz Keogh, along with a collection of her work. We are always seeking new writers within the software and business worlds to contribute, as we move forward with this project, gathering the patronage of many innovative and creative companies along the way.

Please check out our blog at 113crickets.tumblr.com — and buy the books!

[agileanarchy-blog]

Mapping the Value Storm

—A hasty post, based on a couple of tweets, and a short conversation at #SFAgile2012.

1. Streams are uni-directional, they don't have feedback. It's an odd metaphor for knowledge work. [twitter ref] 

2. Consider mapping the Value Storm: starts from single input, behaves wildly and unpredictably, settles to a new state, changed by itself. [twitter ref]

I'm trying to picture a visual map for a Value Storm. We start in calmness. Someone has an idea—this is conception, a trigger moment. Sometimes the idea fizzles, other times it gathers momentum. Much will depend on the environment, and the prevailing conditions. The idea gets lifted up—accepted. The weather bureau issues a storm warning, but with very little detail. We enter a period of uncertainty. Some ideas will move swiftly through the uncertainty, with little to disrupt the system, and settle gently into to completion. Other ideas will cause chaos. Our map could show the dangers we are in with each idea-in-progress being displayed at some position, or with some indicator showing the severity of the storm. And this will change in the life cycle of the idea as it moves from acceptance through to conclusion. Each idea will settle into a new future—a future altered by itself.

I clearly haven't thought this through, and it may be a storm in a teacup (pun fully intended). It's late, I'm about to drive to LA through the night, and I'm done for now. If this inspires you, annoys you, or causes some other emotional or intellectual response, please add your thoughts to the comment section. I may expand on this another time. Or I may not.

[agileanarchy-blog]

Seeking Abundance

Recently I have taken this idea a step further and have begun recommending direct competitors (for want of a better term) even when I am able to take on the work myself. It isn't that I don't want the work—I do, but I also want the client to make an informed choice, in line with the set of recommendations made on this blog a few weeks ago—see How to hire an Agile consultant.

What I am seeking here is to build a climate of abundance. Competition, as we know, creates a climate of scarcity, pushes prices down and drives clients to focus on cheap, rather than good. I believe there is more than enough work to be shared amongst the high quality and integrity-driven Agile facilitators, coaches and consultants, and by collaborating not only will we create an economy of generosity, but we may actually find that consultancy rates increase. Our clients will be moved to seek true business value over simple monetary value, and to focus on quality over quick fixes—exactly the mindset we want to foster in those building software.

I have just made my third offer which included a recommendation to talk to a specific Agile consultancy before deciding who to engage. The last two recommendations included a representatives name and email, to encourage the action. I consider locality, among other dimensions, when making a recommendation. Local consultants can best support a client on a long-term basis. I also do my best to make a recommendation for agencies and individuals I know well, or who have achieved a good reputation in the Agile space. So far I haven't lost any work—in fact, even if I did, is this really a loss? If my true goal is client satisfaction then a potential client choosing a better alternative could be considered a win, rather than a loss.

We live in interesting times.

[agileanarchy-blog]

Integrity Test

Back in 2009/10 I was still a Certified Scrum Trainer, but unhappy with the certification model. For this and a few other reasons I began offering WelfareCSM courses, aimed at unemployed software professionals, using a pay-what-you-can model. There was a recession going on, and some people were struggling. The CSM—much as I didn't like it—could help people find employment. I offered these courses essentially free. But "free" is a misleading word. There are always rewards. In this case I asked the attendees to bring along a friend who was engaged in work outside the IT field. I wanted to explore the idea that Scrum was a framework that could be utilized in other contexts. A few attendees of WelfareCSM went on to practice Scrum in areas such as Architecture, Legal, Curriculum Design, Scientific Research, and Organizational Development. The "Scrum Beyond Software" event was born from this period too, and from that various events spun off, including the Science Unsummit.

Rewards abounded.

Today I don't teach any kind of certification course. Even with the idea of giving it away I couldn't find peace with the model. It undermined my personal integrity. Instead I facilitate workshops rooted in values and principles, and I coach, guide and support organizations towards Agile change. I get paid for this work—and paid reasonably well, compared to the majority of USA citizens.

When a new client contacts me I rarely—almost never—ask myself the question, would I do this work for free? With a new client I have little idea what I am walking into, so the answer would inevitably be, I don't know. Which isn't yes. If I used the yes/no criteria to decide if I took work on I'd never take any work on. I need to earn a living, and I'm always curious as to what a new opportunity will bring. The initial engagement becomes a two-way assessment.

There are some clients who invite me back. Then I ask myself that question, would I do this work for free? If the answer is no, it is a warning to me that I shouldn't take on the work. It will be painful, will lack truth, and is unlikely to make either me or the client happy. 

If the answer to my question is yes, I know that I have found a client I can truly become engaged with, and if the worse happened and they decided not to pay me, I wouldn't be hurt. The reward is in the work, when the work is taken on with an open heart, and a true passion.

I have been much influenced recently by Charles Eisenstein's Sacred Economy video. Here he talks (among other beautiful ideas) about making offers to clients without an agreed price, and letting them choose their own price after the event. Or pay nothing if they are dissatisfied. This is a gift-giving economy. My colleague Pascal Pinck has practiced a similar model with clients, and I'm hoping he'll comment here with a few thoughts.

Do I want to work for nothing? Of course not. I want to earn a fair, living wage. And I also want to find work that is fulfilling and aligns with my life values. I don't want to work only for money, as there are many other ideals to strive for. I plan to explore the gift economy concept further over the coming year. There is something here of great value—something that aligns beautifully with an Agile mindset.

[agileanarchy-blog]

EuroSTAR 2012, Amsterdam

I'm very happy to be taking part in this event. You can read my session descriptions by following the links below. Click the image above to view the whole program.

Games for Collaboration & Innovation

The Why of Scrum

[agileanarchy-blog]

Timebox != Commitment

<✄﹣﹣﹣﹣﹣﹣﹣﹣﹣ This article has been removed. An edited version appears in the book, The People's Scrum, published by Dymaxicon, May 2013. ✄﹣﹣﹣﹣﹣﹣﹣﹣

[agileanarchy-blog]

The Agile Explorer

<✄﹣﹣﹣﹣﹣﹣﹣﹣﹣ This article has been removed. An edited version appears in the book, The People's Scrum, published by Dymaxicon, May 2013. ✄﹣﹣﹣﹣﹣﹣﹣﹣

[agileanarchy-blog]

Team Culture, Project Culture

<✄﹣﹣﹣﹣﹣﹣﹣﹣﹣ This article has been removed. An edited version appears in the book, The People's Scrum, published by Dymaxicon, May 2013. ✄﹣﹣﹣﹣﹣﹣﹣﹣

[agileanarchy-blog]

Love your enemies

"We don't just fight against our opponents, we fight for them. This is a moral movement…" — Van Jones

This quote is from a 2011 Van Jones speech, available on youtube. Whether you like or dislike the man who said this, it is a powerful and interesting statement, a new way of looking at conflict, perhaps.

It isn't that we want to convert people (at least, I don't) but by following our hearts and our instincts, rooted in our collective experience and millions—perhaps billions—of hours of dialog and deep thought, we believe there are better ways to serve the world than focusing on profits, rewards, hero-cultures, quick fixes and silver bullets. By continuing to do what we do, everyone will benefit. And even if many continue to hate the ideas, they will find their lives are better. This is the promise of the ever-growing community of new thinkers, writers and activists within which Agile finds its home.

"But I say to you, love your enemies, bless those who curse you, do good to those who hate you, and pray for those who spitefully use you and persecute you"  — Matthew 5:43-48)

[agileanarchy-blog]

Top 5 Scrum Workshop Dont's

And yes, I know it is usually unwise to focus on negatives [ref], but sometimes one just needs to clean out the crap before our minds are able to take on new ways of thinking and behaving. Smart readers will turn these statements around and draw out the positive. It's there, hiding :)

1. Don't plan the whole workshop.

Big upfront planning is anathema to Scrum. We seek lightweight, flexible visions and architectures that can change on the fly according to market changes or technical innovations/restrictions. Teaching Scrum from a plan is not teaching Scrum at all, it is playing safe, and it is imprisoning yourself and your group to an imperfect outcome. Instead, have a workshop goal, and a lightweight framework. Run workshops in iterations, allowing for reflection and replanning between each. As the workshop progresses, let the participants drive the direction. Allow for the workshop goal to change.

2. Don't ask questions you already know the answer to.

This technique is widely used. It is both fear-driven and patronizing. Fear-driven, because the facilitator is always safe, never taking any risks, always knows the correct answer. Patronizing because it treats people like children, vying to get the gold star in class. Avoid putting your participants in a teacher-pleasing position. Only ask a question if the answer will help inform you, as a facilitator, to better understand the context you are working in.

3. Don't play games with predefined outcomes.

For one, you'll get bored pretty quickly after a few repeats of these. And your mind will become closed to possibilities. Play open-ended games, where the process of the game itself—different every time—will inform the participants. Catch learning moments as they happen, and allow time to explore those. Enter each game as if it is entirely new to you. Because it is. Scrum is about people, not repeatable process, and no two people, not two groups will ever behave the same under the same guiding principles, or rules. Invent variations on games as you go, take risks, be prepared to fail... and use that itself as a learning moment for all. Especially, don't play predefined outcome games you yourself have not experienced as a player. This is disingenuous, and you will only be able to facilitate with an academic mindset. Playing open-ended games you have not played yourself is fine, as you are a player and risk taker in this process.

4. Don't answer questions.

Especially don't answer "How" questions [ref]. These are usually asked as challenges, and attempting to answer them will likely lead to positioning and entrenchment. Instead of offering answers, whether from intuition or experience, seek instead a better question—there is almost always one or more of those lurking below the surface. A classic example is the "How do we manage bugs in Scrum?" question. This is not a useful question, a better one being "Why do we have bugs?" [ref].

5. Don't talk about yourself.

Frankly, no one cares. Spend the time finding out about the group instead. Ask challenging questions. Seek to understand, rather than to be understood. Keep case studies and stories from experience to a minimum. These moments are more about your own ego than any real learning. Teach from a principles and values perspective, not a solutions perspective. Ask about the experiences of the group members, and use those as pivots for exploration.

[agileanarchy-blog]

Thoughts on Coaching

Here's a story, a tangent... Several years ago my wife (now ex-wife) and I went into marriage guidance counseling/therapy. The therapist had an agenda: to make the marriage work, to help us stay together (my wife had the same agenda). We were in counseling because our relationship was broken. We wanted to mend it, but I don't know that having a single goal was the best approach. It closed down all other possibilities. A better goal, perhaps, would have been: let's discover how to be the best co-parents to our children, and build a loving, respectful relationship. It allows for the "make the marriage work" outcome, but it is not bound by it.

My wife and I divorced in 2008. We now co-parent by email. It is horrible. I don't blame the therapist, of course, but the fixed agenda only served to make all other possibilities unpalatable for my wife. It became an all-or-nothing situation, and ultimately a lose-lose outcome. So what's my point? 

Agendas. That's my point. Agendas are restrictive and damaging. The term Agile Coach has a built-in agenda: Do Agile, or Be Agile, or Agile Will Fix Your Organization. This is a bad start. Agile is only one approach to improvement, and depending on how the word is understood, can be more or less limiting. It is always limiting to some degree.

And even more so than training, the term coaching is wildly overused and abused. Organizations now offer coaching certificates, e.g. the Scrum Alliance's Certified Scrum Coach (CSC), as if having that piece of paper qualifies you to serve well. It doesn't. And people without that certification are calling themselves coaches too. There is no real distinction in terms of quality. Coaching is the buzz-word of the decade.  

There is a real discipline known as coaching. Here is an invitation to coaching from  New Ventures West, an integral coaching organization:

We invite you to deepen your connection to yourself and others, contribute what you can to the lessening of difficulties, and unfold into the person you can be. Sooner or later life brings events that require us to reexamine who we are, what we're doing, and why. Personal change—like growing older, shifts in relationship, or job displacement—or societal changes—in politics, economics or technology—can bring us to these moments of reflection. How we listen and respond to this call determines how fulfilled we will be and whether we will make our unique contribution to the world. 

You'll notice there is no agenda there, nothing about tools, techniques or methodologies. There is no solution, only an opening up of possibilities.

When I go into an organization—to assist, one always hopes, in creating engagement and effectiveness—I don't know what the organization requires. I do know they are not happy with the way things are. And too often the presenting problem is not the real problem at all. Our work isn't in offering solutions, it is in helping people see in new ways, to identify those hidden issues that prevent the organization and its people in reaching self-actualization (ref Maslow). How can I do that if I come in with a prescribed solution?

But Agile Coaching aside, I am not a coach as I have never studied coaching, and apart from an introductory workshop I lack a coaching education, so have minimal knowledge of the skills needed to be a coach. Guiding and mentoring teams and individuals is not coaching—it is guiding and mentoring. These are different things. Offering Agile understanding and helping teams implement certain practices is also not coaching, it is advice and suggestion.

I don't know what term or terms to use to describe my work when I am onsite with a client, but coaching, I know, is the wrong term. It is disingenuous of me to use it, understanding the little I do understand about real coaching, and respecting greatly those individuals I know personally who do this for real.

I am not against coaching. I respect the discipline, and perhaps some day will study it. I am against Agile Coaching, as I believe this is just another cynical, "jump on the band wagon" effort to make lots of money. Agile Coaching is quite likely, in most cases, simply a Coaching Shaped Object.