Tag: Teams

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

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 have been on 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

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 – Team Lunch and Learn

Our team has just embarked on “Lunch and Learn”s. (A time for the team to get together over lunch and learn about something new). For the first one, my colleague Tom and I volunteered to teach the team to use Git…

Our development team was previously all located in the UK, but we are about to go distributed with teams in both India and the UK.

We are working on a .Net stack so of course, (shudder) we are using TFS. Due to the team changing to be distributed we are having to look at more distributed friendly source control systems, and thankfully Git is on the table.

Now I am definitely still a relatively Git noob. I was introduced to it on my last project, and we used it pretty extensively for a year. Now, I hate working without it. I think it’s changed the way that I work, so it’s hard to go back to the TFS dictated way of working.

We are planning on doing two sessions. This first one being just on the very very basics for someone who has never used Git or another distributed Source Control System. Literally, this is how you get stuff out, change stuff, and get it back in. Hoping nothing goes wrong.

Anyway, we bought pizza for everyone, to keep them happy, and quiet.

The first part of the session we did in a meeting room with whiteboards. Tom talked about some of the high level concepts of distributed source control systems. Along with a brief description of how it differs from TFS ***. Tom also talked through some of the key terminology that people would need to get used to. i.e. working trees, remote repository, the index/staging etc.

My job was guiding the team through the workflow that we’ll be encouraging. I chose to first explain the workflow we would be using, away from the computers using pictures, to ensure that everyone listened and understand why they were doing each command. I was worried that everyone would be distracted and race ahead without considering what they were doing with a shiny new toy in front of them.

Now I know that there are two different schools of thought out there. Local branches or committing on master. I was taught to use Git using local branches so that’s what I’m more comfortable teaching. Plus it means that your master branch is always clean, gives you a bit more of a safety net, but also it forces you to change the way that you are working, not just doing the same workflow you did in TFS or SVN. It forces you to start getting used to the concepts that really make Git powerful.

It went surprisingly well. I was expecting a lot of fear and resistance, but actually it create a great new energy around the team. Everyone rushed back to the computers to try out what we had been showing them, and it started a lot of good discussions.

See the following post for my detailed description and walkthrough of a sample workflow with Git.

*** to keep the “but in TFS…..” To a minimum, I asked everyone to keep an open mind and if anyone who wasn’t presenting brought up TFS they’d have to do star jumps in the corner.

GHC 2012: How to Influence without Authority, and Why It’s Important

These are some notes and thoughts from one of the sessions that I attended at Grace Hopper this year.

Dictionary definition of Influence. – The capacity to have an effect on the character, development, or behavior of someone or something, or the effect itself.

Inherently, you don’t need authority to influence.

What do you need to be able to influence?

– Relationships – Get out into the hallways and meet people… Learn what their goals are and figure out how you can help them advance those goals. Do your job well and build a reputation for yourself.

– Trust. Takes time to build, very easy to break.  You get this by doing what you say and saying what you do. Be consist in your approach to things.  Reciprocity is important. Give as much as you ask. Takes time. Not a one off thing you try to achieve.

How do you influence?

Become good at summarizing, be concise, make sure your ideas are based in fact. Consider your audience. Change the length and depth of your data depending on who your talking to.

What’s in it for them? If people find nuggets of their ideas in your plan, they will want to be bought in to it.

Ask questions. Ask short questions, give people a chance to tell you what they think. Make an emotional connection and find out shared values. Ask open questions, avoid leading questions, not yes/no questions.

Now i’ve always had a bit of an issue with session’s on how to influence people. We had one when I first start at ThoughtWorks at TWU. I’ve always thought there is a very fine line between influencing someone and just plain manipulating them. In my rose-tinted world I hope that you don’t need to consciously try to influence people if you are leading by example and have everyone’s best interest’s at heart. If you are genuine and achieve great things, it will change the way people around you act.

Thankfully someone in the audience asked just this question: How do you make sure you’re not coming across as being manipulative?

Avoid one sided conversations.  Present your idea and ask for feedback.  Focus on what is in it for them.  Respect “No.”, but try again.  Make sure that you are “perceived as trustworthy”. (<- shouldn’t you just BE trustworthy?!)

What do you do when you are dealing with someone who ‘needs’ to feel like they have that authority over you?

Make friends with people who are friends with them and ask their advice. Ask how can I talk to them in a way that they will listen to? Make sure you are advancing them in their goals as well. “Their ego is their teddy bear and don’t take their teddy bear away from them”.

As long as you don’t care who gets the credit you can go along way.

 How to influence what you are working remotely?

Try to meet at least once. Phone and Skype become easier once you have met face to face. Talk about non work stuff to create a personal connection. Get into a conference call 15 mins early and chat, make it known that that’s what you do.

For more notes on the session see here

Becoming a Tech Lead

I’ve been a senior developer for over a year now and I’m starting to think about how I can grow into an awesome tech lead.

I’ve always wished that there was some kind of manual that would explain to me how to become a tech lead. Which skills I would need to learn and grow, how to know what to worry about and what not. What kind of things I should be looking out for on my team and how to lead a group of developers to make good quality software.

Alas it seems that there is no such manual and you really just have to get out there and try and learn quickly.

A couple of months ago I was fortunate (or unfortunate depending on how you look at it) enough to “try out” being a tech lead while the other senior developers and tech lead all went on holiday for 2 weeks at the same time, leaving me to try to hold everything together while they were gone.

Initially I was quite daunted, but hey you don’t get the opportunity to ‘play’ at being the tech lead without having to actually BE the tech lead very often. I was also very lucky that I was in such a ‘safe’ environment and could fail fast and learn quickly.

