Using improvisation to improve teams

Daryn who runs the Agile Practitioners Meetup has taken part in a number of improvisation classes and was impressed at how fast the facilitators build trust within the room. Within the first class he could see groups of people self organising and showing signs of genuine improvement, while enjoying the experience. He felt that the Agile world could learn from the world of improvised acting, therefore invited Paul Z Jackson, President of the Applied Improvisation Network, to come and give us a workshop and share some of the experiences of improvisation.

In this practical session, Paul Z Jackson shares secrets of improvisation and explores the deep connection with Agile.   It started with getting to know each other. Imagine the world, then stand where you were born and introduce yourself and say what location you are standing in when it’s your turn. Then we had to stand somewhere you wanted to go and say why to the group. Nice little ice breakers. We then had to find a partner, a group of 3 and a group of 5 to remember for the evening.

In the group of 5 you had to state your name again and why your name was special, a lot of interesting comments here and a realisation that all the names somehow linked to the bible! Then we needed to state why we were there that evening. It was a good exercise so Paul could gage where to go next, whilst we got to know each other and relax a little.

Then we got into our pairs. The task was for one person to draw a picture and the other to rest their hand on yours and follow the motion (yes, and). Each person got the chance to play both roles. Then you have to re-do the task but this time instead of resting your hand on the artist’s hand there needs to be resistance (no, but). The end result is a picture that wasn’t the one planned! I suppose this reflects the difference of working together and being resistant to the direction the person is trying to go.  This shows one case where you are working collaboratively achieving what the artist wants, the other working disruptively probably not achieving what either party wanted. It’s meant to highlight the importance of trying to work together.

The next game was also in our pairs we were asked to draw a face and name the face in silence. We were allowed to draw one item but if the pen left the paper the other person had to take over the next part, alternating between the pair. When someone hesitated with the picture then you had to name the face, one letter at a time, taking turns between the pair. Then we needed to present our ‘person’ back to the group and say how we felt about that exercise. Could we work out what the thing was your partner drew and build on it? How did it feel not be in 100% control, did the picture end up like you’d imaged? For me it’s not what I had imagined but working with someone else bought in creativity that I could build on.

We had to redo the exercise again, this time with a vision to be more creative. This was more interesting as the first time you start simply and safe. All groups started with a circle and the partners all interpreted this as the face outline. This time we all started with a different part and the pictures that were created were definitely unique!

These were all non verbal improvisation games so we moved onto the verbal games. We sat in a circle and were given a story and we could all add a line to the story to build it up. It was an exercise that should what sort of sentences help a story and what causes the story to crash and burn. For me it was a good way to highlight how easy it is to accidentally kill creativity in a team if you don’t encourage ideas. We re-did the exercise with a new story but we could had to start our sentence with “yes, and then”  to see how it was easier to keep the story going.

I really enjoyed the session and it does make you realise how easy it is to make or break the team dynamics. Some good ideas of how to get the team more relaxed together.

For more about Applied Improvised acting please visit the following links: 


Planning poker

This fortnight’s discussion at the London Agile discussion group was all about planning poker. What is planning poker and who should be included in the process? Should the Product Owner, ScrumMaster, analyst take part in sizing? Do you size development and testing separately?

The session started with a brief description on what planning poker is and when you use it.

Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads a agile user story or describes a feature to the estimators. 

Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.

If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.

The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.

Then people stated what topics they wanted to cover which was captured and grouped using post it notes. These suggestions included:

  • When should it be used? Alternative methods

This was quite interesting as for me I would only use planning poker in an estimation session, getting enough stories for the next sprint. Not all the stories in the backlog will be delivered so why would you spend time sizing them. To follow the just in time theory, make sure you have enough stories sized and agreed on that will keep the team busy for the sprint. Potentially if the velocity increases have some stories that have been analysed and have the acceptance criteria ready ready so another sizing session can be run during the sprint.

From experience if you size too many stories that are not developed in the sprint, when the developers come to doing them a few weeks later the memory needs to be refreshed exactly what was involved, so if you try and do too much upfront this adds delays later on in the process.

Alternative methods included sizing by functional tasks, though I feel this will take more time and this is meant to be an estimation that you don’t spend too long or too much energy on. It’s a way to create enough work for the iteration. Some teams don’t estimate using planning poker but use BDD in the planning session, writing their tests and from this work out how many stories they can do.

  • Who should be involved?

Interesting to see what people do! The consensus was to have the whole team there, as in agile teams this is normally less than 10 people. This session is useful to have the team in as the Product Owner of the Business Analyst presents the story and is there to answer any questions so everyone hears the same information.

Some teams just have the team delivering sizing and others included the PO, but when they average out the numbers the non-delivery peoples’ numbers are not included. The advantage of getting the PO to size is that is they size low and the developers/testers size high it can highlight a difference in understanding of the exact capability the PO needs.

It is useful to have people in there that have testing knowledge as sometimes a change that is very simple can have a massive impact on the existing system so a lot of regression testing will need to be done.

There is no ‘correct’ solution but try different things and see what works for your team.

  • When do you send a user story back – what is too big?

The majority said that if it were 8 points or higher they would push the story back to the PO to split it further as higher than 8 brings in more uncertainty of exactly what is needed so if it can be split people will get a better understanding. Though it was highlighted to remember INVEST and that the stories need to be independent when they are split into smaller pieces.

  • Resizing? When do you lock a story down?

