Leadership coaching – the best investment I have made in myself.

I have just wrapped up 6 months of coaching with Stacey Sargent from Connect Growth and Development, and it was such a great experience. I wanted to capture some of my feelings so that I could always remember how much of a difference it made.

Why do leadership coaching?

I was lucky enough to be given a yearly budget from my company ThoughtWorks to use for personal development. Some people spend theirs on a far flung conference or books or the odd workshop, and I’d been pretty rubbish at using mine at all in the last few years.

Right now I’m in that middle zone of transitioning to a “leader” on my teams, no longer content with not being able influence the direction of the project and the people on it and starting to feel brave enough to dip my toe in the responsibility that is official leadership roles. I needed a push!

I wanted to focus on my own growth and development. Spend time thinking “What it is that I want?”, and “How to get the best out of myself?” so that I could get the best out of the people and the situations around me.

I have quite a high EQ but sometimes it can be overwhelming, so I wanted help learning how to manage this. I wanted to know how to be a calm, confident leader that people can look to in times of stress and uncertainty. Most of the time I project a very positive, passionate and energetic persona, whilst sometimes I’m actually feeling panic, doubt and uncertainty on the inside. I wanted to feel on the inside what I seem like on the outside.

I wanted to be able to have the tough conversations that I need to have with people to build good relationships, I shied away from personal confrontation.

To work on these things I figured I needed dedicated effort and practice to do so!

How to find a great one?

Find someone who knows what they are doing, and that you have great rapport with. You need to be able to trust this person enough that you will be able to be honest with them, and not be afraid to say the things that maybe you haven’t said out loud before.

For me it was helpful that Stacey did not work for the same company I did. It really provided some unbiased outside perspective.

Work out if you feel like you would need to physically meet up with your coach or if you would be able to be build your coaching relationship remotely, over Skype or some other tool.

I actually had been lucky enough to attend two sessions that Stacey had run at a couple of the Grace Hopper Celebrations that I had been at, and knew that she now runs a coaching company. So called her up and asked.

How did it work?

We would meet twice a month, on Stacey’s suggestion. My first thought was “how am I going to find the time?!” But actually, that frequency provides you with enough focus and reminders to be constantly thinking about how you can be growing.

As I live in London and my coach was in Seattle, we managed to find a time that suited as both, I chose Monday evenings as it helped me start the week off right. We would Skype for an hour or so. I think neither of us were sure how coaching remotely would go, but actually it worked out better than either of us had expected. I’m not sure it would have worked so well over just the phone. With the camera on it was much easier for Stacey to see my physical reactions and to see me squirm when I wasn’t giving an honest answer to myself!

There were days when I was grumpy and upset, and there were days that I was super energised and positive. Sometimes we would work on helping out my immediate situation and other times a more long term high level look at my goals and growth.

What did I learn?

I got an enormous amount out of these 6 months. I think the headline is that I know so much more about myself now.

Having a better understanding of what my strengths and values are gives me something to always check my trajectory with.  This helps me know when and how to push myself. If I’m in a situation I’m uncertain about or wondering if I’ve pushed too far, I can do a sanity check to see if I’m still holding true to my values, and if I am then to be brave and keep going!

We spent quite a lot of time coming up with the goals for my growth. It took many iterations, but what we came out with in, really hit all the key areas and may not have been what I was originally thinking they might be. Having these goals will help me be more intentional about the choice that I make.

One of my goals was to have an answer to “What do you want to do? What to you enjoy doing?”. So I looked back at my previous experiences with a very open mind and thought about what the things were that motivated me, or that I really enjoyed, what did I not enjoy so much, and I came out with 4 things that create an environment that I can really thrive in. This has really helped me to have conversations about how my company and I can put me into situations where they will get the best out of me. A benefit for both them and me! Having these concrete ideas and showing the process that I did to come up with them, has helped me start very rational objective discussions.

Training your brain to be more introspective. It takes a while to get used to analysing why you do what you do. Getting into the habit of it takes practice. During the start of my 6 months coaching, Stacey would have to ask a lot of questions before I would finally realise what the underlying motivations were to a certain situation. By the end, I could almost complete the whole loop before the problem statement had even come out of my mouth.

