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.
– 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
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)
– 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
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!