Agile Coaching Exchange – Improv with Paul Goddard

We are always told or talking about how important collaboration is, but very few people actually take time to practice it and unleash it’s full potential. Improvisational Theatre (or Improv, as it’s more affectionately known) requires the actors on stage to collaborate effectively to build a scene, with no pre-written script.
i10Paul Goddard has studied and practiced improv, tailoring a variety of simple games he plays with agile teams to help illustrate the power of collaboration and its creative benefits. 

Viola Spolin (1906-1994) was an important innovator of the American theater in the 20th century. The Improv started from teaching kids a second language and using games the children picked up the words quicker. She also published a book called “Improvisation for the Theatre”.

Then Second City was formed in Chicago as an improv group with the likes of Mike Myers to Steve Carell. Then Keith Johnstone bought improv to the UK. Paul spends time in the Comedy Store watching these techniques and seeing how they can be used in everyday business to improve successful delivery of projects.
i2Gift box Exercise

2 people
1 person is holding an imaginary box
Person 2 takes things out and both people need to agree that it is what is said and state that they agree.
It is Collaboration exercise that shows you need to let go and not be afraid to be wrong or silly

Yes and…
Yes shows:                              And comes from collaboration…
Appreciation                           Adding
Acknowledgement                 Building
Heard                                      Collaborating
Validation                               Connecting – Inspiring, Creating

Collaborating is a willingness to share, accept and sacrifice for something better as a team

Continuation of the Gift box game is – What I like about your idea is… And….

Offers are the basic unit of currency for improvNeil Mullarkey
Provide, listen and extend offers
i1Blind offers

An example of an offer is “good morning doctor”, “good morning nurse”
Person 1 mimes an offer, person 2 interacts with the offer and afterwards if they shake hands if they agree
EXAMPLES – open a window, bounce a ball

Tell a story
Person 1 tells a story and person 2 Can only say no (block)
Person 1 then have to update the story as this happens
Maximise offers and minimise blocks (stops moving forward)
Yes, but… Is a block
You need to be able to turn a block into an offer

A great collaborator knows how to turn a block into an offer – Neil Mullarkey

One word at a time storytelling
The day we went to the airport…
With a team of least four
Can fire out to the audience for suggestions
Improv is in the moment, you can’t plan in advance with meetings so you need to be able to think on your feet and turn blockers into offers

Good offers = specifics
These make the next few words go quickly
What’s the first word that comes into your head
Can’t know where it’s going
Collaboration is the merging of ideas as no one person had control
It’s exciting when you don’t know what’s happening next
Improv is like a man walking backwards, don’t know what is going to happen but can learn from the past to shape the future Equal responsibility and ability to contribute
Esther Derby wrote a good book on retrospectives
One word games can be played in the retrospective or sprint goals:
The moral of this sprint was and then one word each
Sprint goals – the point of this sprint is…
i9Questions only

4 people 2 opposite each other
2 meet and then you can only converse in questions
Shout die if not a questions of no words
Start with: In a supermarket

Naturally programmed to provide solutions
Used to ask more questions rather than give answers, make sure you dig down
What do you think we should do?
If you don’t know – ask the team
i12The three headed expert

Ask questions
1 word answer, collaboration, all equal
Choose a theme to ask/answer questions on
Interviewer provides offers – the coach has to ask the next question, don’t know what the answer will be and need to ask the next one to be easy to answer
Need open questions not closed

These games were good fun and got the group up, interacting with each other, laughing about the silliness rather than being embarrassed. It will be interesting to try some of these techniques out and see how these can get teams to be more collaborative, having an equal say in projects. Paul ran a great session and it was good to see everyone get so involved and by the end of the night actually enjoyed looking silly having fun.

If you’re interested in finding out more and how these games can be used in your teams don’t hesitate to ask.

Agile Transformation


I was at a customer site today and the customer was having issues with “Agile Transformation” and how to open their department’s eyes to this process, not only their department but the rest of their Organisation.