Along these similar lines, I have always had a bit of a self deprecating tendency. I often slip back into it when going into new situations. Again though, by the end of our sessions I could normally catch myself and consciously turn it more positive. The next step is to not even think it!

We also would work on more tactical aspects when needed. If I was experiencing a particularly tough situation or relationship at work, we would talk through in depth. Thinking about why it was happening, what could I do about, how best to approach it.

I have gotten better at being brave enough to have conversations that I might be afraid of. Approaching them with more structure, thinking about them, and practicing them before I have them.

I am a fairly emotional person, but can also be quite rational. These two sides of my brain were at war with each other. I thought that I needed to be more rational and try and squash my emotional side. I realised though, these sides combined are who I am. It is what makes me me. It is also, often, what makes me very effective. So I am trying not to react but to be intentional with my conversations and actions.

What helped?

  • I love learning
  • I am happy to throw myself into uncomfortable situations and to doing things in a different way to help myself grow.
  • My coach and I had a great rapport and high levels of trust
  • Stacey was not afraid to call me out if I was slipping back  into old habits
  • Regular contact kept me focused

In conclusion…

I feel like I know myself much better than I did before.  I have much more confidence in who I am. I understand and have come to terms with what I bring to the table on a team.

I’ve realised that to be the best leader that I can be I have to be my own unique self and work hard to work out what that is. I can lead with my own style while staying true to what I value in both myself and others.

As I am in the early stages of my leadership journey, my learning is currently more focused on myself. I’m hoping that soon, after I have more practice, I can have another go and change my growth focus to how to get the best out of the people that I am leading.

It was a truly great experience and I am thankful for having the opportunity.  I am very grateful to Stacey and all her hard work, understanding, passion and patience.

I would very much recommend making this investment in yourself if you want to grow into a great leader.

Speaking Event – The Science of Diversity

Myself and two of my colleagues will be talking about the science of diversity and whether diverse teams are better than non diverse teams….
If you are in London please come along! http://www.thoughtworks.com/events/science-diversity
——————————————————
ThoughtWorks would like to invite you to meet with us at an upcoming event. Please share!
 
ThoughtWorks deliver software to people with ambitious missions and we’re looking for talented techies to join us. We value diversity and on 18th November we are hosting an evening with our CTO Rebecca Parsons who will be taking a scientific and technical approach to answer the question ‘are diverse teams better?’ 
 
There will also be an opportunity to network and find out about careers with ThoughtWorks. 
You can register here - we look forward to meeting you!
Please contact Katie kpartridge@thoughtworks.com @katielisa52 for more details.Inline images 1

Creating C# .Net Websites in IIS with a Powershell Script

I created this little script to automate the creation of websites in IIS. It’s written in powershell.

You will need to run this script in powershell thats running in Administrator Mode.

Prerequisites:
You will need to have .net installed.

Step 1 Loading the Web Administration Module

This script is using the WebAdministration module to do the creation and removal of websites. To be able to load this module before it runs my powershell script I create a .cmd file that I would call that would load this module and then call my main powershell script.

install_website.cmd

powershell -executionpolicy remoteSigned -command import-module .\PSCommon\WebAdministration;.\install_website.ps1

Step 2 Creating the main .ps1 script

Create a new script, I called mine install_website.ps1. I put mine next to my install_website.cmd.

install_website.ps1

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i

$website_name = "MyWebsite"
$website_source_directory = resolve-path "..\MyWebsite"
$website_virtual_directory = "IIS:\Sites\MyWebsite"

$app_pool_name = "MyWebsite_AppPool"
$app_pool_virtual_directory = "IIS:\AppPools\MyWebsite_AppPool"

$sub_application_name = "SubApplication"
$sub_application_source_directory = resolve-path "..\MyWebsite.SubApplication"

Function CreateWebsite {
 New-WebAppPool $app_pool_name
 Set-ItemProperty $app_pool_virtual_directory managedRuntimeVersion v4.0
 New-Website -Name "$website_name" -PhysicalPath $website_source_directory -ApplicationPool "$app_pool_name" -Port 8082 -Force
 New-WebApplication -Name "$sub_application_name" -Site "$website_name" -PhysicalPath $sub_application_source_directory -ApplicationPool $app_pool_name
}