When a story enters the sprint the size is locked down. During planning poker you may want to resize after the people with the highest and lowest scores have explained why they have voted this way.

  • For the Release plan do you size the whole backlog?

It was highlighted that managers like knowing how long things will take. For the backlog majority of places size this using T-shirt sizes to give a basic estimation of time. In Agile you are always learning and adapting to needs so what is in your backlog and what is delivered is rarely the same so sizing a project using requirements is hard. A project could be time boxed, delivering the prioritised items first and then see where it is at the end of the time box.

There was a good selection of different experiences with the people involved in the room which allowed a good discussion. To me there is no book way to do these things, each team is different and you need to be flexible to allow for this.

How to be an Agile Coach

It was a London Agile Discussion titled “So you want to be an agile coach? Well, what is it and how do you become one?”

We split into 3 teams and the first exercise we did was to write on post notes everything we thought an Agile Coach did and the characteristics they would need to perform this role. Then we reviewed the things we had written down and had to put C (coach), S (scrum master) or both on each post it note if we thought this was a role that the Scrum Master may also do. Do both these roles do a similar thing and need the same characteristics to do well? Is an Agile Coach just doing the Scrum Master role but just on a bigger level?

IMG_0058From this we were given categories to sort the cards into which were meant to be the different types of Agile Coaches, including guide, cheerleader, guardian of quality and performance, servant, shepherd, bull-dozer or others. These choices came from the book by Lyssa Adkins. This caused a few interesting conversations depending on how the person imagined each category type to be like.
IMG_0061Then all teams came together to present what they had done, making one main post it note sorting result. If the individual groups had differences with where certain post its should go this was now amplified but discussed to a consensus.
IMG_0063It was a very interesting meetup as for me I feel there are a lot of Agile Coaches but maybe doing slightly different roles. It got me wondering would it be better if someone was a coach first and then moved into agile? Is the real need coaching or is it more counselling? 

Very interesting discussions and a good night.

#noestimates and open discussion

This was the first Meetup held as the Kanban Coaching Exchange has just been taken over by Dan Brown and Helen Meek from Ripplerock. This is meant to be a place where people can learn from each other and have a place to discuss things with others that are using similar practices.
dbThe meeting had a presentation by Dan Brown first and then went into a discussion of what format would we like these meetings to have. The presentation was on “How do you start putting your data back to work for you?”  How can you improve your forecasting and planning, and build better stakeholder trust? In this session, Dan explained  ‘#NoEstimates’, and what you can do to replace the hidden value in estimation, while improving your predictability and allowing better conversations between stakeholders and Kanban teams. When you estimate the time it would take to run a project through sizing and estimation there is only a 60% chance that you will be in the right range, meaning 40% of the time the estimate is inaccurate. How can this be improved?

Dan mentions the Monte Carlo Simulation, a tool that you use existing data to help calculate how long a similar project may take in the future. LeanKit have actually built a Monte Carlo forecasting engine on an existing kanban tool. There is also a Jira integration so you could flow your Jira issues through LeanKit in order to do Monte Carlo. Troy Magennis has also presented on how to use this technique to give better estimations:

Modeling and Monte-carlo simulation allows rapid (and repetitive) “what-if” risk analysis to be performed on proposed or ongoing Lean/Kanban projects. This analysis leads to reliably forecasting delivery dates, cost, staffing-requirements, and informed risk management. This provides options that minimize cost and delivery time, whilst maximizing revenue for a project and portfolio.

Modelling and simulation gives a platform for experimentation before and during a project. Modelling your development process and project allows you to simulate possible delivery date/cost outcomes 1000’s of times, and then compare these results to quickly find those model inputs that have the greatest impact on a final result (cost, date, or cycle-time); and then manage your project accordingly.

Very interesting talk but how much data have companies got to run this modelling, would be good to go through a real situation to see how they did it. Are IT the only department not using modelling?


Body Language

This was my first time at a London Comms Dojo so I wasn’t too sure what to expect, the topic was Body Language!  What we communicate when we aren’t saying a word . . . I was told that I’d learn some of the basics about body language, as well as how to handle contradictions in what people say and what their body language is telling us. I tend to have my arms crossed in meetings and have got feedback about this as they think I’m being defensive when I’m just cold, so I felt this could be interesting and potentially very useful.

The organiser, Lynn, walked us through some basics of body language but highlighted that you need to take a combination of factors to come to a conclusion, not just one. Then we got to play a game. Groups of 3, 2 standing together and the 3rd one has to walk up to the other 2 not saying a word. The two have to guess by the body language what situation the person was walking into, such as meeting friends in a pub, seeing family, meeting clients or job interview. Interesting this was easier than expected but I do feel you pull from personal experience and if your body language was like that what situation are you entering.

The next scenario you were in pairs and the situation was how would you get the other persons attention and the person is in deep concentration. This was quite entertaining and some people were “concentrating” more than others! The point was that tasks take about a third longer when interrupted, and that it takes workers an average of 22 minutes—and not infrequently as much as two hours—to refocus on a task after being distracted. If this is true then how can you manage and minimise the distractions. The discussion that followed was great, some people used timers so you could see when they would be free, others used post in notes and some actually felt they thrived on the interruptions.

The last section was based on things you want to discuss. You write ideas or issues you are having on a white board and then you group on the topic you want to discuss, either help with or learn how to deal with it. It was good to be able to talk freely about issues that you may be experiencing in projects and hear what others have tried in similar situations.

This was a great evening and although you feel quite concious at first, this quickly goes and you’re enjoying yourself before you know it. A lot to think about!