The concern was about how to convince people to try something new and move away from the normal waterfall approach. It is very interesting to see how people are afraid of the unknown and doing something new. For me you can’t get an organisation to change without proof. You need an initial, maybe small, project where you can actual show people what the differences are and how this works compared to the old approach. When you can show that changes aren’t going to cost anything, that their are demo’s so you can see how the project is going at regular intervals. That the stakeholders and users have a say in what is being delivered rather than just being told this is the software to use.

If you are having similar issues or just need a steer at how to encourage people to try something new I’d recommend reading this as it’s a good little insight. The other thing I do is not use words such as ‘agile’, ‘scrum’, ‘kanban’… These words don’t put a customer at ease, it can be like you’re part of a cult and they have no idea what you are talking about. People want to see something in action, once they think it is the right thing then they may want to know a bit of background about it. Show and then tell.

Behavioural Design – Gamifiers

I’m looking into how to engage users to use the ‘thing’ you have designed for them. Hence I thought I’d pop into the Gamifiers meeting at the Google building sponsored by Leaderboarded and Dice Holdings. This is a slightly different way of running a meeting as they have several talks with people giving updates and a CEO from a company come and tell you about how and why they have made the choices they did for their company.

There were several speakers. It was highlighted that the Gamification 2013 conference was coming up.
This highlighted that IBM have linked up with Badgeville as to probably increase their gamification offerings.
The next talk was by Phil Wride, who used to run the online community for FIFA. I can imaging this job would keep anyone busy! He made an interesting point the a Facebook Page is an audience, but a forum is a community. It’s true, it doesn’t matter how many people ‘like’ you or your product. If they don’t talk about you or to you then they are not engaged with your offerings.
The CEO of Bizify, Fergie Miller was interviewed and asked how he got his users to ‘stick’. It’s a good idea for having a section in the meeting dedicated to startups but I would have loved to see the site and have Fergie walk us through his decisions.
The last talk was bu Dr Anne Hsu who talked about designing for behavioural change. It was very interesting that the reward path has been proven but I suppose no eureka moments for me in the talk.
It was an interesting meeting, I’m not sure why it’s 9-10.30 in the morning as this does reduce how many people can make it and most people need to run off afterwards. I would have love to see more demos and what incentives worked and what really didn’t. I hope these will start happening in the next meetings.

How to split user stories – London Agile Discussion Group

The London Agile Discussion Group were talking about How to Split User stories which is a topic of great interest as it is hard to do this quickly but well and it is always great to hear how other people deal with similar experiences.

You start a project and depending what side of the fence you sit on depends which issues/experiences you may have. For me in the Business Analyst role on a new project you need to ensure that there is a clear vision for the team to work towards. Then you start working on the requirements with your Product Owner/Customer. This is where it can get interesting as even what seems like the most basic requirement actually probably isn’t. A request for a login page seems quite innocent but if that if the only acceptance criteria is that Job Blogs can login and that is what is delivered I’m pretty sure most customers will say that is not what I wanted. There are different levels of requirements, bronze, silver and gold. What is needed now and how much time do they want spent on this requirement. Do they need registration as well, do details have to be collected, does it need to link to LDAP? Even a story that seems basic need to be split a little more.

Why do you split stories? We came up with a few reasons but there are a lot more:

  • Promote discussion and understanding
  • Several people can work on it
  • Reduce time to deliver and get feedback
  • Fail fast
  • Fit into an iteration
  • Improve acceptance criteria
  • Get better requirements

There are different ways to slice up a story, vertical or horizontal.  Most developers trying to break down a backlog into smaller chunks will automatically head down the path of using a “horizontal slice.”

slicingA horizontal slice is basically a slice through the feature or backlog that horizontally divides up the architecture and this isn’t the wrong way of thinking about its as most things are built this way. If you were to build a house, you would slice up the project horizontally. First you would pour the foundation,  then put up the walls. Finally the roof goes on and many more steps, leaving the finishing work for last. This same thinking usually gets applied to breaking up backlogs in Agile development. It would seem silly to build a house where you finished one room completely at a time.

