Tips For Working With Distributed Agile Teams

One of the major drivers for the need for organisations to be more agile, is globalisation meaning that, from a personal point of view, I have the luxury of scouring the internet for the cheapest place to purchase my favourite brand of whey protein, or where my next holiday destination may be. From a the perspective of McKenna Consultants, this increasing pace of change means that we are now competing with computer programmers and agile consultants from around the world, bringing it's own advantages and disadvantages.

One of the bi-products of having a more competitive global market place is the increasing number of teams that I work with who are either:

• Working with at least 1 distributed team member
• Are a distributed team member themselves
• Working with a team not location in the same country or region

Even at McKenna Consultants we are working on software development projects as part of a distributed team with our clients and with our own distributed team member!

Making good use of our monitors at McKenna Consultants to manage distributed teams!

Some of the challenges with distributed teams that myself and the teams that I coach and train identify are:

• Cultural differences
• Dealing with Time zones
• Language barriers
• Easy to blame
• Lack of trust
• Misunderstanding of requirements
• Lack of visibility

Teams that I have worked and still work with have come up with many ideas to overcome some of these challenges, including:

• Travel - Travel to the office to meet, work and socialise with your distributed team members. If you have a personal friendship with them, you will be more likely to go the extra mile for them, and less likely to blame them! The benefits from building and maintaining these relationships far outweigh the cost of a flight and a few nights in a hotel! If working in a different country, you will also get the opportunity to learn a little about the culture and immerse yourself in it. This works both ways, set up a schedule of when you will make the trip across to see each other.
• Make Them Part Of The Team - Rather than setting up an entire team elsewhere, that you would be collaborating daily with,  one of my clients had great success by extending the team via an offshore distributed team. The offshore team had 6 members, with each offshore member extending the size of a different UK team.
• Get In Sync - One client that I worked with had an offshore team and agreed to have them working UK hours. This may seem unreasonable, but so long as you're clear from the outset, this could help to resolve time barrier issues. Other teams have dealt with this by altering their working hours to start and finish earlier or later, whilst another team that I worked with held 2 stand ups a day - one in the morning and one in the afternoon to help with the handover.
• Use Technology - There are so many cool products out there now to make working remotely so much more easier - JIRA, Trello, VersionOne, Skype, Slack, Google Hangouts, I could go on and on. Use these to share information, progress and encourage communication. I once worked with a team who created their own version of a "Sheldon Bot" to wheel around the office into team meetings as and when required! On an agile training course that I recently ran in London, one attendee described how he worked at a start up where they had a continuous live 2-way feed so that the two locations where always just loud noise away!
• Retrospect Regularly - Point 12 in the Principle of the Agile Manifesto - At regular intervals the team reflects on how to become more effective, then tunes and adjusts it's behaviour accordingly. In order to continue to be/aspire to be a high performing team, it is essential that you continue to retrospect regularly and experiment with new ideas. And guess what? Involve the distributed team members too!

This is a common discussion that I have on training courses and with teams that I am coaching, so I would love to hear your challenges and how you got around them!

Build Your Own Manifesto In Action!

A few months ago I published a blog called Build Your Own Manifesto, describing a game that I used to help teams understand the Agile Manifesto and also to help myself as a trainer understand what the group whom I am working with are at in terms of knowledge and experience.

I have run this game over 20 times now this year as part of "An Introduction to Agile", a flagship course for McKenna Consultants, and continue to receive great feedback!

Here are some photos of the latest group, 4Com plc, a telecommunications company based in Bournemouth, getting hands on playing Build Your Own Manifesto!

Feel free to download the pack, customise it, try it and let me know what you and your participants think!

Team Building With Build Your Own Manifesto

Build Your Own Manifesto

Build Your Own Agile Manifesto In Action!

How To Be A Better Leader - Management 3.0

In August, myself and my brother and fellow McKenna Consultants director Nick McKenna, travelled to Stockholm to attend a two day Management 3.0 training course.