Function RemoveWebsite($app_pool_virtual_directory, $site_virtual_directory, $website_name){
 if (Test-Path $app_pool_virtual_directory){
   $webSite = Get-Item $site_virtual_directory
 if ((Get-WebsiteState -Name "$website_name").Value -ne "Stopped") {
   $webSite.Stop()
 }
 $poolName = $webSite.applicationPool
 $pool = Get-Item "IIS:\AppPools\$poolName"
 if ((Get-WebAppPoolState -Name $poolName).Value -ne "Stopped") {
   $pool.Stop()
 }
 Remove-Website -Name "$website_name"
 Remove-WebAppPool -Name $poolName
 }
}

RemoveWebsite $app_pool_virtual_directory $website_virtual_directory $website_name
CreateWebsite

As you can see I have two functions. One creates my website and associated app pool, the other removes it if it already exists. So I can run my script multiple times without a problem.

CreateWebsite, first sets up a new app pool, sets its ManagedRuntimeVersion to v4.0, creates a new website and then we also needed a sub application below that, so also sets that up.

Automating WebPageTest with a Ruby Script

WebPageTest is a great tool for seeing how well your website is performing. I was just on a project where the speed of a particular results page loading was the focus. How long the server took to respond, how long the UI took to render, what it was rendering, and where there were places for optimisations. We also wanted to measure the users’ perceived page load time.
We wanted to create an automated test that would run regularly so that we could track changes in page load over time.

Reasons why we picked WebPageTest

  • Ability to test any URL we wanted (ourselves, competitors, etc.)
  • Multiple browsers that can be used to test pages
  • Multiple locations and line speeds to test from
  • Can be automated (they have a REST API)
  • Ability to pin point a particular DOM element to measure load time of. For example we might consider the user perception of the page load as when there are 10 results on the page.
  • Provides a waterfall of all the objects loaded onto the page so that we can look for optimisations.

We set up the following to prototype (read: not production quality)  a top line measurement tool that the business could use to see how performance was tracking from a users perspective. With only a week of these tests running we found 3 issues that had been causing major problems with the page load time.

Where to start?

WebPageTest provide a RESTful API that we can use to interact with them. You will however have to host your own  private instance of WPT to be able to automate public URLs. You will also have to set up an agent for that instance to talk to.

Follow this guide for more information Setting up a Private Instance of Web Page Test. We set up  a couple of Amazon EC2 boxes for ours. (Make sure you pick at least Small rather than Micro)

Once you have that setup you should have a private instance of WebPageTest and URL that you can use to start manually testing your website.

For the purposes of this example I am going to test the BBC news website… I also used Ruby for this script. This was my first ever time creating a Ruby script for something like this, so keep that in mind!

These are some steps you can follow to build up a scripted test, and then store the results in a MongoDB for analysis later.

Step 1:

Call your instance of WebPageTest with your URL of choice and get back a 200 response

#!/usr/bin/env ruby
require "net/http"
require "uri"

test_url = "http://www.bbc.co.uk/news/"
baseurl = "http://[WEB PAGE TEST SERVER]/runtest.php?runs=1&f=xml&fvonly=1&url=#{test_url}"

response = Net::HTTP.get(URI(baseurl))
puts response

At this point you should get a response that looks something like this:

<!--?xml version="1.0" encoding="UTF-8"?-->

  200
  Ok
  <data>
    130723_9Y_BM
    d93f0a316369c61a891428dfb8b071d97b3dd19b
    http://[WEB PAGE TEST SERVER]/xmlResult/130723_9Y_BM/
    http://[WEB PAGE TEST SERVER]/result/130723_9Y_BM/
    http://[WEB PAGE TEST SERVER]/result/130723_9Y_BM/page_data.csv
    http://[WEB PAGE TEST SERVER]/result/130723_9Y_BM/requests.csv
    http://[WEB PAGE TEST SERVER]/jsonResult.php?test=130723_9Y_BM/
  </data>

WebPageTest will asynchronously run the tests and dump the results into the locations returned above. As you can see there are lots of different formats that you can consume for the results data. Everything that I needed was in the summaryCSV.