There is a distinct difference though, between developing software in an Agile way and building a house. In Agile software development you don’t know exactly what you are going to build until you are done building it. With a house I hope this isn’t the case! You start with some blueprints that you have drawn up ahead of time.  You know exactly where each wall will be and where each outlet will be.  You may have even built houses before that are very similar. When building software, unless you are taking a waterfall approach and planning everything upfront, you don’t know what you are really building until you are done.

To be Agile means responding to change. Building a house, you do not expect the customer to say “hmm, yeah, I don’t really like that wall there” or “actually, I am thinking we are going to need 5 bedrooms now.” In developing software when the customer can see how it is turning out, requirements may start to change and new ideas appear.
slicing hVertical slicing is basically building one room at a time. It is not functional as a house straight away, but we can pour more foundation, change how we are going to do the rest of the rooms and even knock down the walls and start over without incurring a huge cost. The point in building our software “one room at a time,” is to give the customer a chance to see the product as it is being built and this enables them to test it out. They can’t live there until it is all done.  But, they will have the ability to step into a room and envision it with all their furniture in there.

Customers don’t care about foundations and framed in walls.  As a developer, you may be able to look at some foundation and framed in walls and envision what the house will look like, but the customer can’t and worse how can they test it? Vertical slicing in software development is taking a backlog that might have some database component, some business logic and a user interface and breaking it down into small stepwise progressions where each step cuts through every slice.

The idea is that instead of breaking a backlog up into the following:

  • Implement database layer for A, B and C
  • Implement business logic layer for A, B and C
  • Implement user interface for A, B and C

The backlog is broken up into something like:

  • Implement A from end to end
  • Implement B from end to end
  • Implement C from end to end

Developers think about the horizontal slicing when planning out the implementation of a backlog, wanting to implement things by building one layer at a time. Thinking about how to break apart a backlog into vertical slices requires a step outside the understanding of the code and implementation, instead thinking about the backlog in small pieces of working functionality. There is always some progression of functionality that can be found in a large backlog. Meaning there are always smaller steps or evolutions in functionality that can be created in order to produce and end result in software development. Sometimes the steps that are required to break up a backlog vertically are going to result in a bit of waste. Sometimes you are going to purposely create a basic user interface that you know you are going to redo parts of as you implement more vertical slices. It is better to plan small amounts of rework than to build up an entire feature one horizontal slice at a time and have to rework huge parts of the feature that were not planned for.

Vertical slicing is about delivering working functionality as soon as possible, delivering working functionality as soon as possible is important and valuable.

There is a good flow chart on how to spilt stories how to Split a User Story that helps you break it into smaller sections and obviously mentioning INVEST that we reviewed in the meeting. Stories should be:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

ecWe then split into small groups to run through an exercise on Elephant Carpaccio. You ideally need 2 hours to run this and you need developers for this. We decided to do it without the coding and show and tell. You need to make a calculator, what are your stories for this, how do you split up the project and how do you ensure you get value sooner. I think this exercise was an eye opener and I’d like to run it again as it makes you think, trying to work out the priorities and what would be most useful. I also think it was good as it tried to make you split up the stories as small as possible but each story had to add extra value and could be demoed. I’d recommend this to teams to help developers see the different on how you could split stories. It was a very interesting session.


Xanpan by Allan Kelly

This was a talk hosted by Skills Matter who had invited Allan Kelly to talk about Xanpan. What I actually really like about Allan Kelly is that he believes that every team should create their own methodology not stick to a text book version. From this theory he has mixed Kanban and Extreme Programming (Xanpan), added in a bit of product management, some Economics and a little of Lean thinking. The talk can be found here.

He believes that to be successful you need to focus on the teams and their needs not projects, that time is set aside for both planned and unplanned work within iterations and that work flows across these rather than a start stop process. One team using this approach claims to be able to deliver “to the day.”

Allan starts the talk with the comment of “what do you get if you cross Kanban with extreme programming?” and described the talk as his cigarettes and colas talk. This originally came from when he was asked to present at the BCS conference. He had already started writing his ideas down using the self publishing tool Leanpub. I’m glad that he realises that there are already too many methodologies around and we really don’t need another methodology. He is presenting not another methodology but an idea that you are not chained to one way of working, that you need to test different things and see what works within your team.

This is why it is his cola talk, teams need to choose what type of cola they want. Is it Ken and Jeff’s scrum cola, Kent Beck’s XP cola or even David Anderson’s Kanban cola. There are a lot of varieties out there but what one person prefers does not mean it is your favourite.

Thinking beyond lean was the book inspiration that started Allan to think how things could be done differently and maybe better causing him to write about the blue-white-red process. The original idea was using lean and XP to improve processes rather than test and fix cycle. You need to make sense of the world you’re working in, that the supply of a product is constrained but user demand is exponential. As Allan looked into this idea more he came to the conclusion that Just using lean and XP is not enough, so started thinking XP with kanban/lean. Then you need product management and finally would you not need scrum, BA, testers… Each team is different and trying to achieve a set goal and the methodologies used should be those that allow the best working pattern for this team.

Xanpan Principles
– iterations
– team centric not project
– allow for planned and unplanned work (there is always unplanned work)
– no projects
– software is living therefore there should be no end date
– invest in quality / quality is free (quality takes more time but in the long run it over balances so is cheaper than fixing bugs which is the most expensive)
– dis-economies of scale, bigger = more expensive, smaller is better
– Flow: emphasise, level the flow – work out when is busy/quiet times and plan around this, span iterations if needed
Goodhart’s law
– constructivism learning – learn from what you do, not what you are taught. You need personal experience
– visualise – seeing is believing, can share visually

In Practice
1. XP technical practices –  can use TDD, CI, etc
2. Teams can work on more than I stream, more than 1 project
3. Break down stories to tasks – designing process when breaking stories and gaining requirements
Colour code the work depending on what it is, epic, story, unplanned work
Estimate in points
Small is better – think small
4. Benchmark against self – velocity, no commitment (can’t have commitment and estimation, you’ve already committed)
5. Flow
– use product ownership to restrict flow (PM and BA)
– apply WIP limits across iteration and columns
–  absolute prioritisation – no MOSCOW as over 60% is a must! Rate, for example, 1-5 for importance and set a limit.
6. Planning levels (horizons) but plan fortnightly, monthly, quarterly. Use Value based roadmaps for longer time not effort based.
7. Pick n’ mix, pick the bits that work and loose the rest
8. Action over words, do first and then talk about what you learnt
9. Fit work to the time
– deadlines are good, people work towards deadlines
– limit WIP
10. Evolutionary change
– small bangs are ok, piecemeal change
– but big bangs are bad

Iterations and flow
Strict iterations BREAK flow and are BAD
It causes the Testers drop standards and gamify results so they finish in time
How does business value fit into strict iterations ?
Flow through iterations, there will always be something to deliver and demo Stories shouldn’t be more than 3 sprints

Breakdown Stories
Have a planning meeting and usually this surfaces information that is useful.
– software design
– requirements elicitation
– opportunity to reduce scope

Colour scheme example:
Epics – not desirable red
Stories – white – planning poker estimates
Task – blue – ball part figures for tasks
Yellow unplanned work

Story Points are a Currency that floats – not a target to hit and if they become a target they will fail.
The Team creates its own board – should be physical not on a computer

Is it useful?
People need their own method
It is like rolling a cigarette, everyone does it a little differently but what do you like, what works? You need to  work out where to be tough and where to be flexible What’s your teams cola?!

The talk was good and I like the fact that he realises and vocally advocates that if you stick to the text book then you are in danger of doing something wrong and missing opportunities. I am always anxious when I’m told a team is strict, for instance, SCRUM as what if something isn’t working, what if the retrospective raises something that doesn’t sit well in that methodology. Do you just ignore it and carry on regardless? Thanks Skills Matter for hosting that talk!

Agile Talks and Conferences

There are a lot of Agile Conferences that happen throughout the year. If you are interested in finding out what is going on this site is quite useful.

The good thing is most places are recording the talks, so if there is no budget you can still watch and learn. You do miss the discussions that arose from the talk afterwards but it does allow you to hear the latest ideas being promoted. Agile on the Beach in Cornwall has just happened and the videos and presentations are up. There was a good mix of agile for developers and agile for the business.

Coming up in London is the Business Analysis Conference 2013 with a few more talks on Agile for a Business Analyst including one of the Agile Practitioner Organisers, Christian Heldstab, talking about 10 Things a BA Should Know About Agile.

Another place for good talks is Skills Matter who have courses and some free evening talks, which are recoded as well in case you can’t make it.

This year I went to Sync Conference, which for next year will be in October where there was an agile stream and a technical stream. It’s only a day but there were a good crowd there and you table hop at dinner which allows you to speak to most people there.  The talks can be found here.

Sometimes I think there may be a bit too much information out there! Though this way you have no reason to stop learning.

Flow Chain by Bob Marshall

discussion1Flow Chain was a Meetup help by Agile Practitioners at Pearson’s given by Bob Marshall, known for his ideas on rightshifting. FlowChain is described by Bob as his model for how to organise a knowledge-work business along flow, synergistic and systems thinking lines. Organisations in the real world that have discovered and implemented (some) of the aspects of FlowChain include Reaktor (Finland) and Motek (California). Just to clarify Flow Chain is a framework to surface issues, not a methodology to resolve them.
Inband Improvement

Bob started with a Pecha Kucha, which is a deck of slides with one idea per slide, he spends 20 seconds per slide and then at the end we vote on what we want to learn about and then we spend about 10 minutes per topic voted for. These included:

  • Product Development Flow chain – How can we run organisations that are focused on new products?
  • Idealised Design – How would you rebuild a company if you were doing it all again?
  • Theory of Constraints – The company is only as strong as their weakest link
  • Companies are Organic – As the organisation perceives and accepts its organisational self-structure, more of its organic experiences, replace the present value system.
  • The Red Queen Effect –  Also referred to as the Red Queen’s Hypothesis, Red Queen or Red Queen’s race, is an evolutionary hypothesis. The term is taken from the Red Queen’s race in Lewis Carroll’s Through the Looking-Glass. The Red Queen said, “It takes all the running you can do, to keep in the same place.” The Red Queen Principle can be stated thus:
    In reference to an evolutionary system, continuing adaptation is needed in order for a species to maintain its relative fitness amongst the systems being co-evolved with.
  • Politics – Want to reduce the politics, keep calm and focus on priorities.
  • Covalency:
    – What is the need of all the stakeholders?
    – Can all of these be achieved?
    – What needs to be done to achieve this?
    Tom Gilb has done a lot of work in this area to ensure people quantify requirements properly
    – What isn’t working at the moment?
    – How does the organisation build products?
  • Single Piece continuous flow –  Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create and throw away know-how, at every opportunity. Need to keep this knowledge, not lose it.
  • In band improvement:
    – Plan, Do, Check, Act PDCA
    – Meaning sprint planning, do the work, retrospective and then feed in the output of the retrospective for the next sprints.
    – Toyota product development process was a good example of learning how to improve their process
    – Operational Value Stream Owners request something. This causes a backlog to be created, there are a pool of people who can work on these. Item moves into WIP (work in progress). The ideal item size is 1-2 days for 2-3 people.
    – In band is feeding back into the process of how that item can be better, an improvement suggestion and this can then be added into the backlog.
  • Evolution – Seeking the ideal
  • Emergence – Flocking behaviour, one alone isn’t great but together complex behaviours can happen. Pack is better than single.
  • Systems Thinking
  • YANGI – You ain’t going to need it
  • Self Organisation
  • Prog.nosis

Book recommendations:
The Phoenix Project
The Goal
Learning to See

The meeting was good and there were very interesting discussions from it, but it is one thing identifying the ideal solution, it is another to be allowed to implement it. How are these conversations broached, especially if you are a third party implementing as it suggests that you didn’t do it right the first time? I think you need to have a very open channel of communication with your customer and upfront book in time regularly to deal with technical debt and improving the deliverable. It would be good to hear from companies that are using this methodology and how it is working for them.