Anne’s Top Tips for Enablement – Lessons from being an Agile Coach

Often at ThoughtWorks we will be asked to help train and up-skill the client’s team members whilst we co-deliver projects. We call this enablement. These are some lessons that I learnt whilst being an agile coach and from having 1:1 coaching sessions with clients, that are worth thinking about if find yourself on the “consulting” or “coaching” side of a relationship.

Tip #1: Understand the expectations from the start

What kind of engagement is it?

Think about what kind of situation you are in. Are you there to “just deliver x”? Are you working closely with a client team? Are you there in more of a coaching or consulting capability? It could be something anywhere along that spectrum. Wherever you land on that spectrum there will always be some degree of influencing, education and support of the client needed. You will need to bring people along with you, whether it’s a single stakeholder or a team of developers, this to me, is enablement.

Pick technologies and techniques that the client can support

More often than not, we will be leaving behind some software or hardware that we are expecting the client to be able to maintain or support to some degree. Really think about this when picking technologies, designing your software, and evolving your process. How different is this to what the client has done before? What are their core skills in, and what’s reasonable progress from that? Often the newest, coolest techniques are not going to be easily learnable in the time that we have with them. Think about your choices and don’t leave them with something they won’t be able to look after. Do the right thing by the client.

Talk about it often

At an account level, make sure you talk about what degree of enablement you are expecting, ensure that it’s planned in from the start, and check that you are progressing, revisit decisions and assumptions regularly.

Tip #2: Put yourself in their shoes

Work on courage and confidence

People’s confidence can often take a huge hit when they are transitioning to a new skill set. For example between waterfall and agile or from one technology to another. Until the person can work out how to adapt their current skills to meet the needed skills, they can often feel like they have no skills at all, they might feel they no longer have anything to bring the table and that they are the only ones feeling like this. Multiply this phenomenon by the fact that it’s not just one new thing thing they are experiencing, it could be their whole working environment, how they collaborate, how they contribute, the people round them and it can spiral quickly. It is really hard to stay confident and courageous with all this going on. At the beginning focus on doing everything you can to help people grow in confidence and courage, so that they can throw themselves into learning.

Consider learning agility

Learning Agility, the ability to learn, adapt, and apply ourselves in constantly morphing conditions, is something that as consultants, is a required skill. In some larger, more traditional environments, this is not something that employees have a chance to practice and develop often, so their learning agility levels might be quite low. This doesn’t mean they can’t learn, but that the process might be a lot slower that someone who is more practiced. It’s quite a different mindset, so think about how reasonable it is that we expect someone with lower learning agility to “just pick up” tens of new tools and practices at a fast pace. Really think about how patient you are being, slow down, cover basics and practice fundamentals often. It takes time to develop the skills of learning, but helping people build these skills can make such a radical difference in the future.

Show your vulnerability

It can be very intimidating to learn from an “expert”, someone might feel like this “expert” can do no wrong, that they never make mistakes, that they are always confident, that you don’t have anything to add. Try sharing stories of times that you have struggled to pick things up, or situations you have felt scared in. We all feel unconfident at times, admit that to them, you’ll see a massive difference. Make sure to ASK for their input don’t just expect them to speak up without encouragement.

Make sure you cover the basics

Don’t forget to cover the basics, explain the dynamics and responsibilities when pairing, cover basic TDD and red, green, refactor, go into the finer details of how to write stories and plan work. Always remember to explain WHY. Keep repeating this basics, when you are new to anything it takes a lot of mileage and repetition until you start to understand the nuances.

Tip #3: Get to know the people you are working with

Build rapport

Rapport is one of the most important things when coaching. There needs to be trust and respect between both parties. You might want to ask how they got into what they do, what their experience is at the company, find out what they do for fun, look for common ground.

Talk about goals and aspirations

Take time to ask and listen about what their goals and aspirations are, you are more likely to find you have a motivated pair if you can help find them opportunities that they would enjoy. One idea that someone had which I thought was great, at the start of pairing or at the start of the day the pair should talk about what learning or knowledge they want to gain out of the activity. This will help you work out when to take more time over particular concepts, and when it’s ok to go at a higher level of understanding.

Value them and their skills

It doesn’t matter what experience or background people have, everyone has skills to offer, everyone will bring different perspectives. Your clients will have the best domain knowledge, and they know their own systems better than anyone. They are software professionals, probably with a lot of experience. Value and embrace this diversity in thinking.

Open the feedback conversation

It’s important to create an environment where feedback is encouraged and accepted. This might not be something that currently exists, it is our job to create that space. Make it a place where they are comfortable enough to be able to feedback to you about how they learn and what helps them.

Conclusion

I hope that you have been able to take away some tips that you can apply in your next enablement situation. Please reach out to those around you and ask for help, and make sure the team is talking about enablement and how it is progressing. Developing the empathetic skills I’ve talked about above will make a huge difference in creating a successful enablement situation.

The Retrospective Handbook by Patrick Kua

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 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.

Other 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

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.

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!

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.

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!