Step 2:

Parse the URL to get the summaryCSV and then poll that until the results appear (as we have no idea of knowing when they will appear I checked every 5 seconds until I no longer got a 404 response). I then parse the CSV response into a 2 dimensional array, where the first array are the headers, and the second is their values. You can then see all the results that come back and which ones might be interesting for you.

#!/usr/bin/env ruby

require "net/http"
require "uri"
require "nokogiri"
require "csv"

test_url = "http://www.bbc.co.uk/news/"
baseurl = "http://[WEB PAGE TEST SERVER]/runtest.php?runs=1&f=xml&fvonly=1&url=#{test_url}"

response = Net::HTTP.get(URI(baseurl))
doc  = Nokogiri::XML(response)

csv_url = doc.at_xpath('//summaryCSV').content

uri = URI.parse(csv_url)
http = Net::HTTP.new(uri.host, uri.port)
req = Net::HTTP::Post.new(uri.path)

while((csv_content = http.request(req)).class == Net::HTTPNotFound)
	sleep 5
end

raw_results = CSV.parse(csv_content.body, {:headers => true, :return_headers => true, :header_converters => :symbol, :converters => :all})

puts raw_results

Step 3:

Great! Now I have test results coming back and I want to save the ones I’m interested in so that I can visually represent them later and look at the changes in performance over time.
I’m going to use mongoDB to store the results of the tests. I created a class called TestResult with the fields that I am interested in from my WebPageTest results.
At this point you will need mongoDB up and running and you will also need a .yml file to define your mongoDB setup.
mongoid.yml

development:
  sessions:
    default:
      database: web_page_test_results
      hosts:
        - localhost:27017

My scripts now looks like this:

#!/usr/bin/env ruby

require "net/http"
require "uri"
require "nokogiri"
require "csv"
require "mongoid"
require "chronic"

Mongoid.load!("mongoid.yml", :development)

class TestResults
	include Mongoid::Document

	field :timestamp_of_test, type: Time
	field :load_time, type: Integer
	field :time_to_first_byte, type: Integer
	field :csv_url, type: String
end

test_url = "http://www.bbc.co.uk/news/"
baseurl = "http://[WEB PAGE TEST SERVER]/runtest.php?runs=1&f=xml&fvonly=1&url=#{test_url}"

response = Net::HTTP.get(URI(baseurl))
doc  = Nokogiri::XML(response)

csv_url = doc.at_xpath('//summaryCSV').content

uri = URI.parse(csv_url)
http = Net::HTTP.new(uri.host, uri.port)
req = Net::HTTP::Post.new(uri.path)

while((csv_content = http.request(req)).class == Net::HTTPNotFound)
	sleep 5
end

raw_results = CSV.parse(csv_content.body, {:headers => true, :return_headers => true, :header_converters => :symbol, :converters => :all})

TestResults.create({
	:timestamp_of_test => Chronic.parse(raw_results[1][:time]),
	:load_time => raw_results[1][:load_time_ms],
	:time_to_first_byte => raw_results[1][:time_to_first_byte_ms],
	:csv_url => csv_url
	})

And my mongoDB happily contains the result of my first test, which will look something like this

db.test_results.find()
{ "_id" : ObjectId("51eef7cee055e6cee5000001"), "timestamp_of_test" : ISODate("2013-07-24T21:38:04Z"), "load_time" : 3566, "time_to_first_byte" : 317, "csv_url" : "http://[WEB PAGE TEST SERVER]/result/130723_RW_CN/page_data.csv" }

What next?

If I had had a chance to extend this, I would of loved to of added visualisation, using a graphing framework and deploying the results to a web service so that everyone can see the change over time and drill down into any of the suspicious looking results.

The fear of blogging about technical topics…

I rarely blog about technical topics, despite my main trade of being a developer. The prospect has always scared me, and from others that I’ve talked to I’m not the only one.

The irrational thoughts that tend to go through my head are:

  • What right to I have to blog about technical stuff?!
  • Major case of Imposter Syndrome
  • What do I know that the internet doesn’t already?!
  • Will people judge me about what knowledge I do have?
  • What if  I’m wrong?!

