The pursuit of happiness; A journey towards large scale scrum - Matt Winn - Agile SG 2013

Presented in Agile Singapore 2013 Conference

Matt will discuss an exciting and large scale agile transformation happening across the globe in JP Morgan’s Core Processing Technology division. During this talk Matt will share some of the challenges and pitfalls the group faced while trying to be agile and some of the tactics being applied in order to improve all the time.

Transcript

1. Introduction - Matt Winn, ‘Line Coach’ , J.P. Morgan Singapore. Core Processing - Technology, work on Securities. That’s stocks/shares/fixed income rather than ‘Security’. The teams build the systems that move stock and cash around the world, and maintain the firms ‘books and records‘. This is central for a number of other key activities. 7 x Teams in Singapore, I’m also helping around 70 team members in Manila location on their journey also.
2. ‘Happiness consists in tranquility of mind’ -Cicero ~ Cicero Why Happiness The Pursuit of Happiness is an essential human right. Both Confucius and Socrates implied that happiness and personal growth were a major purpose of life, and a central goal of education. According to the Federalist Papers, written by the founders of U.S. government, "A good government implies two things: first, fidelity to the object of government, which is the happiness of the people; secondly, a knowledge of the means by which that object can be best attained." Roman philosopher, politician, lawyer, orator, political theorist, consul and constitutionalist. Cicero was assassinated.
3. Talk today is centered around sharing my experiences with Agile Adoption in a large organisation. Some of the lessons we’ve learned and some of the improvements we’ve made; and improvement experiments we’ve run. Hands up people who are being agile in their organisations, hands up if there are more than 50 developers in the group. Hopefully be some parallels between our experiences and yours. Bring back to talk title - pursuit, you never actually get their its the journey itself that you live.
4. We adopted agile and it worked quite well in small teams. Our challenge was scaling. The parachute represents all the things which were slowing us down, and the larger our agile adoption was the larger it felt like the parachute was. As we scaled more and more organizational constructs became involved which started to create compromises with some of the intents of the agile manifesto. Best Practices guides pushed into teams Functional Departments - IA, BA, TA, QA Multiple Layers of Management - Dev Management, Project Management, Program Management Component Teams, meaning even within ‘development’ Locked Down Source - if you need a simple change you are caught up in another teams release cycle Variability - production support and continual interruptions causing challenges with a stable velocity and prediction of release dates Targets and measures -
5. Agile Playbook, states tooling, references architectural practices. implies that development teams need to be proscribed to. 1.0 document. Wiki!!! Assumes ‘economy of scale’ of fungibility as over-riding factors. In reality create barriers that can sometimes slow us down making working software.
6. Up front estimates, often mis-interpreted as commitments when they were ‘estimates‘ Detailed gantt charts which assume accurate prediction of how the project will pan out over the course of 6-12 months. PM required to co-ordinate between the BA, TA, Component Development Teams, QA, USER base implementation..... Simple features from a customer perspective can take 2-3 months if they cut across several organisational boundaries.
7. implies people get promoted to their level of incompetence and then remain How do we identify first level of management. Call it L1 management. Often the best value worker. All of a sudden in the deep end. Takes years to become ‘good’ manager.
8. Draw Picture - Burden with coaching, career development, training plans, appraisals & assessments, recruitment, tasks management, escalation.
9. Locked down source. One team may need simple change. Don’t have access to internal libraries or ability to release them. Perhaps hooked into 2 month schedule. Frustration, and inertia can result.
10. Variability.... harmful to Scrum. Two kinds of variability. Manageable variability - vacation plans. Un-Manageable variability, building flooded/sick leave... Production Support.... continually divert team members/SMEs in a very unpredictable fashion away from sprint deliveries.
11. Dispersed Teams..... 2 Team Members in Bangalore, 5 Team Members in Singapore. Not Working. Guys in Bangalore are good. Why? Standup - over the phone Sprint Backlog - tools rather than visual display Barrier to paired programming. Makes design workshops more challenging Retrospectives/sprint reviews
12. Tyranny of Measurement Bass Vodde - code coverage... example, test with no assertions. Velocity - comparing between teams, results in estimation padding to make velocity look better. Deming - substitute targets with leadership.
13. Draw - one feature. 3 Component teams, component level acceptance... many sprints. Even in trunk development unless component teams sprinting implies integration period. More sprints before components are integrated & shipped to production the bigger the problem will be. At some inflection point it takes longer to integrate and integration test than it did to do the development in the first place.....
14. Technology management are product owner...
15. Hard and fast dates and unsustainable working patterns. Long cycles with delayed feedback lock teams into these situations..
16. Epoc. Reset... Craig Larman talk to Technology & Operations Management. Craig & Bass Vodde are experts in Large Scale Scrum and had observed the challenges Core Processing was facing in many large development groups in the past. Appetite to make meaningful changes and adopt real scrum to address inefficiencies, Improve agility
17. Removal of dispersed teams.... Co-location of teams, self forming and self-organised. Ability to work together face to face, breaking down communication barriers. timezone, stand ups, whiteboard design, paired programming...
18. Co-located teams are able to work with physically materialised team areas. JIRA - information hiding, task granularity, chasing for updates. These things are largely gone.
19. http://www.craiglarman.com/content/feature-teams/feature-teams.htm Component teams become feature teams.... Mixture of domain knowledge, technical skills Ability to take on ‘feature’ rather than part of a feature.
20. Pairing.... those with skill and knowledge impart via pairing pairs rotate regularly - maybe pairing ladder or promiscuous pairing techniques are used.
21. Elimination of organisational Barriers, working to title. developers only develop if there are testers. BA’s only write specs. Functional Managers find new roles - join teams, become ‘value’ workers. Leads to lean wastes of waiting, over production resulting in WIP Removal of organisational barriers, meaning that one team can cut across not just architectural boundaries but also functional boundaries.
22. Line Coaches/ Mentors Flatter structure. Manager as coach and mentor. Small number of experienced line coaches, maybe up to 100 team members/scrum masters per coach team members will also seek mentors/coaches from other teams in order to help them improve and x-fertilise across teams
23. Self-organised teams make most if not all decisions them selves. They seek advise from line coaches/SMEs but have auto-mony on several things. Slide shows Manila feature teams selecting full team scrum masters in facilitated session . because team members are intelligent, skilled knowledge workers they are best placed to make these decisions rather than having them imposed from above
24. Internal Open Source - need a change made to a library. Make that change, if necessary ask for help from SME/Component Guardian Requires good level of automation and CI , and ‘build quality in’ techniques like paired programming to ensure that issues are not created by team mebmers not familar with the code. Removes lean waste of ‘Waiting‘
25. Kanban for ‘small’ urgent items. Production Support tour of duties. Elimination of variability from most of the teams scruming
26. Continuous Integration but at a feature level. If you have feature teams there will be feature level tests. Not having end to end CI can be an organisational failing
27. Continuous Improvement. Aiming to always get better Teams have freedom to run Improvement Experiments each sprint without asking permission In some progressive teams - developer days!
28. Environment of continual learning. Example - Hardeep on Encitec Libraries Lunch and Learning
29. Red/Green Screens (recent Improvement experiment) Build Cop Role Encourage CI practices, show the floor that its important with build visual signs
30. Happiness, teams involved in their own destiny are happier places to work!
31. Next - Product Owner.... Red and Green