Scrum & Agile Practices

current practices in our project

Transcript

1. Scrum & Agile Practices in Simocrane Unrestricted
2. Sprint Review & Sprint Planning • 3 week sprint are planned • Review meeting in Thursday morning • Retrospective meeting in Thursday afternoon • Planning meeting in Friday morning • DSU are in 9:30 Germany Time • 15 minutes Daily Scrum • 15 minutes Question & Remark section
3. Pre-Grooming (PB refinement meeting) • Second Monday in Sprint • All Scrum Team join • Agenda • Discuss current user stories • Discuss new complexities with PO • Negotiate current scope if team see any risk • Groom new user stories
4. Sprint Retrospective • Conceptboard is used for Sprint Retro • Provide real time collaboration on digital whiteboard • Different templates can be used
5. Technical Debt Management • Technical debts are accumulated in common place. • If developer found new technical debt, the new debt is inserted to the list. • Technical debts are regularly checked by developers and giving estimation and priority. Big technical debts are cut to smaller pieces. • If technical debts contains user experience change or feature change, technical debt should be negotiated with Product owner. • Regarding to estimation and complexity, developers can fix the debts.
6. Improvement Ideas • We are collecting improvement ideas in collaborative workplace. • If any new improvement idea is found by developer, the new idea is added to these list. • These improvement ideas are presented to Product Owner or Product Owner can check also these ideas
7. Planning Poker • Estimation for Product Backlog • All Team members estimate the PBI • who gave the high and low estimate justify their reasoning • Fibonnacci Series are used for estimation. • https://pokrex.com/rooms/simocrane- cms
8. Retrospective • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly • Key practice for Inspect & Adapt • Continuos Improvement \ Kaizen
9. Futurespective • Retrospective for Future • A futurespective is an agile retrospective where you start from the goal to find ways how to get there.
10. Coding Standards • No big Coding Standard Documentation (Anyone Read/Remember ?) • Automated tools (ReSharper, SonarQube) • Do Code Review • Add important items to Code Review checklist
11. Code Review - Pull Request • No new code is checked-in to master without code review • Two developer review the code via Pull Request tool. • After Code Reviewers approve the code or review/fix cycle is done, code is checked into master branch.
12. Pair Programming • Critical code or production bug fixes • Better diffusion and know-how transfer between new colleagues or junior developers. • Define common coding standards
13. Definition of Ready Meeting • Dev. team seat together talks about ready Product backlog items. • Meeting is more suitable for technical discussion/architectural issues • Purpose getting same understanding for current ready product items.
14. Overview of the week • 15-30 minutes meeting every Monday • Dev team members join • Discuss the week which starts. • Possible impediments & bottlenecks • At the end of the week where will be the best • Set Weekly Target
15. Feedback culture • Face-to-face feedback is always good but culture change is hard. • Feedback surveys are created by volunteer developer every 6 month • Feedback surveys are filled by anonymously. • Feedback result & comments are sent to person & SM.
16. Kanban Board \ Scrum Board • Visual Board, All tasks are visible to Team • Encourage collaboration & conversation • One dev team member update the board everyday. (More Interactive and Fun) • In Scrum, Dev Team update the board in Daily Scrum meeting • Dev Team can calculate Velocity \ BurnDown chart and other metrics
17. Burn Down chart / Velocity • Burn down chart is used for show the remaining effort in Sprint and show the current speed of team. • Burn down chart good information radiators for the dev team ! • Velocity shows the yesterday weathers.
18. Visualization • One physical board is available for team discussions. • Retrospective action items are written to the board. • Weekly targets are written • Information which needs to disturb people
19. Daily Standup Meeting • One dev. Team member update the online board • Every team member give stick to each other. • DSU Meeting is 15 minutes Daily Scrum & 15 minutes Question & Remarks section. • In Question and Remark section, if any team member want to ask any question than who the target person.
20. Continous Integration (Jenkins) • Every check-in to master, trigger new job in Jenkins • These Job does • Compile • Execute unit test (nunit) • Unit Test Coverage (dotcover) • Run static code analysis (sonarqube) • Build setup project (create setup file) • Run automated test (install binaries)
21. Continous Delivery • is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. • Release Candidate job creates delivery folder for customer or system test • Setup files • User manual / ReadMe files • Example application files/ Images • Updates • Source code
22. Continuous Delivery & Deployment
23. SonarQube • Every CI job update Sonar DB • Sonar Code Smells & Bug evaluated continuously • No new code smell is added with new check-in
24. Minimum Viable Product (MVP)
25. Collective Code Ownership • Encourages everyone to contribute new ideas to all segments of the project. • Faster code development, prevent possible bottlenecks • Reduces the risk that the absence (or unavailability) • Is a favorable factor in the diffusion of technical knowledge • Encourages each developer to feel responsible for the quality of the whole • One technical perspective like "Conway's Law"
26. Test Automation • End-to-End test scripts are written by Dev Team. • Test automation scripts are executed every nightly build.
27. Technical Backlog Items • Defining technical backlog items are not beneficial in PBI • Giving %10-%20 time in Sprint • We have additional Off-Sprint Backlog list. We collect technical items and prioritized these items.
28. For Future
29. Slack Time • Every sprint change, give some extra time for developers for own research or development for products • These research areas can be • New components/libraries which will increases the productivity • Technical debts • CI/CD improvements, Server upgrades etc. • New technologies which will be beneficial for product.
30. Demo Date • PO is not available always for getting feedback • When US is done, getting feedback from PO immediately always best. • If PO is busy person, settle demo date before 1-3 days ago • Collect feedbacks from PO, in next days complete
31. Mob Programming • All team working • at the same time • in the same space • at the same computer • on the same thing • 5 to 15 minutes rotates • Driver : writes the code & not think & listen navigator • Navigator : Tells the driver what to do. • Pair Programming + Code Review + Standup
32. Mob Programming • Mob Success • Critical code to create • Production code to fix • Complex problems to analyze/solve • Big refactoring sessions • Mob Failures • Repetitive Tasks • Boring Tasks • Long Tests Run
33. Acceptance Test Driven Development • Acceptance Test is an executable specification of system behaviour. • ATDD aims to encourage collaboration among the user, developer, and tester to ensure that acceptance tests exist before writing any code.
34. VS Live Share • For home office only, enables pair programming with remote colleagues