These are some lessons that I took away from that week:

  • Trying to stay in the pairing rotation and being a useful part of the pair while starting out in this role is really hard. I started this way at the beginning of the week, but found it too distracting for both me and my pair when I kept getting pulled away for other discussions. The constant context switching every 5 minutes meant that I could never concentrate fully on pairing effectively. Once I took myself out of the pairing rotation and worked on my own, my stress levels and concentration were much better, and I didn’t feel guilty about being an awful pair. It also meant I was free to float around and help anyone else where needed without worrying that I’d left my pair in the lurch.
  • I kept a list of all the things that I saw going on around me that I thought might be ‘smells’. There were a few things that I simply didn’t have time to worry about, making a note of these and moving on made it much easier to not get overwhelmed. I would then come back to the list often to see what I could tackle next or note down anything that was changing. This was very helpful when it came back to handing the reins back over so that they could see what had been happening and any solutions that I had to problems that I hadn’t had time to dedicate too.
  • Don’t let anyone see your fear! There was a certain amount of ‘fake it until you make it’. Present a confident front. Admit it when you don’t know the answer to something and go and find out the answer. But letting on that you’re nervous or that you’re not sure what you’re doing is not going to make anyone want to follow you. I was very lucky that the rest of the team were supporting me and understanding that someone  had to play this role.
  • Trust people. Theres no point hovering over people and/or  micromanaging people. Let them get on with their work and they’ll come to you to ask for input on their own.

Since then I have been “feature leading” one of the main streams of work for our current release which has been really fun. Especially with the ‘real’ tech lead back. Thats another great way of getting experience in leading a technical team. Take charge of a stream of work and become the point person for it. It’ll give you great exposure to teams outside of your own. and let you see the consequences of design decisions that you made earlier on.

See my colleague Pat Kua’s post on Feature Leading here. If anyone has any resources on growing into a technical leader please share!

Notes from Strengths Based Leadership

Now that I am commuting for two hours a day on the train, I have a lot more time to catch up on some reading. The followup of Strengths Finder from Gallup is this book, Strengths Based Leadership.

I am a big fan of the Strengths Finder book and it’s accompanying online test, so I was looking forward to this follow up. See Blogpost: Finding Strengths in Your Team for my post on  Strengths Finder.  I have also been working on a proposal for a conference with a co-worker entitled How You Can Develop Your Team By Harnessing the Strengths of Your Team Members so this topic was right up my alley.

Like the first book you also get a code to take an online test to help figure out your strengths but with a specific slant on leadership skills. Interestingly my top 5 strengths from before were all the same apart from Restorative has been replaced by Relator.

The researchers have identified how these strengths group into 4 overarching leadership styles.

The theory being that lots of the leaders that they have research do not have strengths in all of these areas. Their strengths are normally dominating one or two areas. The key though is that they surround themselves with people whose strengths dominate different areas.

These are some of the biggest things that I took away from this book:

  • If you spend your life trying to be good everything, you will never be great at anything. The greatest misconceptions is that of the well rounded leader.
  • The path to great leadership starts with a deep understanding of the strengths you bring to the table.
  • Be aware of just trying to imitate great leaders that you know. You will spend all your energy trying to be like them rather than figuring out what kind of leader you are.
  • If you are able to to help the people that you lead focus on their strengths, it will dramatically boost engagement levels throughout your organization.
  • Effective leaders surround themselves with the right people and build on each persons strengths. In most cases though leadership teams are formed out of circumstance. The most competent and skilled people making it to the top. Rarely are people recruited for strengths that will complement others on the team. For example seeking someone who could build stronger relationships between the group, or someone who could influence theirs on behalf of the group. Often people will pick people similar to their own personalities and strengths. How are you supposed to grow and adapt to change this way?

The book has three sections

  1. Investing in your strengths
  2. Maximizing your team
  3. Understanding why people follow

With lots of case studies and examples. A good read for anyone trying to find their leadership legs like me!

Bringing Visibility to Retrospective Action Items

I’m a big fan of the Retrospective. I think it’s so important to take time to look back and reflect on how things have been going, and think about how to make things better on your team. There are heaps of different kinds of retrospectives for different occasions and to enable you look at your from lots of different angles.

Regular retrospectives will open up great communication between team members and make it easier to talk about issues and successes.

However, you can’t reap the full benefits of retrospectives if nothing changes afterwards. If the team feels like they are losing an hour of their lives to retrospect and then nothing happens they aren’t going to be keen to have one again.

Some things that I think are important:

  • Retrospectives should happen regularly. Every 1-2 weeks AT LEAST.  More than that and the feedback cycle is too long, the retrospective will likely take hours because so much stuff has built up.
  • Keep them energetic, change up the format often and get different team members to facilitate and take ownership.
  • Keep them constructive, follow the prime directive and ensure that there are action items that have owners and are achievable.

I recently joined a team that was feeling quite disillusioned with their retrospectives. They were every 3-4 weeks, and the same issues came up time and time again. Nothing was changing and the team was frustrated. On my second day on the team we had a session and everyone was grumbling before we had even started, that it was pointless. It broke my heart.

I felt like there was a massive lack of visibility to the items that had come up, no ownership and no follow-up.

So I got hold of the items that had come up and created a Retrospectives Action Items board that lists all of the action items, their owners and equally as importantly, which ones we have actually achieved so that the team can see that we are making headway.

This board lives next to the story wall where we hold standup so that we can talk about the items every few days, see progress (or lack there of) and provide a friendly reminder. (My crafting skills pale in insignificance compared to some of my past team mates, so sorry about that!)

  • Ensure the whole team can see the action items and who’s responsible for making each one happen.
  • Regularly bring action items up and check progress during standup, remove any blockers if necessary.
  • Celebrate the items that do get done.

So far this has worked pretty well. I already feel there is a better energy and things are changing as a result of our last retrospective. Next mission, get them to happen much more often!