Wonder if anyone else finds this too?

Well, we have to embrace whats scary to grow. So I have set myself a target of at least one technical blog a month.

These are my mantras to help me feel more confident about it

  • We are all always learning. There will always be people that know more about something than you, but there will always be people who know less. Things that I find useful when I am learning WILL be useful for other people who are learning.
  • If I had to hunt about on the internet for half an hour to find out how to do something,  if I can give an example that might save someone  haf an hour of googling, then I have made a tiny difference.
  • I must embrace feedback! If people leave comments, and share other ways that I could do things better, I should embrace and learn from these.
  • I am not ever pretending to know everything… these are just things that have helped me and I hope they might help others.
  • I can put things down here, so I can remember them for next time.

Here goes!

I’d love to hear any thoughts if you feel the same about technical blogging, or even better if you used to, and how you got over it.

The Retrospective Handbook by Patrick Kua

The Retrospective Handbook

One of my colleagues at ThoughtWorks published his first book last year called the Retrospective Handbook. It’s a great tool for people thinking about facilitating or wanting to hone their skills facilitating Agile retrospectives.

You can buy it here on Amazon or on Leanpub

I thought it was great… I’ve listed out here some of the things that the book covers that I really liked.

  • The right context for Retrospectives
    • The effect that team dynamics and environment have on the success of a retrospective
  • Lots of practical advice
    • How to prepare and set up a retrospective. Right down to the kinds of pens and paper best to use.
    • Lots of examples of language to use in specific situations
  • The importance of independent facilitators and advice on what to do if thats not possible and a team member facilitates.
  • Great tips for facilitators
    • How to help achieve equal participation from everyone.
    • How to handle anti-patterns from participants
    • Importance of observing body language as a facilitator and realising that there are many more things to ‘listen to’ of you participants that just what they are speaking out loud.
  • A whole section on Distributed Retrospectives
  • Your job is not done once people have left the room. There are a bunch of necessary things that need to get done after the retro is over.
  • 8 Common retrospective smells

Stand-ups – We can make them better…

I’ve been thinking about how to get the most out of stand-ups. They are something that all the teams that I haven been do every day, but  how often do they actually meet the real goals of a stand-up? I spent some time thinking about how, instead of just rattling off the usual status update, we can really think about how to best use this time. Not only to communicate  with and learn from the team, but also how to provide that daily re focus on what the team needs to do today to get awesome features into the hands of users. I propose some different questions to think about and frame your updates with during stand-up.

While I was hunting about the internet looking for inspiration, I came across Jason Yipp’s article on Martin Fowler’s Blog – It’s Not just Standing Up. There’s loads of great stuff in there, but specifically what jumped at me was the goals of a stand-up.

 The Goals of the Daily Stand-up are GIFTS

There are several goals for a daily stand-up  meeting:

  • To help start the day well
  • To support improvement
  • To reinforce focus on the right things
  • To reinforce the sense of team
  • To communicate what is going on

As a mnemonic device think of GIFTS:

Good Start, Improvement, Focus, Team, Status

I also came across this from Agile Coaching by Rachel Davie and Liz Sedley. A good way to sanity check how your stand-ups are going.

Signs of a healthy stand-up

- Is everyone engaged, motivated and excited?

- Are they making progress and working on high-priority tasks?

- Are they working together and helping each other?

- Are they able to concentrate and do their job without disruptions?

Reality of what many stand-ups tend to be and some of the problems

I think that it’s easy to say that you are ‘doing standups’, everyone goes around giving their 3 question updates (what I did yesterday, what I am planning on doing today and do I have any blockers), but  you have to ask how effective they are. Was everyone listening to each other? Do you even remember what each person said? Did you learn anything from stand-up? Do you have a better sense of where in the lifecycle any particular story is?

Just like other processes that the team follows, stand-ups should be continually improved and tweaked.

So. I don’t think that the 3 questions above are enough. I think they are great to get the team started, but teams often grow out of them quickly. As long as you keep the goals in mind, you can change the structure to be whatever you want it to be.

