Curing Agile Hangover: Sandro Mancuso and Mashooq Badar
•
1 gefällt mir•1,808 views
Agile adoption brings into focus the shortcomings in the existing engineering practices. After undergoing an Agile transformation for a few years at UBS, where the focus was heavy on process and light on the technical disciplines, it is an understatement to say that we still have problems. We call this the Agile Hangover. Focusing on the technical practices is essential to a successful software project, regardless of the process. Software Craftsmanship principles have been essential in tackling the problems we face. In this talk we will share our experiences in how we are trying to find the right balance between technical practices and processes. Empowering professional software engineers, well defined testing strategy, process automation, high investment in people development, requirements management and strong emphasis on quality have been the key areas we have been focusing the most.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von JAX London
Mehr von JAX London (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Curing Agile Hangover: Sandro Mancuso and Mashooq Badar
- 1. Curing the Agile Hangover with Software Craftsmanship
- 2. BACKGROUND
- 3. Waterfall Process Requirements Dev Test Release
- 4. Teams Divided By Roles Project Managers Developers Testers / Analysts
- 5. Component Teams Dev Team 1 Dev Team 2 Dev Team 3 Component 1 Component 2 Component 3
- 7. Scrum Teams Scrum Developers Product Master Owner QA BA Component 3 Component 2 Component 1
- 8. The Hangover Lack of Technical Expertise S tagnant S kill-set Long running builds Late discovery of Bugs Low Moral Unstable S ystem Requirements not well understood Inefficient Develop, Debug, Deploy Cycles Unreliable and Costly Tests Mountain of Technical Debt
- 10. Low Moral Poor ROI The Hangover Low Quality Us and Them Software Attitude
- 11. Low Moral Culture of Learning • Bring mentors in that could lead by example and motivate people • Internal Communities of Practice – Learning Sessions • Active participation in external communities
- 12. Low Moral Social Coding • Pair Programming • Feature Branches • Pull Request Based Commit Model – Code reviewed by members of another team
- 13. Low Moral Equality - No Special teams - No positions or hierarchies within the teams - Individual efforts are valued and recognised by everyone – No egos
- 14. Low Moral Recruitment - Recruitment is a team activity - Passion is a key criteria - Foundations of software development is more important than technology specific knowledge
- 15. Community of Poor ROI Professionals The Hangover Low Quality Us and Them Software Attitude
- 16. Poor ROI Focus on Quality • Time reserved for improvements – Developers can make a call on what to improve and when • This time is agreed by the business – Improvements articulated so that the value is well understood – Improvements are communicated
- 17. Poor ROI Quality is a team concern • Design Committee to discuss and communicate System Design • Stop and Fix Attitude – No broken windows • Boy Scout Rule – Always leave the campground cleaner than you found it
- 18. Poor ROI Continuous Delivery • Continuous and Frequent Deployment to Production – Release even when minor changes are made • Strive towards One Button process for release and deployment – Release promoted through test environment
- 19. Community of Steadily Add Value Professionals The Hangover Low Quality Us and Them Software Attitude
- 20. A different mindset • Emphasis on TDD – Automated tests at all levels • Business domain reflected in the code and design – Focus on readability and maintainability • Simple design • Healthy intolerance of Bad Code – Develop an allergy for code smells Low Quality Software
- 21. Basic quality checks • Comprehensive static analysis during CI – Code Coverage, PMD, Findbugs, Checkstyle etc. • Quality Gates based on Static Analysis – Builds fail if quality threshold is not reached • Well Understood Quality Metrics – Sonar to visualise and report Metrics Low Quality Software
- 22. Tools and Paradigms • Technology decisions backed by Business Requirements • Understand different programming paradigms • Leverage tools to increase efficiency – For example: build process efficiency Low Quality Software
- 23. Community of Steadily Add Value Professionals The Hangover Well Crafted Us and Them Software Attitude
- 24. Understand the Business - BAs are part of the team (at least one per team) - BAs often pair with developers - BDD and Spec by Example - Developers understand that writing code is just one of their responsibilities - Holistic approach to software development Us and Them Attitude
- 25. Closer to Production Services - Close collaboration between developers and production services - DevOps Us and Them Attitude
- 26. Community of Steadily Add Professionals Value Software Craftsmanship Well Crafted Productive Software Partnership
- 27. Thanks Sandro Mancuso Mashooq Badar sandro.mancuso@ubs.com mashooq.badar@ubs.com @sandromancuso @mashooq
Hinweis der Redaktion
- Mash: NEXT SLIDE
- Mash: Journey from Waterfall – through agile transformation – to where we are nowMASH: NEXT SLIDE
- Sandro: Few years agoSandro: NEXT SLIDE
- MashMash: NEXT SLIDE
- Sandro: Dev teams divided by components – Working in silosSandro: NEXT SLIDE
- Mash: Loads of issues, integration, multiple teams – USUAL WATERFALL PROBLEMSMash: NEXT SLIDE
- Sandro: Scrum introduced (Devs, QA, BA in the team); x-component teamsSandro: NEXT SLIDE
- Mash: After a couple of years – More problems were identifiedSandro: Lack of Technical Expertise, Stagnant Skill-set, Low Moral, Unstable System, Mountain of Technical DebtMash: And that’s what we call The Agile HangoverMash: NEXT SLIDE
- Mash
- Sandro: We discovered we could categorise those problems in four main areas. Presentation is about going deeper in all these areasLet’s start with Low Moral. Without sorting out our people, we can’t achieve any of the other thingsSandro: NEXT SLIDE
- Mash: People didn’t care about their job. Working almost mechanically.Sandro: (autonomy, mastery, purpose) - Culture of Learning - Injection of passion. Mash: Internal CoPsSandro: Participation External communities
- Mash: Developers isolated due to “individual effort”Sandro: Pair programming (Loose pairing)Mash: Feature Branches: (Github) Help understand and visualise the current changes. We didn’t get it right first time or even second. Split a feature into review branches to allows us to commit oftnSandro: Pull request model (if it is too big, reviewers will scream at you)
- Mash: No special teams, Off-Shore vs On-Shore. Very difficult when teams joinSandro: No positions or hierarchies withing the teams. Emergent leaders (implicit recognition)
- Mash: Recruitment is a team activitySandro: Filter criteria (blogs, github account, pet projects) / Not Java Spring Hibernate Devs / Foundation more important
- Sandro: Solving low moral by creating a community of professionals Mash: Next category we identified – Poor ROI – increasingly spending more time to create same value
- Mash: Focus on QualitySandro: Time reserved for improvementsMash: Time agreed by the business
- Sandro: Design committeeMash: Stop and Fix AttitudeSandro: Boy Scout Rule
- Mash: Long periods within release resulted in unstable deployment and functionality. Prod Services: Decreased value, Customer: Faulty ProductSandro: Enable continuous delivery - One Button Process. Same release >> Dev >> UAT >> Pre-Prod >> ProductionSandro: Next slide
- Sandro: The focus on quality and continuous delivery is how we are tackling the poor ROI, steadily adding value.Mash: Low Quality Software
- Mash: Why lack of quality? Cause? How to Avoid?Mash: TDD (You’ve seen test pyramid)Sandro: Component tests (Love and Hate)Sandro: Business domain reflected in the code / designMash: Simple DesignSandro: Healthy intolerance
- Mash: As we all know metrics are not enough to measure quality checks. This is the bare minimum.Sandro: Comprehensive static analysisMash: Quality Gates – Build fails if checks failSandro: Motivation behind is v. important. Devs understand the significance of the metrics. Metrics are discussed. Sonar(LCOM4).
- Mash: Technology backed by business requirementsSandro: Different programming paradigms (Java / XQuery)Mash: Leverage tools to increase efficiencyMash: NEXT SLIDE
- Mash: By using these techniques in fact what we are trying to do is create Well Crafted SoftwareSandro: Last but not least, another problem we had was the Us & Them Attitude (Prod Service, Business, Devs)
- Sandro: BAs are part of the teamMash: BA’s often pair with developersSandro: Writing code is just one of the responsibilities of a developer
- Mash: Closer to Prod ServicesMash: MOVE TO NEXT SLIDE
- Mash: Us & Them >> Productive partnershipSandro: Four biggest problems highlighted by Agile processes. Four key values of Software Craftsmanship. Agile vs Craftsmanship. Mash: We are not trying to say that all is perfect!Sandro: We still suck in many areas. At least we know our problems. We are still on a journey.
- Agile doesn’t workWe have asked ourselves the same question