Kurt's Blog

March 26, 2012

10 Observations About “Agile” Consulting

Filed under: agile — Kurt Häusler @ 6:29 pm

This week I noticed a lot of discussion on twitter, and mailing lists, and blogs about agile coaching and scrum mastering, and whether it is effective or not, and it just happened to coincide with some of the observations I had been making recently as well. I felt it might be a good idea to write down some of my thoughts on what works and what doesn’t regarding roles in the agile world, and how that can be reconciled with individuals or companies providing services as consultants in that space.

It should be noted that this is very much the beginning of a chain of thought, a few rough ideas, rather than a fully thought out final version of anything.

I think what started me off thinking about this is this blog post from Bob Marshall: Agile Coaching is Evil and Scrum Mastering is the work of the Devil.

What the link-bait title actually means, is that Agile coaches and Scrum Masters generally promise organizational change, but focus particularly on the way software development projects or products are managed. I am pretty sure there are a lot of coaches and Scrum Masters out there that either don’t promise such a fundamental change in the management culture, or they actually achieve organizational change by not focusing so much on they way teams develop software.

One other thing I find a bit shocking, but had heard before, was that actual coaches were conceding that it matches their observations. They only go for small improvements, slowly, and are happy when they occur. They simply don’t expect to see significant improvement. It always used to annoy me when I saw a tweet from a coach, very upbeat and excited to have such a great team of people who are “getting it”, and their whole lives have been improved etc. What I picture in my head is a complete turnaround, everyone is using all the technical practices, the managers are removing impediments and staying out of the way, and the CEO is Deming reincarnated. It usually means there was a little game during Scrum Training, and someone said something like “oh I see how that could improve quality” or something like that, but everything else is still just as crappy as before. Scrum coaches are really good at thinking positive and celebrating small victories, but I wonder if they might also be setting the bar too low. I wonder if their clients thinks a small “aha” moment is worth the tens of thousands in fees.

