Scrum Indonesian Banks

This presentation is the work of Joshua Partogi of @ScrumWayAsia. Please kindly mention the original source when you are citing from this slide.

Using Scrum in Indonesian Banks Workshop

Joshua Partogihttp://www.scrumway.asia @ScrumWayAsia


Who Am I?

• I am a Scrum expert from Indonesia and the only Professional Scrum Trainer through Scrum.org based in Asia to date

• Scrum.org is the home of Scrum. We host the Scrum Guide - Scrum Body of Knowledge - in 30 languages and provide assessments to allow people to evaluate themselves and improve.

• I translated Scrum Guide to Bahasa Indonesia

• I have successfully helped many Indonesian companies transition to Scrum

• So you can say that I am a reliable source anything related with Scrum


Today we are going to discuss how to implement

Scrum in Banking environment in Indonesia


Compliance

• In implementing Information Technology in Bank, Indonesian Banks must comply with:

• Surat Edaran Bank Indonesia Nomor: 9/30/DPNP Tanggal 12 Desember 2007

• Peraturan Bank Indonesia Nomor: 9/15/PBI/2007


Misconception (1): These two regulations is Waterfallaholic


The truth...

• Waterfall is one of System Development Life Cycle

• Agile is another

• But Bank of Indonesia never specifically mentioned that you have to use Waterfall

• At first sight the processes may seems like Waterfall

• SEBI Nomor: 9/30/DPNP point 2.4.2 specifically mentioned that you can use Agile software development

• Scrum is one of Agile flavour


So we have solved one problem...


Mapping Scrum to SE BI

• Remember that Scrum is just a framework and we are responsible to fill in the missing pieces

• Scrum context is in Product Development, which means we can plug in any other processes in SE BI that is not related with Product Development

• SE BI never said that you have to do the processes sequentially, but you have to do all of the processes

• We will do all of the processes in SE BI but not sequentially


Analyze Design Code Test Release

Plan

Analyze

Design

Code

Test

Release

Review

Plan

Analyze

Design

Code

Test

Release

Review

Plan

Analyze

Design

Code

Test

Release

Review

Plan

Analyze

Design

Code

Test

Release

Review

Plan

Analyze

Design

Code

Test

Release

Review

This is 1 SprintYou don’t have to release every Sprint, but you can if you are confident with your code integrity


Risk Management

• SE BI talks about Risk Management over and over again.

• Scrum will make risks in your banking projects painfully visible throughout the project for you to manage (not only before the project).

• These risks are exposed so you can make hard decisions based on it.

• And everyone needs to be proactively involved to manage these risks when it comes right to the surface.


Misconception (2): This Scrum thing seems to have little planning, how can I get the big picture?


Plan

Analyze

Design

Code

Test

Release

ReviewRelease Planning

•Feasibility Study•Project Ini>a>on•Project Charter

•Release/ Implementa>on

•Post Implementa>on •Maintentance•Disposal

Scrum prefers emerging architecture. The output of this meeting is the Product Backlog or the Release Backlog.

Plan

Analyze

Design

Code

Test

Release

Review

You can even have your own Scrum team for this


Planning

• Gather requirements and design architecture in detail only if you are smart enough to predict the whole future.

• The only way to predict the future is not to make detailed requirements but to inspect and adapt the outcome of your work.

• Detailed documentation doesn’t proof that you will get a good software.


Detail

Effort or Time

But details is sometimes expensive


So we have solved two problems...


Misconception (3): Product Backlog is the only documentation in Scrum


Documentations in SE BI

• Naming convention

• User Manual

• Application detailed description

• Inline coding documentation

• Business Requirement Document

• Functional Spec Documentation

• etc ...


Testings in SE BI

• Unit Testing

• System Integration Testing

• Stress Testing

• User Acceptance Test

• etc ...


Non Functional Requirements

• Data Backup

• Data Verification

• Data Retention

• Disaster Recovery

• Security

• etc...


We will not lower quality because that is not professional


So we have solved three problems...


That sounds great, but how can possibly do all that in one Sprint?

Shall we have 30 days Sprint?

Concerns


Focus on getting things “DONE”


Co-location lowers communication complexity and increases productivity.

Scrum expects high-bandwidth communication, full interaction and collaboration.


Scrum sounds great. But our developers need to be multitasking.

Scrum recommends developers not to be multitasking as it automatically lowers product quality and in the long run it can make developers less intelligent.

Other concerns


It’s your call now. Scrum will expose a lot of dysfunctions in your organization. It may be

painful along the way but it can make everyone joyful in the long run.


Contact us today for consulting work and let us help you!

[email protected]