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!

Being the Product Owner of the ElfKit Festive Fitness Advent Calendar App

This week has seen us at McKenna Consultants successfully deploy the ElfKit Festive Fitness Advent Calendar App iOS8 iPhone and iPad app to the AppStore.

ElfKit is available on iOS8 from iPhones 4, 5, 6 and 6+ to iPads

This was especially exciting for me as I had the pleasure of being the Product Owner on this project! The app is based on a traditional advent calendar, where each day from 1st December you open a door. Behind each door there is a fun tip to help try and keep you fit and healthy over the Christmas period, hopefully instead of gorging on mince pies like myself and the rest of the team at McKenna Consultants!

We have also added some HealthKit integration and some little gimmicks to make it fun. You can read into more detail about the app on our website.

This app provided me with some unique Product Owner challenges. As a lot of app developers out there will know, Apple can sometimes have a tough approval process. A lot of this comes down to the person at Apple HQ who picks up your app to review.

When we submitted the app, within 13 minutes of receiving the "Your app is in review" email, the app was rejected! Imagine my horror! After a conversation with the reviewer, it turns out that they thought that the app was broken as when they tried to open a door they saw the "Too Soon" image. Now, we had anticipated this, so in the submission, we provided lengthy instructions on how to test the app (by dodging the dates).

Apparently though, the reviewer was adamant that this wasn't enough, and we had to provide a video to support the submission. We duly obliged, with my very own Yorkshire accent narrating the events on screen.

I thought that this would please the reviewer and the app would be accepted, but no! We were instructed to now re-submit the app and join the back of the queue!

As the app is based on a traditional advent calendar, it was imperative that it was live by 1st December, so I have been a nervous wreck for the past 8 days waiting for an answer!

To our delight (and my relief) the app was approved after being in review for a few hours!

You can view the app in iTunes here.

And......... Breathe!

Just another thing that us Product Owners have to deal with!

Our Office TVs!

Following up from my blog post last week on "How To Justify a 60" TV To Your Boss", I thought that I would share with you our latest innovation on our TVs.

Feeling inspired after reading my blog post (that has to be the reason), one of our developers, Mike, suggested that we automate our burndown! Sounds like a volunteer to me!

We have an internal system called the "McKenna Contol Centre" (sounds like something out of the George Orwell Classic, 1984), that we use for various internal bits and pieces, such as automating deployments for clients, storing passwords etc.

Mike integrated a program that speaks directly to our JIRA Kanban and displays a graph of the current sprint. It also calculates the average number of stories and points that we complete over the last 6 sprints! We like to keep a rolling average over the last 6 sprints as this means that the velocity is more responsive to changes in the team. We could have taken a longer rolling average, which would give us a more stable velocity, but this would mean that changes in our sprint would have less of an impact on the velocity.

We are now proudly displaying this on our office TVs!

Unfortunately, Star Trek has given way to the Burndown!

Burn Baby, Burn!

Stand Up! (and be counted)

It's 8:35am and my Outlook is ringing at me - time for our daily stand up.

I perform a variety of roles in my team, from Product Ownership to marketing and sales to agile coach. This doesn't mean that I sit out the meeting and leave it to the devs (we don't have testers, our devs do that, but that's a whole other blog post...). No way! I want to know what is going on and see if I can help!

Photo courtesy of ScrumShortcuts.com

Over the past 12 months I've coached over 20 development teams. Some new to agile/lean/scrum, so not so new. One thing that I like to get nailed immediately is the daily stand up.

Why is the daily stand up so important? Why do I need to go? Why do I care what everyone else is doing? Can't I just email it? Isn't that what the Kanban is for? These are some common questions (excuses) that I hear.

Here are some reasons and tips to help your team take advantage of this traditional SCRUM discipline.

1. It gives the team a heads up of what you have been and are going to be working on - I like to answer three questions; Since the last stand up I worked on... Until the next stand up I intend to work on... The issues that I have are...
2. It gives the team a chance to raise issues to each other - Sometimes sitting in a dark corner with your headphones on "wired in" is not the best way to solve problems. Speak. Collaborate. Listen. Learn!
3. It gives the team a chance to SOLVE issues AFTER the stand up for each other - Don't waste others time by going into detail (or showing how clever you are) of how you're going to help solve some iOS memory leak issues, save it till the stand up is finished and solve it then.
4. It gives the Product Owner the chance to share vital information, feedback and insight with the team - Yes, that's what I said, Product Owner. They absolutely need to be there too!
5. It improves team bonding in only a few minutes - You'd be amazed at what the 2 mins on chit chat whilst you're stood waiting with a coffee for the last couple of members to walk over can achieve!
6. It provides the opportunity for stakeholders to come and LISTEN to what is happening in the team - Anyone can come along and listen. If they have any questions afterwards, the ScrumMaster should be on hand to help out!
7. It provides a mechanism for problems that cannot be solved by the team to be quickly escalated - This is where a great ScrumMaster will come into play to initiate a Scrum of Scrums (or Stand ups of Stand ups).
8. It can present the chance to have fun within the team! - There are some great games that you can play when holding the daily stand up to keep team members on topic. At McKenna Consultants we throw around a small rugby ball (rugby - scrum, get it?!) to indicate who can talk. Sometimes this can be a good laugh, especially if someone is not paying too much attention! I have worked with other teams who do things such as provide weather reports to summarise how their day have been and how they expect it to be! The book Scrum Mastery has some good ideas of how to "Sex up your Scrum".
9. It involves remote team members - Just because you are working with an offshore team in India doesn't mean you have an excuse! Get them involved. Use Skype, FaceTime, Google Hangouts, whatever you like. Just remember that it is important to actually be able to see them on screen! We recently worked closely with Rocket Matter in Florida on an iPad app project. We installed a couple of clocks in our office and set one to London, GMT and the other to Florida, USA, EST and arranged a daily stand up at a mutually convenient time. Guess what? Despite not actually ever meeting the other team members, we got on great and delivered an amazing product
   !
10. Coffee - Do we really need an excuse to make the morning coffees?

When setting up your stand up, you just need to remember two things:

1. Agree a time and stick to it
2. Agree a structure and stick to it

The stand up is hugely undervalued and I am sure that your team can get more out of it that you currently do! Start getting more out of your daily stand up and be counted!