Remo Biagio shares his experiences of transforming the BI Development Team at Callcredit from using a DSDM iteration-based approach towards Kanban. This presentation includes the learnings taken and the benefits gained such as stakeholder engagement, speed and quality.

1. Becoming Lean
Remo Biagioni
June 2015

2. Offshore Fog
• Operating expenses have doubled in 15
years
• A fifth of the increase is because of
increased activity
• Poor planning wastes the time of highly
paid staff
• Reliability is awful
• Use of bespoke parts rather than
standard
• Repeatedly predicted falling costs as
they have soared
2

3. Japanese Clarity
• The answer – pushed for by the British
Government – is to copy lean
production techniques
• Aera Energy in California treats well
drilling as a manufacturing process –
managed by a single team from design
to implementation
• Just in time planning
• Cut waste
• Decentralised decision making
• Standardisation
• Visual communication tools
The Economist, pg. 62, May 30th 2015
3

4. A new role
• Core issues
• Productivity
• Stakeholder
Engagement
• Predictability of
Delivery
• Motivate & Engage
4

5. 5

6. Sharpen The Bullet
• Focus on quality
• QAT & UAT => Test Driven Development
• Peer Reviews
• Shared deliverables
• Fixed term iterations
• Continuous Deployment
• Measuring Output
• Iteration planning and review
6

7. Xanpan
• Allan Kelly’s adaption of XP and Kanban
• Idea is to move away from projects
• Strong correlation between maintained
projects and downloads on Source
Forge
• Establish the team
• Feed the team with work
• Prioritise development for the team
• Not a project … a production line
7

8. Getting Started
Requirements Change
• Moved from a waiting – doing – done
whiteboard to a more explicit process
• Focus on quality
• Different process for reports and ETL
• Two types of backlog
• Prioritised – ready to go
• Holding area
• Just in time
• Detailed requirements
• Planning
• Design
• Work In Progress (WIP) limits
• Requirements change at
an average of 2% each
month
• Over 12 months this is a
change of 26.8%
Capers Jones, The Economics of
Software Development
8

9. David J Anderson’s Kanban Recipe
1. Focus on quality
2. Reduce work in progress
3. Deliver often
4. Balance demand against throughput
5. Prioritise
6. Attack sources of variability to improve predictability
9

10. Our process
10

11. Push vs Pull
11

12. Theory Of Constraints
• The argument by reductio ad absurdum is as follows: If there was nothing
preventing a system from achieving higher throughput (i.e., more goal units
in a unit of time), its throughput would be infinite — which is impossible in a
real-life system.
• Only by increasing flow through the constraint can overall throughput be
increased.[1]
• Assuming the goal of a system has been articulated and its measurements
defined, the steps are:
1. Identify the system's constraint(s).
2. Decide how to exploit the system's constraint(s).
3. Subordinate everything else to the above decision(s).
4. Elevate the system's constraint(s).
5. Warning! If in the previous steps a constraint has been broken, go back to step 1, but do
not allow inertia to cause a system's constraint
http://en.wikipedia.org/wiki/Theory_of_constraints, June 2015
12

13. With a Kanban system
most or all of the
stations in the workflow
have WIP limits. … The
local WIP limit … will
stop the line quickly,
keeping the system from
clogging and becoming
overloaded
David J Anderson, Kanban
Drum – Buffer - Rope
13

14. Where We Are
• Initial constraint was deployment
• Looked at our process and optimised it with the Change Approval Board and
deployment teams
• Next came test
• We have one QA resource – his role became one of coordination and guidance
• Golden rule is a developers don’t mark their own homework
• Currently
• Bottleneck is user story and acceptance criteria
• Highlighted a lack of skill creating stories
• Symptom is that developers start working on lower priority work because major work
is not ready for development
• WIP limit is often broken
14

15. Prioritisation
15
Daily
• Remove blocked work
• Manage flow
Weekly – as needed
• Senior users
• Prioritise user stories
within subject areas
Six weeks
• Senior stakeholders
• Ensure alignment with
business strategy
• Agree proportion of time
spent on each subject area
• Size and shape of team

16. Metrics
• Report to the board on function points deployed each month
• Function points are standard and objective
• Cycle time for each subject area
• How long user stories wait before being elaborated
• Time to deploy
• From when elaboration starts to “ready to deploy”
• ETL, Reports and Defects reported separately
• Bottlenecks
• How longs jobs wait in each queue
• Time taken in different parts of the process
16

17. Conclusions
• Cultural difference
• Process and flow
• Pull vs Push
• WIP
• Still no silver bullets
17