We had both read books around this and wanted to find out more, with the aim of becoming Management 3.0 Licensed Facilitators (which I am pleased to say that we did!). We work with a number of clients who we have successfully helped to implement many agile methodologies from the team level (Scrum, Kanban, Lean etc) to running and scaling the entire software development process (SAFe is a popular framework for many of our scaling clients), yet may of the leaders, managers and executives are left wanting more, asking us how they can "be more agile" in their day to day and ultimately become a more effective, better manager of people.

Stockholm Looking Beautiful In The Morning.

 This is where Management 3.0 comes in. After reading some of the work by Jurgen Appelo, including Management 3.0 and How To Change the World), we had an appetite for more and felt that this could be something that our clients could truly benefit from.

So what is Management 3.0?

Management 3.0 is a modern approach to managing people, blending together ideas from complexity thinking, change management and agile methodologies to give leaders, managers and executives a practical toolkit of knowledge and techniques to enable them to become more effective leaders and managers.

The focus of the course is around the following main topics:

• Energize People
• Empower Teams
• Align Constraints
• Develop Competence
• Grow Structure
• Improve Everything

And within each of these topics is not only the why, but gives you some practical tools, techniques and activities to allow you to explore these concepts with your teams, colleagues and organisations. Some of my favourite tools from the course were:

• Moving Motivators - A great tool to encourage discussions around what are the intrinsic motivators of individuals. Believe me - this tells you a great deal about yourself and your team!
• Kudo Box - Everyone loves to get praise, whether it is a well done, high 5 or a slice of cake. This is a cool way to make it easy for people to say thanks to each other.
• Delegation Poker - Not all decisions have to be made by the managers and leaders. This game is a great way to collaboratively agree on how the responsibility of decision making can be shared, and also, which decisions cannot be shared.

Moving Motivators Card Deck.

We have already used these at McKenna Consultants, and we are using them with our agile clients right now!

Since the course, we have started to experiment with some of these tools and way of thinking to great effect. So much so that we have decided to run the two day Management 3.0 training course in Leeds, UK (the only one in England outside of London) on Thursday 24th and Friday 25th November 2016. You can visit our dedicated training website to find out more about this.

For a quick summary of Management 3.0, here is Jurgen himself presenting these topics at a recent TED Talk.

In summary, the trip to Sweden was well worth the effort and we are excited to contribute to Management 3.0 community and help our agile clients become better leaders!

Build Your Own Manifesto!

I have been teaching agile courses for the last few years, and coaching teams for even longer. When I start my training courses, I like to gauge the experience in the room, firstly, to help myself as a trainer so that I know how much to focus on "the basics" and secondly to demonstrate to the room that more often than not, we are all in the same boat, with the same level of experience! At McKenna Consultants, our most popular course is our Introduction to Agile training course, where the game that I am about to introduce is particularly useful.

I have tried to do this different ways, such as explaining your agile experience, rating your agile experience from 1 to 10 and also with human affinity maps. With all these ways however, I find that some attendees like to "think that they know it all" whilst others are too polite to be truly honest that they know quite a bit.

I spent a while thinking about how I could improve this experience for myself and my students, and, inspired by Build Your Own Scrum (a tool which I also use when coaching and teaching), I came up with Build Your Own Manifesto.

The rules are simple:

1. Divide the group into small groups of no more than 3
2. Give them the Build Your Own Manifesto handout - explain that 4 of the phrases are actually not needed.
3. Give the groups 15-20 mins to construct what they believe to be the agile manifesto
4. One group at a time, present back to the room

I find that this exercise is really useful for a number of reasons:

• It gets everyone in the room talking and importantly - collaborating!
• When I facilitate and walk the room, you hear some great discussion like "I thought agile was about not having a plan" or "There is no documentation in the agile world". I note all of these comments down to tackle throughout the session
• It clearly demonstrates to me people's knowledge of agile
• Helps people to feel in a safe environment when everyone presents back and not a single group has it word for word perfect.

You can download the Build Your Own Manifesto template that I use here.

It is basically the 4 values from the agile manifesto mixed up, with some additional red herrings in there - Instead of is included! This is a bit of fun and tends to provoke some healthy discussion and groans when the teams realise!

Please download and use this idea and let me know what you think, I would love to hear it!

Try A Festive Agile Retrospective!

