Scrum & Agile Practices in Simocrane Unrestricted 

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 

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 

Sprint Retrospective • Conceptboard is used for Sprint Retro • Provide real time collaboration on digital whiteboard • Different templates can be used 

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. 

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 

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 

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 

Futurespective • Retrospective for Future • A futurespective is an agile retrospective where you start from the goal to find ways how to get there. 

Coding Standards • No big Coding Standard Documentation (Anyone Read/Remember ?) • Automated tools (ReSharper, SonarQube) • Do Code Review • Add important items to Code Review checklist 

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. 

Pair Programming • Critical code or production bug fixes • Better diffusion and know-how transfer between new colleagues or junior developers. • Define common coding standards 

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. 

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 

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. 

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 

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. 

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 

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. 

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) 

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 

Continuous Delivery & Deployment 

SonarQube • Every CI job update Sonar DB • Sonar Code Smells & Bug evaluated continuously • No new code smell is added with new check-in 

Minimum Viable Product (MVP) 

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" 

Test Automation • End-to-End test scripts are written by Dev Team. • Test automation scripts are executed every nightly build. 

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. 

For Future 

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. 

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 

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 

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 

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. 

VS Live Share • For home office only, enables pair programming with remote colleagues