Why aren’t they enough? Some reasons:

  • There is too much talk of ‘I’.
  • Lacks focus on getting stories to ‘Done’.  Ultimately the team should be focused on how to get the best, most useful features into the hands of it’s customers, I would like to see updates the revolve around how to achieve that.
  • Too easy for people to hide behind them, robotically answering and it’s easy to lose emphasis.
  • The language is quite passive. Rather than stating what your blockers are, why not focus on what you are doing to get rid of them?

The differences may seem subtle, but the language a team use can totally change the team’s approach.

How to make them better?

Don’t think of it as a status report, more as a chance to communicate with and update your whole team at once.

Explore different formats of standups. I find that ‘Walk the Wall’ works quite well to ensure that everyone is focused on what needs to get done to get  features out the door.

Start to move away from the 3 basic questions. Talk with your team about what kind of updates you would like to hear during stand-up that would be most useful to everyone.  Change the language to be more proactive.

Perhaps think about framing your updates using the language below:

  • What am I doing today to get cards moved across the wall towards “Done”?
    • Ensures that the focus is on activities that directly relate to helping to progress work.
  • What remaining work is left? When am I likely to move it to the next state?
    • Helps downstream roles to know when to expect new work, helping them plan better. Gives the whole team the sense of where the story is in its lifecycle.
  • Meetings? Would the team benefit from hearing a summary?
    • I forever hear “I was in meetings all day”,  hopefully the meetings were project related, so share what happened. People want to know…
  • Did you learn something yesterday that people might benefit from knowing?
    • Help the team become more efficient, by sharing things that you have learnt. It may prevent someone from making a similar mistake, or struggling with something someone has already figured out. If it prompts interest, have a post-standup huddle for people to hear more.
  • What am I doing to remove/fix blockers?
    • This is an important language difference from the standard update.  Don’t wait for people to remove obstacles for you, see what you can do yourself to work round them or move them yourself, or even other peoples. It’s more often than not quicker than waiting for someone else to do it.
 So I prepared the following ‘cheat sheet’ to help you think about your update. You could even stick this up on the story wall itself to act as a memory trigger.

StandupOther great stand-up resources

It’s Not Just Standing Up: Patterns for Daily Standup Meetings http://www.martinfowler.com/articles/itsNotJustStandingUp.html

The Standup Game – Great game to introduce standup concepts, but also to bring awareness to the effects that stand up anti-patterns have on the team.  http://loveagile.com/stand-up/stand-up-game

Some ways to address anti-patterns http://www.scrumalliance.org/articles/358-daily-standup-beyond-mechanics-a-measure-of-selforganization

Gender Diversity on Teams – Roundup

Wanted to keep a note of a bunch of articles and books that I found recently around studies about gender diversity on teams. Prompted by a discussion with a programme manager at an investment bank and then subsequently with my fellow ThoughtWorks colleague Nic Ferrier

I found these often quoted “facts” and was trying to hunt down their sources…..

National Center for Women in Technology – Resources
The Impact of Gender Diversity on the Performance of Business Teams 
Gender Diversity and the Impact on Corporate Performance – Credit Suisse Research Institute
Gender Diversity, Team Decision Quality, Time on Task, and Interpersonal Cohesion
LBS study shows addition of women to teams improves performance

Beginnings of an Agile Coach

So, I’ve not blogged in a while…  I’ve been at a new client since January as an Agile Coach, it’s been quite the learning curve,  leaving me little mental space left for blogging!  To celebrate my return I have got a new blog theme. Pretty!

Agile Coach?! What is one of those?

Teacher, Instructor, Coach, Trainer, Encourager, Enabler, Questioner, Confidente, Counselor, Advocate,  Life Coach…. (Not sure all of those are words) in all things Agile. Helping the team achieve the best that they can and create and deploy high quality software as quickly as possible.

Most ThoughtWorks projects have some inherent enablement as part of their remit. Projects where we deliver software alongside the client normally involved an enablement piece, teaching and mentoring them as we both deliver software together. Showing the client how to do TDD, continuous integration etc. The main point here though is that we normally are the ones setting up and driving the process that the team follows, and sometimes show whilst ‘doing’ when all else fails.

The enablement part had always come quite naturally to me, I’m fairly reasonable at communicating, people tend to naturally follow me,  I’ve been working in Agile environments for 5 years now and my ski instructing background gives me a leg up on the teaching aspect.

