17 November 2011

Riding One Syllable to Success

Flow.  Play.  Slow.

Although I haven't read nearly as much as I would have liked, over the past decade I've spent a lot of time with my nose in a book learning whatever I could about the many facets of XP, Scrum, Kanban and other Agile topics.  Over the past two years, though, my thinking has been markedly influenced by three single-syllable words and the books about them.

Back in early 2010, it was Flow.  I presented Confessions of a Flow Junkie at the Agile Ottawa meetup in January and again at the main Agile Conference in Orlando that summer.  I spent a lot of time delving into work by people such as Mihaly Csikszentmihalyi and Don Reinertsen about how to establish and maximize the flow of work, knowledge and learning through a team, group and organization.  While many of the concepts and practices were well known to me, I did learn much more about system thinking and took a much deeper dive into the world of Lean than I had up to that point.

Late in 2010, it was Play.  My wife had read Dr. Stuart Brown's book of the same name for a course she was taking, and suggested I read it.  It took me a good number of months, but I finally got to it and was immediately hooked.  Within the first 10 pages I had laughed out loud, cried and recognized myself in a lot of what Dr. Brown was saying.  I've always tried as much as possible to make work fun, but Play really drove home the need to use the techniques of play in order to foster creativity and help drive innovation.  Play also provided ways (or at least reasons) to break stagnant teams out of their funk.  It made it OK to have fun at that endeavour that takes nearly half our waking hours as an adult - work!  Indeed, I mentioned before in The "F" Word that every team with whom I've worked has valued 'fun' as something important to them in their work.  Dr. Brown's Play illustrates how that isn't only something pleasant, but from a business perspective it's quite lucrative - happy workers are productive workers, and it results in happy customers!

Finally, in late summer of 2011 I started reading Carl HonorĂ©'s (In Praise of) Slow.  Again, this was a book my wife had read for a course, but I have to admit I was skeptical.  Yeah, yeah... we have to slow down and live like organic-farming, granola-eating, Birkenstock-wearing hippies, yadda yadda yadda, peace, love, understanding and all that.  Then I saw something on the back cover of the book about the author receiving a speeding ticket in Italy (they have those there?!) while rushing to a meeting with one of the people he interviewed, and saw just a little of myself (really, only a little!).  So, I broke down and started reading it.  Again, there were many, many insights into a lot of what I was starting to feel was broken in how we worked and even how we lived.  I thought of a new ScrumMaster at a client who said one day,
All I want to do is not feel guilty for leaving work at a time that let's me be with my family.
She was by no means the only person who was feeling that way, and part of my job at that client as a coach was to accelerate their work even more... at least that's what her management thought!

Slow, the book, delved into deceleration in all aspects of our lives while keeping one foot in the reality of 21st century society.  Yes, we have technology and the ability to communicate like never before, but we don't always have to be 'on'.  We actually need to slow ourselves down at times in order to promote Csikszentmihalyi Flow, which goes back to my first single-syllable word.

While there was nothing specifically about software development in Slow, there were so many aspects of HonorĂ©'s message that apply.  Even teams, groups and organizations that successfully apply Agile processes such as Scrum can end up running in a hamster wheel, feeling like they can't stop to take a breath.  Nothing is further from the truth, and failing to do so is actually more harmful.  Like a golf swing, slowing down can lead to much more effective teams with the ability to deliver constantly in a sustainable way over the long term.

So, these three words - flow, play and slow - may seem simple (or simplistic), but they have much deeper meaning.  Focusing on them and making changes that promote each one can radically improve how a group works, not only today or this week, but for years.

Oh, by the way, I really don't mind organic food, actually like granola and find Birkenstock's quite comfortable. :)

9 November 2011

What I Do When Coaching

In the past few months I've seen more and more articles, discussion group entries and blog posts that talk about Agile Coaches using words such as charlatans, snake oil salesmen and '#@$!!!#$%$#' (I'm not exactly sure what that translates to, but I believe I can safely assume it isn't complimentary).

Of course, I have no control over what other people do to hang up their shingle as an Agile Coach, but I can talk about what I do as a Coach.

First and foremost, my job is to listen and listen a lot! From my initial meetings with a potential client to daily standups with teams with whom I've been working for weeks or months, I have to listen not only to what's being said, but how it's being said, and often what isn't being said.  Every coaching engagement starts with a discussion about what problem or problems the client is trying to solve.  Only then will I have the most vague idea of how to help, and even then I almost always don't have the full picture.  That leads directly to the second aspect of my job.

I ask questions... a lot of questions.  If you're annoyed by a toddler constantly asking, "Why", then there's a good chance I'm going to annoy you as well.  However, to be able to help I really need to ask all those questions.  Sometimes the answers alone are sufficient, but again I listen to how a question is answered, observe the body language, and look for avoidance or deflection in the answers.  Questions that are given direct, clear answers are usually things that either aren't problems, or at least the people are conscious of the problem and can find ways to solve them.  The hairy issues are the ones that are behind questions that people don't want to answer, or deflect the question using responses like, "It has always been like that here!", or, "That group never cooperates with us!", or one of my favourites, "It's above my pay grade to worry about that!".

The third aspect of how I coach is to challenge assumptions.  Again, this can annoy people, but I usually point out that someone has hired me because they believe there's a problem that I can help solve.  Why does your build take 15 minutes after a trivial one-line change?  Has anyone tried building on a local machine?  Has anyone tried optimizing the build scripts or partitioning the build such that you only have to rebuild a small fraction of the system after that one-line change?  Has anyone actually tried having teams work in a common work area?  Has anyone actually tried pair programming?  Did someone from management actually say to the teams that they shouldn't refactor code so that it's maintainable over the long term?  Has management actually said to the teams that they expect them to refactor the code in order to make it maintainable over the long term?  I could go on and on...

The fourth aspect is mentoring in any number of Agile practices.  I come from an XP background, so I'm often called upon to work with teams on technical practices.  I also do everything from provide ab initio training to teams and working with them directly for a few iterations, to simply acting as a sounding board for people who have been working in an Agile environment for a while and they want a different perspective on what they're doing.  In these respects, I'm an expert by virtue of my 10+ years experience, and I'm constantly learning myself!

Finally, the most important part of what I do as a coach is to work myself out of a job.  A single team should be able to fly on its own after a few iterations of coaching.  The most important things I help them with is learning how to reflect on their work and make their own improvements.  I can show them the mechanics of a process very quickly, but effective retrospectives are key to long-term and sustained improvement.  Lean principles are also a key aspect to this.  Essentially, I try to impart a mentality of "Things are good, but we can always find a way of doing better!"

On larger engagements with many teams, another way I work myself out of a job is to help develop an internal training and coaching capability for the client.  That allows the client to sustain the changes they have decided to make, and especially to tailor the training and coaching to their specific domain.  While I do learn a reasonable amount about a client's business domain during my engagement, there's no substitute for people who have been working in that domain for many years.  That perspective allows the internal coaches to provide better situational coaching that I might be able to do, because they already know the work, the people, the politics, possibly the code base, etc.  That said, looking back at my second and third points, my external voice can shake loose some assumptions about the current environment that an internal coach may see as issues or positions that can't be changed!

So, to summarize, here's what I do as an Agile Coach:
  • Listen
  • Ask boatloads of questions
  • Challenge assumptions
  • Teach/Coach Agile practices
  • Work myself out of a job
The length of an engagement can anywhere from a few hours to many months depending on the situation.  I had one client where I spent about 6 hours going through the steps above, because their actual need was relatively small.  Other clients have taken longer due to the number of issues, the number of teams and a combination of both.  There's no set formula for determining how much coaching a client needs, although it generally becomes apparent once the engagement starts.

So, yes I call myself an Agile Coach, and yes I specialize in helping teams to use Agile values, principles and practices.  However, the actual work that I do may not be to teach a client Scrum.  It may not be to show them XP technical practices.  It may not be to talk about Lean.  It does, however, always follow the steps above.

Now that you know what I do as a coach, if you think I can help then give me a call! :)