Curing Agile Hangover: Sandro Mancuso and Mashooq Badar

  • 672 views
Uploaded on

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 …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
672
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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

Transcript

  • 1. Curing the Agile Hangover with Software Craftsmanship
  • 2. BACKGROUND
  • 3. Waterfall ProcessRequirements Dev Test Release
  • 4. Teams Divided By Roles ProjectManagers Developers Testers/ Analysts
  • 5. Component TeamsDev Team 1 Dev Team 2 Dev Team 3 Component 1 Component 2 Component 3
  • 6. AGILE ADOPTION
  • 7. Scrum Teams Scrum DevelopersProduct MasterOwner QA BA Component 3 Component 2 Component 1
  • 8. The Hangover Lack of Technical Expertise S tagnant S kill-set Long running buildsLate discovery of Bugs Low Moral Unstable S ystem Requirements not well understood Inefficient Develop, Debug, Deploy CyclesUnreliable and Costly Tests Mountain of Technical Debt
  • 9. The Off-Shore Effect
  • 10. Low Moral Poor ROI The HangoverLow 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 ROIProfessionals The Hangover Low Quality Us and Them Software Attitude
  • 16. Poor ROIFocus 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 ROIQuality 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 ROIContinuous 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 ValueProfessionals 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 smellsLow 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 MetricsLow 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 efficiencyLow Quality Software
  • 23. Community of Steadily Add ValueProfessionals The HangoverWell 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 AddProfessionals Value Software CraftsmanshipWell Crafted Productive Software Partnership
  • 27. ThanksSandro Mancuso Mashooq Badarsandro.mancuso@ubs.com mashooq.badar@ubs.com@sandromancuso @mashooq