For a while now I had been asking to go on a pure coaching/enablement gig thinking that I’d be quite good at it, and how different could it be?!

Very. Turns out, when you don’t have full control over everything, as well as the ability to jump in a ‘just do it’, it’s not so easy any more! As with any new project it always takes me a while to settle in and really feel confident about what I’m doing. It’s been a very steep learning curve, but I can happily report that I’m now really enjoying it.

What advice would I have given myself  back at the start of this enagagement?

Learning about Learning

I’ve spent quite a bit of time learning about the ways that people learn. Funnily enough this is where a lot of the things that I learnt whilst learning to be a ski instructor were very familiar. Acknowledging that different people learn in very different ways and that you, as a coach, have to adapt your techniques and approaches to suit each kind of learner.

I also spent a lot of time learning about the Dreyfus Model, which is a model that talks about how individuals acquire skills and the different techniques that work best for people depending on where they sit on the Dreyfus Scale http://www.learninggeneralist.com/2009/08/using-dreyfus-model-to-engage-people-in.html

I still have tonnes more to learn about learning, but I find it fascinating. I think it’s something that you really need to invest in if you want to become a great coach.

Being coached on how to Coach

I was lucky enough to be working with a small group of very experienced consultants. Not only could they share their ideas and war stories with me, but I felt comfortable getting feedback from them. They made an effort to be approachable and open, so I always felt like I could go and ask them questions, and validate the ideas I had and the approaches that I wanted to take.  It’s important to have that supportive group as you are starting out. Unfortunately I don’t think that anyone can teach you how to be a coach, so it’s really a question fo getting regular feedback, failing fast and going with your instinct.

We all have own style

Following on from the point above. It’s important to recognise that we all have our own styles of coaching and teaching. What works for one person in a situation may not work for another person in the same situation. When you are starting out it’s very easy to watch other, successful coaches and think, “Wow they are amazing at XYZ when they do ABC, therefore if I do the same I will be successful too”. Not true in most cases. Every time I tried to emulate someone else I was never as effective as if I just went with what I would naturally do. For example one of my colleagues is great at asking very probing, thoughtful questions to people to get them to think about what they are doing and the affect that it has. I thought, ah brilliant, downloaded a bunch of  “consulty” type questions and tried them out on the next person I spoke to. I was so busy trying to remember the right questions in the right situations that I wasn’t even listening to what they responded with, I also sounded distinctly un-genuine. Turns out that when I stick to my normal mannor of talking to someone and asking they things, I achieve the same outcome but in a different way.

Pace

Things will move a lot slower than you are used to in a delivery situation. People take time to learn and change, and this shouldn’t be rushed. Step back, take a breath and let things happen in their own time. The sooner you come to terms with this the more enjoyable the experience will be.

It also may feel like things are a lot slower because you are not the one thats physically doing the work anymore (writing code, doing analysis etc.). That lack of control will seem like things are going slower, but they are probably not that different.

Don’t get overwhelmed

When  you are first in an Agile Coaching environment you will like see infractions of what you think is “proper Agile” everywhere you turn. Especially if it’s a new team and they are brand new to Agile. You might feel like there is so much to work on that you don’t know where to start. Recognise that you can only do one thing at a time, and some things may be easier to work on than others. Try and find the thing that is causing the team the most pain and start from there. We also found that trying to work on something that they are already ‘doing’ will be harder than introducing something that is brand new that will really help them. You are much less likely to get a defensive reaction.

I found just keeping track of the behaviours I was seeing, coming up with things that I thought might help, and then reveiwing them daily with some of my colleagues really helped. It’s also worth thinking about  whether or not a task is worth the effort that it requires. The image below is a Impact/Effort Analysis chart that you could use. Rate the potential exercise/piece of work on this scale and think about which order to then tackle things in.

Effort/Impact Analysis

Reflections on my last gig…

I have just rolled off of my project of the last 8/9 months, and thought it was a good point to reflect on my time there.

Once again I had an awesome time. I learnt a lot, met some great people, made some good friends, watched people grow, and most importantly contributed to a great product. There were a lot of highlights, too many to name them all, but here are 5 I picked out.