I started thinking about what this might mean for consulting companies, who might have experience in general IT or management consulting, but are new to the “Agile” world, or the radically different culture that lies behind the Agile values and principles (I am glad there is no umbrella term for this, as when it can be wrapped up in a term and sold, it stops working). So here are my rough ideas:

  1. Be clear about what we are offering. Are we trying to improve just the way an organization manages software development, or are we trying to fundamentally change the culture of the entire organization? Sometimes, in a software company for example, the difference might not be that clear, but I think it is still important to understand this difference.
  2. Be careful how we use the word Agile. There is an English word agile, with a lower case a, that means something like dexterous or lively. I don’t think it is that common. If we are dealing with software companies, or perhaps a company that has started using Scrum, and want more “Agility”. Then we are using the word Agile with a large A. It comes from the Agile Manifesto for Software Development, and it is software specific. There is no sense talking about the “Agile organization”, as if the values and principles used by small teams to deliver software were somehow portable outside that context. I don’t think it is helpful to turn around and say “I am not talking about the Agile Manifesto, I am talking about the English word agile”. If that were really true, and not an attempt to confuse people into linking it to the the benefits that the value system in the Agile Manifesto have brought to software teams, then why not use a word like “flexible”, or “swift”? There is I think a more fundamental value system or philosophy behind the Agile Manifesto that can be extracted and applied outside of software, but you can’t use the word Agile for that. It probably is hard to find a single word for that, but I am pleased, as it means it can’t be packaged and sold like a product for those looking for a step by step how to guide, as if leading cultural change were as easy as using a software product.
  3. Whether it is Agile software development, or some radical management ideas we are consulting on (I am thinking of using the word Radicalsville, inspired by this blog post.), chances are, a different pattern applies when compared to traditional IT consulting. From talking to colleagues, I understand traditional consulting to mostly be about experts or specialists that read all the books on a topic, go to the conferences, take part in community events, understand the theory behind, evaluate all the tools etc, so that the client doesn’t have to. One of the things that seems to be common in both Agile software development and Radicalsville, is the concept that it is not a destination, it is a journey. Rather than having a set of less relevant theories and values behind some concrete step-by-step method, what we are trying to convey are the values or theories themselves. The managers that we are training don’t have a step by step method they can use to “do whatever needs to be done”. They have to continually apply values, principles and theories to the current situation and discover their own concrete “methods”. Or at least stay in permanent contact to “the community”, and by learning about, and reflecting on the way others work, you can perhaps discover what sorts of things work, and which things don’t and use them as a basis for your own experiments. So if you are a manager, and want to get consultants in to save you the time of becoming an expert yourself, then think twice. If you can find such a consultant, what they are selling probably won’t be that useful, or it will come to a point where it may even make things worse. You need to either employ people who already work in a certain way, or you need to accept that a good consultant will just point you to the community, and a bunch of values and theories, and perhaps help you apply them in the beginning.
  4. Some roles are suitable for consultants, other roles are only suitable for more permanent employees (whether employed, or contractors). One of the other big differences between the traditional world, and Radicalsville (including Agile software development), is that a manager tries to stay out of the way and remove impediments, and slowly improve the system. This is probably cost effective for a permanent employee, as he is learning all the time, and contributing to the normal flow of customer value, in between system improvements. There are a number of roles like this, including Scrum Master, that are not cost effective for expensive consultants that charge by the hour. The external consultant in the role of Scrum Master has to find an appropriate level of engagement that might not suit the needs of the teams and/or the expected ROI. For example, on one side there is the need to continually deliver value in the form of process improvements or employee training. Process improvements get confusing if made daily rather than monthly, and employee training takes capacity away from their ability to deliver actual software (or whatever it is they are delivering). A Scrum Master spends a lot of time investing in his own knowledge, but for a permanent employee this is an investment. For an external consultant it is waste (for the paying customer) as it leaves when the consulting engagement is over. Much more effective would be to identify actual Scrum Masters employed by the company, and for external consultants to work with them as coaches on a part time basis. Generally I can’t think of many ways in which a consultant can be effective full time, unless perhaps it is a very large company, and the same workshop needs to be given to dozens of teams over a week or two.
  5. Learn how others in the community do things. I suspect one of the differences between the “evil” coaches in Bob’s blog post, and the good ones, is in how they themselves approach the job. I think the evil ones think of “Agile” coaching as just another type of IT consulting. The good ones see it as nothing to do with IT. They work more like sports coaches, or professional coaches. They focus on either individuals or teams, and they play with Lego. They are also well known in the community. I find they, like good Scrum Masters, focus on non-technical coaching. That is things like communication and teamwork. They are usually well aware of the cultural basis for Agility, and know full well that a radicalization of the management system is one of the main prongs to global effectiveness, and are often capable of targeting improvements in that area, should it be desired and/or required. I believe “Agile” coaches are very well placed for the needs of companies outside of Agile software development. What they do seems closer to cultural improvements than improving the way software gets developed anyway.
  6. Teaching technical practices is best done in my opinion according to the craftsmanship concept. This will typically involve cultivating mastery amongst the employees. Setting up a system that leads to them learning and teaching the technical practices themselves. This may require employing apprentices and journeymen who already express interest in clean code and craftsmanship. Slightly less effective would be to bring in a consultant to give workshops on the topic. Not economically effective would be to have a consultant there full time to work as a developer alongside the permanent developers.
  7. Every role should be done properly. Scrum Masters should not need technical skills, they should be full time (with no other roles), and they should only be in 1 team. They should focus on cultural and organizational impediments within or affecting the team, as well as organizational change, outside the team.
  8. I guess it does make sense to turn up full time at the beginning, for at least an iteration, or long enough to take part in all the relevant events of whatever it is they do, just to observe, and comment and prepare more focused part time sessions afterwards. I cannot see this full time observation period taking more than 2 or 3 weeks. Any given consultant should probably pick one area in which he will work in, and pick a role to either be, or shadow. Having too many hats on, and trying to take on too much cannot be a good idea.
  9. A consultant should never really have to “sell” anything. He should give his honest opinion, but he should remain neutral, not personally invested in the other parties acceptance of the idea. It is not as if you are a permanent employee, and have to live with a decision you disagree with. Plus we should always remember the lean principles of respecting people and trusting those closest to the work to know how it should best be done. Once you explain an idea, and it gets rejected, that rejection should be gracefully accepted. If you push too hard, and they end up feeling pressured to embrace your idea, and things go wrong, then it wont feel very good for anyone. Perhaps offer options, if it feels honest to do so, that makes people feel in control. As far as I know, some coaches don’t even go so far as to actually suggest things, preferring to set things up so that a client sees something and comes to his own suggestion.
  10. Sometimes things can be a bit backwards. Take Kanban for example, or Scrum. They both have some fairly simple rules, like chess, but they are hard to turn into real success. Also like chess. So what do the experts, i.e. trainers do? They go around teaching the rules, perhaps getting things started, then they leave. Leaving the client to face the hard bits alone. What ends up happening is that the expert consultants, focusing on the trivial rules of some tool, revert to a superficial understanding of it. They might even start to believe the easy bits are all there is. In the mean time, the client will try and solve his problems, and try and win a game of chess, by himself. He might fail, or he might succeed. In either case he will probably get some experience, and the market will reward him for becoming a trainer. Wouldn’t it make more sense for the people with a basic trivial understanding to go around teaching the basic rules of chess, and leaving the true experienced experts, the elite of the field, to actually get their hands dirty and win some games? I dunno, maybe part of being a consultant, or at least a trainer, should be a regular return to practice? I will have to think about that and write another blog post.

