#msdevcon Community Track IMPLEMENTATION OF SCRUM Bernardin Katić Insa Investment Software AG

Putting it all together

Our Scrum project Development/Implementation of our product Product in enterprise LOB solution for banks Scrum (in our way) implemented for the last 5 year internally. Clients use „classical” project management Our client base is in Switzerland/Germany/Italy/Singapore/Panama/Croatia 2 Teams Dev team in Croatia, Sales/Implementation in Switzerland and Singapore 60 customers+ several new every year 4

Scrum framework Roles Ceremonies Artifacts Sprint planning Sprint review Sprint retrospective Daily scrum meeting Product backlog Sprint backlog Burndown charts Product owner ScrumMaster Team

Scrum Roles 6

Product Owner Define features of product Decide Release Date and content Responsible for profitability (ROI) Prioritize features according to market value Adjusts features and its priorities in every iteration Accept or reject work item result One person On vendor side

Product Owner Account Manager(s) Contact (filter) to clients Responsible for correct and comprehensive specification and real priorities of change/feature requests Talks to clients BUT always thinks of his team DOES NOT decide alone about which features go into backlog Change Board (App Architect/Key Account Manager/Sales) takes responsibility and decides

The Scrum Master Represents Project Management * Enacting Scrum values Ensure team’s productivity Shield team from external interferences Corporate across all roles

The Scrum Master 2 scrum teams– 1 scrum master Proxy between 2 teams (development & implementation) Responsible for cooperation between two teams Shield DEV team from external interferences (clients or other team)

The team 5-9 members Cross-functional: Programmers, testers, user experience. Full time Work Self-organizing Membership could be changed only between sprints

The team(s) 2 Scrum teams Dev team, 6 members, 4 developers, 1 UX, 1 Tester Implementation team, 6 members, 4 Account Managers, 1 Support, 1 Sales Very seldom self-organizing… Taking tasking „out of profile” very welcome but mostly not possible

Scrum framework Roles Ceremonies Artifacts Sprint planning Sprint review Sprint retrospective Daily scrum meeting Product backlog Sprint backlog Burndown charts Product owner ScrumMaster Team

Daily ScrumSprint PlanningSprint Review Sprint Retrospective Scrum Events

The Sprint 30 days or less Reduces risks Creates focus Enables realistic planning

The Daily Scrum Parametars Daily 15-minutes Stand-up Not for problem solving Everyone is invited Only team members Scrum Master, product owner can talk Avoiding other unnecessary meetings

Not status report for Scrum Master! 3 questions What did I accomplish yesterday? What will I do today? What obstacles are impeeding my progress?

The Daily Scrum(s) 2 stand-up meetings, 15 min (max) each, always same time 1st with Implementation Team (Skype – geo-spead team) 2nd with Dev Team (coffee table meeting) Only Scrum Master on both Communication channel between two teams

Sprint retrospective Periodically take a look at what is and is not working Typically 15–30 minutes Done after every sprint Whole team participates Scrum Master Product owner Team Possibly customers and others

Sprint retrospective Bi-weekly Internal, only Dev Team/Account Manager Clients NOT INVITED Review of priorities for the next sprint

The Sprint review Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal 2-hour prep time rule No slides Whole team participates Invite the world

The Sprint review Monthly For specific customer projects Client is invited Meeting/Demo at clients office Feedback from client

Release review Quarterly Announcement to all clients on Yammer/newsletter All clients invited Webcast demo of new features Feedback from clients and implementation/sales/support team

Focus Group Yearly Announcement to all clients on Yammer/newsletter All clients invited Organized as held-day workshop (2 hours+ lunch/networking) No more than 15 clients in group Live demo of all new features in the last year Share demo of planned features and further development Proposals & Ideas from clients for the further development Voting, Offline - post-it notes!

Scrum framework Roles Ceremonies Artifacts Sprint planning Sprint review Sprint retrospective Daily scrum meeting Product backlog Sprint backlog Burndown charts Product owner Scrum Master Team

Product backlog The requirements A list of all desired work on the project Ideally expressed such that each item has value to the users or customers of the product Prioritized by the product owner Reprioritized at the start of each sprint

Managing the sprint backlog Individuals sign up for work of their own choosing Work is never assigned Estimated work remaining is updated daily Any team member can add, delete or change the sprint backlog Work for the sprint emerges If work is unclear, define a sprint backlog item with a larger amount of time and break it down later Update work remaining as more becomes known

50% Strategic Development 30% Feature Requests 20% Incidents/Support Backlog Structure

Change Requests Accept only controlled changes Avoid out of scope changes Accept changes – unfortunately this is reality Change requests/Feature Requests Change Control Board Decision about change request(approve, reject, defer) Influence to other customers Code stability analysis Complexity of implementation Business value of the request

Scrum Release Management Quarterly Q1, Q2, Q3, Q4 release 6 bi-weekly sprints make one public release Development and Releases versions in parallel All new development in Development track After every sprint Development App version (but internal daily build) Release version fully tested before publishing No new features in Release version Only critical bugs are corrected within Release version Feature set defined for the next release before development starts Feature set defined by change management board Feature set and delivery date announced to clients

DEV Q1.100 Branching

DEV Q1.108 Q2.1 Q2.100 RELEASE Branching

DEV Q1.108 Q2.1 Q2.100 RELEASE Branching

DEV Q3.100 Q1.108 Q2.1 Q2.110 Q3.1 RELEASE Branching

DEV Q3.100 Q1.108 Q2.1 Q2.110 Q3.1 RELEASE Branching

DEV Q3.100 Q1.108 Q2.1 Q2.110 Q3.1 Q2.6 – Patch Q2.17 RELEASE PATCH Branching

DEVELOPERTESTER1 ST LEVEL ACCOUNT MANAGER CUSTOMER 5 STEPS TESTING FRAMEWORK Quality Assurance

#msdevcon Community Track Questions & Discussion Bernardin Katić

© 2016 Microsoft Corporation. All rights reserved.