Christmas is approaching and you're coming to the end of your sprint... why not capitalise on the season of goodwill and hold a festive themed agile retrospective!

In order to keep things nice and simple for you, I am going to use my favoured template to help lead and shape the discussion. For those who aren't familiar, I like to use the following from "Agile Retrospectives - Making Good Teams Great".

• Set The Scene
• Gather Data
• Generate Insights
• Decide What To Do
• Close Retrospective

I'd love to hear how you get on with this retrospective, how the team reacted and how it helped or hindered the discussion! Leave a comment with how it went!

Festive Retrospective!

You will need:

• Post it notes
• Whiteboard/flipchart
• Whiteboard/marker pens
• Planning poker cards

Highly recommended/optional:

• Festive playlist - load your phone with a selection of Christmas songs to help manage the time during activities. I like to limit activities to the length of "x" amount of songs. Personal favourite Christmas songs of mine are Merry Christmas Everyone by Shakin' Stevens and the Michael Buble Christmas album!
• Christmas treats - As mentioned in previous posts, the retrospective is cause for a celebration and a valuable chance to build the culture of the team. I always recommend bringing in sweets or chocolates. As it's Christmas, take advantage of the mince pies on offer in the supermarkets, or if you're feeling brave, bake your own (providing there are no health and safety issues...)!
• Christmas jumpers - Why not?!

Set The Scene - Festive Foodies!

This is my favourite, fun way to start a retrospective. I like my teams to come up with a metaphor to describe the sprint. In previous retrospectives I have used food, drinks, movies, songs, countries, I haven't yet found one that doesn't work. I've even managed to get this to work with teams based in India, where I was worried that this exercise may become lost in translation!

Give the team a few moments to think of a festive food that best describes the sprint just gone. Each person should do this individually. Get each team member to write it on a post it and stick it to the board. Then, go round the team one by one and get them to explain their Festive food and why the sprint relates to that. 

You might want to give an example like:

A tin of Quality Street - The sprint has been great, with lots of variety and interesting stuff going on. However, I picked out a "toffee penny" of a user story that's full of issues...

Gather Data - He's Making A List, Checking It Twice...

Now that the team are warmed up, in good spirits and onto their second mince pie, we need to get to the bottom of their metaphors by thinking about some of the events that occurred during the sprint.

Ask the team to think about some of the events that happened in the last sprint and categorise them into two columns:

"The Naughty List" and "The Nice List".

"The Naughty List" should contain all of the bad, frustrating, annoying and generally unfortunate things that occurred during the sprint. This could be anything from poorly defined stories, build issues, lack of knowledge etc.

"The Nice List" should contain all of the good things that occurred during the sprint!

Use the Post It notes to compile the list!

I'd recommend giving the team the length of 2 to 3 songs worth of time to compile the list.

Once this is done, get each person to read out their events of the sprint, explaining why each is either naughty, or nice!

Generate Insights - Santa's Sleigh

Now that as a team we have learned a little bit more about the sprint, it's time to do something about it! Let's use the idea of Santa's Sleigh.

All of the items on the Naughty List are weighing Santa's Sleigh down, causing his productivity on Christmas Eve to struggle. These are his presents. If we can somehow remove, or deliver his presents, his Sleigh will fly a little more smoothly, causing him to be more productive.

The items on the Nice List however, are helping to pull Santa's Sleigh along. These are his trusty reindeer! How can we do more of things on the Nice List, or do them better? Think of this as adding a reindeer to the sleigh. 

Using the Naughty and Nice lists as a reference, ask each team member to come up with 1 idea to deliver presents (tackle an item on the naughty list) and 1 idea to add a reindeer (maximise the nice list).

Again, limit this to a number of songs and get each team member to explain their idea to the team!

Decide What To Do - North Pole Dollars

Now in order to keep the number of action points to take into the next sprint manageable, we need to decide as a team which we would like to focus on.

To do this, the team needs to come to a collective agreement. I have tried many ways to quickly, fairly and efficiently do this, but find that dot voting or a twist on relative estimation is the best. As we did a twist on dot voting in my last themed retrospective, lets go with relative estimation this time.

Hand out your Planning Poker cards to each team member. Ask the team to quickly decide which improvement would be the least valuable to the team. Once this is decided, the team should estimate this by holding up a card. 

Take an average based on the estimation,so if the team hold up a 1, 3, 1, 5 and a 13, then the average is 23/5= 4.6. Multiply this average by 1000 to give you your value.

For added fun you can assign a monetary value to this, say North Pole Dollars. Therefore this improvement has a value to the team of NP$4,600. I first used this idea of assigning fictitious currency when doing my ScrumMaster certification training and found it fun and a great way to help prioritise!

Using this item as a frame of reference, ask the team to assign values through planning poker to all the remaining improvements and collate a leader board (from highest value to least) for them all.

Once you have finished, the top 3 improvements are the most valuable to the team and the ones to be carried into the next sprint! Make sure that you don't forget to assign the responsibility of looking after each action to someone and agree on the next steps!

Close Retrospective - Secret Santa

By now, you should have some actions to take into the next sprint. It's time to end the retrospective with a little fun! 

Anonymously, ask each team member to write a name of a team member who had the most positive impact on the sprint (no cheating and writing your own name here!). If they can also think of a reason (that doesn't give their identity away) too, write that down as well.

Then, fold the notes and pop them in a bag for the ScrumMaster to draw out. One by one, draw the notes reading out the name and reason! This should give the team a boost, an opportunity to show some appreciation and have some fun too!

If you're team doesn't like the idea of this (I find some software teams don't like some of this hippy "feel good" stuff), you can always instigate a game of Christmas charades!

Have a go at introducing some festive cheer into your next retrospective and remember to let me know how you get on!

An Agile Letter To Santa!

Wouldn't it be great if Santa Claus was more agile? I mean, by now we all know that it is crazy to work for 364 days a year and then do a delivery within a 24 hour period! Wizard definitely had the right idea, wishing that it could be Christmas everyday! Working in shorter, 1 day sprints, Santa and his team could have more chance to stop, reflect and improve. Plus, his clients would get the added benefit of getting value, enjoying Christmas everyday!

Putting Santa's waterfall approach aside, today is a month till Christmas day and it is about time that we put an agile letter to Santa together (let's just hope that we haven't changed our minds as I don't think that Santa and the elves can cope with change this late in the game).

I have been thinking of some of the things, products and artefacts that have made agile teams that I work with successful over the years. I have put them into a nice list for you, in order for you and your team to pick and choose the ones that you want to add to your list!

Toys are an important part of our day to day work...

Here goes...

Dear Santa,

My agile team and I have been really well behaved this year, been responsive to change, open minded, value focused and committed to continual improvement. With that in mind, please can we have:

1. A huge 60" TV - If you haven't already read it, read my post on "How To Justify a 60" TV To Your Boss". It explains in detail why I love the benefits that a large TV can bring to your agile team... Really!
2. More whiteboards - Whiteboards have transformed how we work at McKenna Consultants. We use them to; draw wire frames, discuss ideas, make lists, come up with technical architecture, stick things to it, display the World Cup sweepstakes and even as a kanban board before we went digital! There are many more ways to utilise a whiteboard in your office. We cover every spare metre of wall space with them! Just remember to photograph any moment of brilliance before a colleague comes along and wipes the board clean!
3. A JIRA subscription - We started to use JIRA for our digital kanban around 18 months ago and have never looked back since. It is easy to use and great for managing our backlog. We use it in its simplest form as we find that the more you customise and restrict it, the more that the team becomes bound by it!
4. Planning poker cards - A staple of any agile team. If you're not already relatively estimating, start now. It's easy to do and you will be amazed at how accurate over time your estimates become! If you don't want to buy them... make your own!
5. Books - CPD is a big part of what we do at McKenna Consultants and it's something that we actively encourage the team to do. We have a shared Kindle account and Amazon account enabling anyone at any time to buy or download a book that they need! In a bigger organisation? Why not start a CPD book club, or in a smaller team, each member do a show and tell on a book they've read each sprint! Just try to avoid any titles starting with 50 shades... Some of our favourite books can be found on our training references list.
6. ElfKit Festive Fitness Advent Calendar app - Who loves counting the days to Christmas with an advent calendar? We certainly do, that's why we have made a couple of Christmas advent calendar apps, free for you to download now! Check them out and spread a little festive joy around the office!
7. Scrum ball - I like to keep my teams on their toes - especially in the daily stand up. I introduced a mini rugby ball as a symbol to determine who's turn it is to speak. Once a team member has finished, they throw it to who they want to hear from next. Only the person with the ball can speak. When the stand up is finished, the person with the ball has the responsibility of starting tomorrow's stand up. This game makes it fun (there is a certain amount of heckling when someone drops the ball), and encourages everyone to pay attention and LISTEN!
8. Microsoft Surface 3 - Transform the way you work with one of these nifty little machines. Our CEO Nick has recently moved to this as his work and on the go machine. He has even spared the time to blog a couple of times about it here, and here. 
9. Video camera - During a CPD book show and tell, a team member shared an insight into a book about User Story Mapping. The author suggested that you record discussions around requirements, or as we call them at McKenna Consultants, "User Story Workshop" or "Story Time". The benefits of this is amazing. These discussions can often become detailed, enthusiastic, interesting and key to the product. But if the team is not immediately going off to work on this, some key insights can be forgotten. We found that by recording these short, snappy discussions, we can watch them back and recap on any decisions and suggestions made. It also provides a great talking point for a retrospective! (Which are also great to record!).
10. Toys! - No software development team is complete without some toys! We have Ironman, a Plant of the Apes monkey head, R2D2, lightsabres, an Xbox One... We try to find some downtime now and then to make the office fun and to foster creative thoughts.
11. Coffee machine - The Tassimo in our office is probably the hardest working member of the team. It's not because the rest of the team doesn't work hard, just that we drink a lot of coffee. No one likes rubbish coffee, so don't buy your team and guests it!
12. Dedicated PO - Finally, the thing that all agile teams want for Christmas, a dedicated, pro-active Product Owner. You can have the most highly skilled software development team in the world, with a weak Product Owner and you are likely to build a really good, but ultimately WRONG product. However, with an average development team and a strong Product Owner, you are more likely to build the RIGHT product... eventually! Imagine what you could do with a great team and a great Product Owner. We have coached, trained and mentored numerous Product Owners and find that once this is nailed, the team almost instantly becomes more focused, more productive and happier!

So that's my Christmas wishlist for you and your teams, see how you can make the most of some of these things! Maybe you could adapt this to a themed retrospective, or wait patiently for next week's blog post... 

The Value of a Product Owner

One of my existing agile consultancy clients has booked me in this week to do some follow up coaching and consultancy after our initial session. The client in question faced one of the most common challenges that teams I encounter are facing - lack of/confused/mixed/missing product ownership.

With this in mind, the follow up session has a focus on what is product ownership, who makes a good product owner and the value of having one dedicated product owner.

As I am going to be going over in detail some of these points with my client this week, I thought that I would share with you some of my key thoughts on product ownership.

Product Owners...

1. Are responsible for the product, but this doesn't mean that they should be afraid or too proud to ask for help.
2. Are part of the team - they should feel part of the development team.
3. Are not "the boss" of the team.
4. Are there to make the life easy for the development team. I try my best to constantly remind my team this!
5. Need to be close to their stakeholders.
6. Need to have an interest in technology (or whatever sector your product sits in).
7. Must make brave and sometimes unpopular decisions (try telling your CEO that they cannot have a feature that they love!).
8. May not be appreciated by the organisation at first (especially organisations new to SCRUM, agile etc) but must celebrate their successes in order to earn respect.
9. Should not pass the blame.
10. Are critical to the success of the product.

I think that the following sums up the importance of great product ownership perfectly:

The best computer programmers ever in the team + a poor Product Owner = A really great but ultimately WRONG product

Average computer programmers in the team + a great Product Owner = The RIGHT product (eventually!)

The client that I am working with really understand this and want to educate their team and are looking to recruit a Product Owner from within the organisation's ranks. This is a great strategy for them as the new Product Owner will already be familiar with the product, stakeholders and the team that they will be working so closely with.

Product ownership is so hard to get right, but once you do, your company will reap the benefits!