So I was going to write a bit more about specific areas of focus, and how they can best be addressed, but I will leave that for another post too.

Also don’t forget this is pretty much a beginners observations, I am sure I have got a few things wrong, so feel free to comment.

And sorry there is no pictures today.



  1. Hi Kurt,

    Thanks for referencing two of my recent blog posts. They sure do seem to have garnered a lot of interest. And I like your post, here, too.

    I am interested to hear your interpretation of the key point in “Agile Coaching is Evil” – seems like I have more work to do to make the real key point stand out more clearly.

    Some comments on what you have shared, above:
    1) Agreed. In many agile adoptions and the coaching engagements that often go with, I note a widespread tendency to not clearly describe the goals of the adoption/engagement.
    2) The single word I use to refer to “the more fundamental value system or philosophy behind the Agile Manifesto” is “Synergistic” (see “The Marshall Model” for more context – lots of info on the standing pages of my blog).
    3) Happy to hear that you find the term “Radicalsville” useful. Consultants are rarely schooled or experience in facilitating mindset shifts, particularly organisation-wide (when called-for), and managers and other folks are not generally keen on radically changing their view of the world, and the world of work, just for some local optimisation to go better.
    4) Goldratt has told us that external consultants are not a good choice for involvement in systemic improvement. cf the Jonah effect #TOCOT
    5) Please note the distinction between the sin (Agile coaching) and the sinners (Agile coaches)., As Gandhi said “Hate the sin, love the sinners”.
    6) I would defer the up-skilling in technical issues to eg a competent tech lead. Many times a client will naively expect the Scrum Master to do “double duty” to cover this role too. Not sensible imo.
    7) Very much agreed. But is this cost-efffective (in terms of ROI) when Scrum remains, as it so often does, a local optimisation with little impact on the bottom line?
    9) Almost the whole consulting industry is predicated on HAVING to sell things. This means consultants routinely dissemble, exaggerate benefits, downplay or ignore risks, and generally act against the best interests of the client. I agree ethically things should be otherwise. And very few indeed are the consultants that have even the vaguest awareness of the Synergistic frame.
    10) Agreed. In the Synergistic frame, regular visits to, or continual residence at the genba, is integral.


    – Bob

    Comment by flowchainsensei — March 27, 2012 @ 8:20 am

  2. […] 10 Observations About “Agile” Consulting (kurthaeusler.wordpress.com) […]

    Pingback by Agile methods do not fit every software development project | Svein Minde Blog — March 29, 2012 @ 11:55 am

  3. By the way, there is a relatively new book called “Radical Management” by Stephen Denning that brings Agile to the non-software world! It’s actually pretty good.



    Comment by Damon Poole — March 30, 2012 @ 7:50 pm

  4. Just adding a note here to help my poor memory. One other thing I want to clarify before consulting, is am I there because of my opinions and subjective beliefs (e.g. Agile is better than Waterfall, TDD is better than a design dreamed up in advance by an architect etc) and I bring therefore an agenda with me or I am there completely agenda free, and am expected to be objective (i.e. keep my personal opinions to myself) and neutral and support whatever agenda the client has? (If its the client’s agenda, it opens up the question of whether I am there to support the agenda of the boss paying me, or the agenda of the teams I am working with).

    Comment by Kurt Häusler — May 1, 2012 @ 5:27 pm

RSS feed for comments on this post. TrackBack URI

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: