Monday, November 22, 2010

Comments on “No True Agile, No True Lean, No True Latte”

This post is in response to Jurgen Appelo’s “No True Agile, No True Lean, No True Latte”. I agree with most of Jurgen’s message in his blog but had a couple of thoughts along the way while reading it. I highly recommend you read it...while drinking a latte :)


WRT “There is no objective way of determining who is right and who is wrong”
As far as details and minutia go, I think I agree with you. However, in the broader sense I think we can safely agree that Agile and Lean (and maybe even Lattes) exist to help organizations deliver better value from their software development efforts.

While the word “better” is certainly not objective, an organization should have at least some understanding of what “better” means to them within their given context.

So, while I agree there may not be an objective way to find what practices/values are right or wrong, I would think an org should be able to tell you what is working for them and what is not. That should count for something even if it is subjective or relative or whatever.

WRT “[…] attributing relative weights to versions of the model depending on how often they are being referred to.”
So, this is an awesome way to sum up a good idea. This basically describes learning, or at least learning the way a neural net learns...which I’m sure you’re aware of being a complexity guy and all.

My key issue here is that the process of assigning weights to pathways to nodes of stored information is the process which is important for an organization to understand and continue to propagate. This learning is the key to understanding what pieces of the whole (aggregate model) work for the holistic organization in its context.

While I’m positive we don’t disagree on this, my concern is that the people who may need to understand your blog the most may take away from it that it’s possible for an “aggregate model” to get created and ironically become the One True Aggregate Model (or at least treat it as such).

WRT “It’s no use pointing out what an original document actually meant in the past”
I guess I half-disagree with this...meaning while I totally agree the main thing to focus on is the current best understanding of Lean/Agile, I also completely disagree that there is no use in understanding the original intent.

I’ve always liked the phrase “Those who don't learn from history are doomed to repeat it”. I believe it is important to understand that history. What was the struggle? What was the point? Are we solving the same problem? How have things changed? Is this still useful? All good questions to ask, but need a starting point or some beginning context.

So while I don’t think folks should just blindly assume past original intent is still applicable to current problems, I think it serves them well to know how things started as well as how we got to where we are now from there.

My Takeaway on Your Takeaway
I guess I’ll just go back to my opinion that the learning is the key. I don’t really think there is right or wrong, just better or evolutionary. I think the process of building one’s own aggregate model is the useful task, not the having of an aggregate model. So to that point I’m not sure if an “all models are wrong” stance is the best, but perhaps an “understand many models, adapt your own and keep adapting” would be better...although they may effectually be saying the same thing :)

One note on “context”
I know I’ve mentioned orgs doing things in context a few while I think almost everything needs to be considered in its context, I don’t subscribe to not trying new things because “that just wont work here” or “we’ve tried that before”.

Monday, November 1, 2010

So now I’m an Agile Coach...whatever that means.

So for those who don’t already know, I recently left my previous employer and have moved into a consulting position with Pillar as an Agile Coach and have been doing that now for just under two months.  So while I did a lot of what I would consider coaching at previous positions, this is the first time I’ve been hired to do it specifically.

Overall I find that I am loving what I do and look forward to all the various challenges and opportunities that present themselves everyday.  However, one thing I have discovered is that the title “Agile Coach” is a troublesomely nebulous term.  The sorta title where you ask ten different people “what is an agile coach” or “what does an agile coach do” you are likely to get ten different answers...or just the famous “it depends”.

In an attempt to help clarify the role and duties of an “Agile Coach”, below I’ve listed a few of the hats I’ve worn or feel I have been expected to wear over the past few weeks:
  • Software team anthropologist
  • Application architect
  • Scrum master
  • TDD Coach
  • Developer guide
  • BS caller
  • Business consultant
  • Behavioral psychologist
  • Staff aug. project manager
  • Product Owner
  • Furniture mover
  • Pragmatist/Realist
  • Executive coach
  • PMO advisor
  • Marketing advisor
  • Finance & Budgeting advisor
  • SDLC theorist
  • Software Craftsman
  • Group therapist
  • Team defender
  • Turok: Dinosaur hunter
  • Project portfolio planner
  • Test engineer
  • Assertive Team Leader
  • Motivational Speaker
  • Troublemaker
  • Driver of business value

So basically, after almost two months of doing it, I still don’t have a very clear definition or elevator speech to give someone :)

Something I have noticed is that I seem to be a bit different to some of the other Agile Coaches I have met in the past.  Specifically, I come from a very strong developer background and still keep one foot squarely planted in the technical arena.  I also have spent a lot of time studying (formally and informally) various aspects of business, economics, operations and project management, as well as organizational behavior.  So in short, I feel comfortable running the organizational gamut. Not all coaches are like this, but instead specialize in some area, and likely have deeper knowledge and understanding within a particular arena.

My personal philosophy driving my knowledge portfolio is to be a jack of all trades, master of a few ;)  At the end of the day, the dev teams are the folks actually doing the work to deliver value to the business and if I can’t interact with them on their level I feel I won’t be as useful and may have trouble gaining their respect and building trust.  Just as important however, is that those dev teams are operating in a business or enterprise that care about many other things.  If I can’t speak that language and advise on those topics I may not be as effective in facilitating changes, building bridges and closing gaps.

For me, I find having this breadth is important but maintaining an appropriate depth is of equal concern.  In some cases it is good enough to just be aware of a topic, in others you need to be able to hold an intelligent and informed discussion about a topic, in yet others you need to have a working, practical level of knowledge.  Experience will help you figure out what works best for you and the type of work you like doing.

So what is the point of all this?

If you are thinking about bringing in an Agile Coach, spend some time thinking about what your organizational objectives are, but realize you may need some outside perspective on what it is you are trying to undertake.  In my experience many organizational objectives are connected and it’s usually impossible to just tug one string without changing the entire tapestry.  Therefore I would tend to start with a generalist who can also help at the team level.  Review and revisit your agile adoption/transformation routinely and bring in specialists as needed.