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.

Bringing visibility to code quality metrics

It’s often hard to measure whether or not the quality of your codebase is improving. It’s also very easy to become overwhelmed by software quality metrics. With so many, you stop paying any attention.

One of the metrics my current team has been paying a lot of attention to is a “duplicate count”. It’s a measure of how many lines of duplicated code you have in your codebase, both in the test code and in the production code. Team City, which we are using as our Continuous Integration server, has a built in duplicate count, so that every time you check in you can see whether it has gone up or down. (The way that it counts is sometimes a bit strange… but I won’t focus on that!) You can make sure that the build fails if it goes over a certain number.

We were trying to focus on “improving the quality of our test code”, especially our high counts of duplicates within our test code. As this one was easy to measure, we thought we’d focus our efforts on a single metric and consciously reduce the number with each check-in.

Feeling particularly arty that day, I decided to create a physical counter that we could use to measure how we were doing. I created one counter that I put in front of the build monitor. Leaving the numbers to be coloured in as people got to them. This would then be flipped over as people reduced the numbers.

I also created a summary of the numbers to put on the story wall, so that at standup we could always check on progress. Noting what the number was at the start of the week and then what the number of duplicates was for that particular day.

It worked amazingly well. Suddenly this group of grown men were enthusiastically running over to the build monitor to change the counter as they reduced the duplicates. Cheers would go up when a pair checked in code that reduced the number. Turns out “gamification” is a real motivator. Before I knew it, people were getting shout-outs at standup for being particularly good duplicate reducers that week.

Having the additional counter on the main story wall meant that people outside the developers were aware that we were paying attention to the quality of our code and actively trying to improve it. It has now become part of our daily standup routine to talk about it.

The counter worked so well, that we then introduced one for the number of warnings in the code base. Pick a quality metric and try it!

IMG_1455IMG_1454

Git for Beginners – A Sample Workflow

So here is my *very* happy path sample workflow, using local branches, with explanations for first time users of Git. See here for a worksheet with useful git commands and their uses and a sample workflow. This covers only what this post covers.

You will aslo see references here to “git tf”. This is not an alias but a cross-platform, command line tools that facilitate sharing of changes between TFS and Git. The commands are the same as the regular Git ones. But slightly different for pushing and pulling. See here for more information.

A familiar workflow:

  • Get the latest code
  • Create somewhere to put the changes you are about to make
  • Make changes
  • Make sure you are happy with them and want to integrate them back into the main repo.
  • Check for any more updates
  • Push your code into the remote repo

Now broken down into the Git steps to achieve the above.

1. Get the latest code

Make sure you are on master. Use git status to check.

Pull down the latest changes onto master git pull

2. Create a new branch for your story work.
Name it after your story so you can remember it later. git checkout -b [branchname]

If you do a git status now you will see you are on your new branch.

3. This is where you code as normal, running your tests etc.

4.Commit your changes to your branch.
When you are a point where you are happy with your changes and you want to pull in everyone else’s changes… You can commit as many times as you like to one branch but try to keep them small and in a working state.

A git status will show you your changes.

You will see the files that git is tracking and has staged and those that it has not. git add . Or git add -A will add any untracked files.

Next commit your files to your branch. git commit -am "[message]"

When you do a git status now, you should see no changes.

If you do a git log you will see that your commit is now part of the branches history.

5. Get latest code on master

Move back onto your master branch git checkout master

If you do a git log at this point, you will notice that your commit is not yet on master, and the latest commit will be from when you last pulled.

git pull will bring down any more changes.

6. Update your branch with lastet code

Move back to your story branch git checkout storyname

Next you are going to rebase your branch. When you originally created your branch it was based on point in time x, since there have been additional changes (time y), you want to tell your branch that you actually want it to be based from time y and you want your changes on top of that. So now git rebase master will update your branch with all the changes that are now in your master branch. As you watch the output you will see that git pulls out your change, fast forwards to time y and then replays your change on the top. Now you may have conflicts at this point if two people have changed the same thing but will assume things are all good.

Now run your tests and make sure everything is good.

7. Get your changes back into the main repo.

Move back to your master branch git checkout master

Merge your branch back into master with git merge storybranch

git push will then send up changes to the remote repository.

Next time… Merge conflicts…..