Non-hostile atmosphere.

The whole team was respectful of each others ideas and skills, open to change and new ideas and a lot of fun. One of the first projects where change has not been outright resisted and refused. As consultants I can see that it’s natural that our presence on a team can cause hostility, but we’re here to help, honest! This lead to a much more productive and more pleasant working environment, allowing people to try new things and bring their ideas to the table.

From the moment that I got there I felt like there was space for my ideas and people were ready to listen to them and give them a go. Wonderful feeling.

It sounds like a small thing but its really not. When a team is willing to change the way it thinks and embrace new ideas, everyone can contribute to that success, it’s not just the persistent, rebellious people (which is often the role that ThoughtWorkers have to take) who can make change happen but there is space and support for everyone to have ideas and change the way things happen.

Feature Leading. Our tech lead was comfortable letting some of us lead a few of the features, which was great. I got to look after the online sales feature we added and an emailing piece. It wasn’t so much as an official thing but more an organic thing. As well as being involved in writing the code, I helped with analysis, spent a lot of time talking to the teams that we were integrating with, kept an eye on and helped out with testing and deployment and generally provided a consistent technical vision for the whole feature. It’s great experience for people who are moving towards becoming a tech lead, without the pressure and responsibility for being the actual tech lead. I found it really energising to have such focus on one feature.

Coaching / Mentoring.

I went to a leadership academy event recently where one of the speakers said that you are not a great leader unless you have pulled people up with you. That has really stuck with me. What kind of leader can you claim to be, if you haven’t helped other people learn and grow?

The client had a female developer on their team who had never met another female developer before she met me. She is also very talented and passionate about technology with some great potential. I spent a lot of time with her coaching and mentoring, and this relationship will outlast the client engagement. I get a massive amount of satisfaction helping others reach their goals and look at the world in different ways. Also being able to provide the support that people need to grow.

I also tried quite hard to make sure that I was giving “in place feedback” i.e. immediate feedback in a situation, mostly whilst pairing etc. One of the other TW Developers on the team commented that he heard me doing this often and learnt a lot from just listening. Need to do this more though. Especially when there are more “heated” pairing situations.

A positive attitude can go a long way.

Generally I’m a pretty positive person, and I got a lot of feedback about how this changed the whole atmosphere of the team. It only takes one consistently negative person on the team to start bringing the entire mood down. Remember this and try and look at situations positively and with energy.

There is more to being a developer than just writing code for the story you’ve been given.

As a developer, you are responsible for getting features that help the people using them into the hands of the people using them. It is your job to push back if you think requirements don’t make sense. It is your job to ensure that the software you are producing is of a good quality. You should not just be coding whatever you are told to without questioning anything. So as well as writing code, be part of the requirements definition, the testing, the conversations with stakeholders, with the people that are deploying your code if it isn’t you. Software that is not in the hands of the users and being used is useless.

As well as advocating the above, I spent some of my time on the team championing and facilitating the retrospectives, launching lunch and learns, being part of the inception, and countless other things that weren’t strictly in the remit of a typical “developer”. For me this is normal as they are things that I enjoy, but I don’t think this was the kind of developer that many of the client devs had met before! I hope that it has influenced them a bit.

Technical highlights

No-SQL datastores (Dynamo DB)

JavaScript testing (Jasmine)

JavaScript frameworks (KnockoutJS)

E-Commerce

In process browser testing (Plasma)

Feature driven development (Starting with high level feature tests and build down)

Analysis of logs (Stash)

Releases every week with blue/green deployments

Our tech stack:

Written in:

C# .Net, Javascript (KnockoutJS, JQuery), Razor, MVC4

Dependancy Injected with:

Unity

Package Managed by:

NuGet

Tested with:

Moq, Plasma, Selenium Webdriver, NUnit, JMeter

Data Stored in:

SQL Server 2012, Dynamo DB

Deployed on:

Amazon EC2, IIS,

ORM Layer:

Linq to SQL, Dapper

Deployed and Built using:

DBDeploy, MSBuild, Team City

Monitored with:

Stash

Coded using:

Resharper, Visual Studio 2012

…..and probably others that I can’t remember off the top of my head.