uCOIN, the first value stream

As a key data source, uCOIN holds many opportunities for the future. With the agile setup as a value stream, uCOIN is able to deliver internal sustainable product development of our central customer database.

What is uCOIN all about and how did it come to be a value stream?

uCOIN is the group-wide central (corporate) customer database, serving as a “golden source of truth”. uCOIN stands for unique counterparty identification number and this enables us to know which clients form a group of clients.This is a regulatory requirement and serves other applications (GDP, RICOS and the various Local Customer Systems). With it we establish overall risk exposure per client and find ways how to further serve our clients’ needs. uCOIN gets many development requests from dependent applications and projects. Our agile setup helps us to deliver and optimize the value of uCOIN as an ‘internal product’.

How did you set up the agile team?

The team uses Scrum* and consists of colleagues from Business and IT. Business is the application owner and as such nominated the Product Owner1. The Development Team2 and Scrum Master3 are staffed from EGIT and almost all are internal colleagues. A big success is that everyone in the team is assigned for 100% to uCOIN. For the development this is split to 80% CtB and 20% RtB.

How does uCOIN benefit from the agile setup?

First of all it was great to see that everyone – independent from which entity - was committed and successfully learned the new approach.Of course we believed that Scrum made sense for uCOIN, but as it is a pilot you can never be sure and are bound to run into extra difficulties and hurdles. During the retrospectives – the regular event to inspect how we work - it became clear for the team that it did make sense.Several benefits surfaced and several “agile myths” got busted.

Benefits listed include:

  • The granular break-down helps to not forget anything.
  • High commitment from the team.
  • Write SDS and Jira stories at the same time to be more efficient and reduce waste.
  • Start to build up cross-functional (T-shaped) profile(s), especially in testing.
  • High flexibility and high delivery of business requirements.
  • Focus on “what the client needs”, constructive challenging between business and developers increase understanding and helps to move beyond ‘huge’ initial requirements.

Busted myths:

  • Myth:no documentation - Our release notes are audit compliant. We specifically focus on value added documentation and are thankful of our colleagues in PM Governance that they do not expect copy pasting to special documents. They have a link to our internal Confluence (a.k.a. ‘wiki’) where all the key information is kept up to date. This includes our Definition of Done, Definition of Ready, and Architecture, but also our Knowledge base and guidelines on for instance onboarding of new colleagues.
  • Myth: no testing – We use Jira to track that all work is tested (SDS, test cases and commits).
  • Myth: no plan – we start each Sprint with a detailed plan (every two weeks) and the backlog holds planned and prioritized requirements / user stories for another 2 to 3 Sprints. We plan based on our capacity and average velocity (measured based on experience/learnings). Until now we managed to keep our plans for CtB development, even though RtB has priority. 

What kind of difficulties have you been facing within uCOIN?

  • It is hard to overcome patterns from the past – e.g.
    • Use events as they are intended, for instance, it needs continuous attention to keep the daily stand up focused on coordination removing blockers, not focused on ‘status updates’.
    • “Develop as requested”, it is important to stay alert and keep on asking questions like “and what value does this add?
    • ”Risk of ‘waterfall in Jira’ - while writing our Jira tickets, we must take care to keep an E2E perspective on user stories and not to revert to first the ‘development story’, then the ‘FAT story’, followed by the ‘UAT story’, etc.. Nevertheless it is essential to stay aligned with context projects, that follow the traditional way (e.g. integrated testing).
  • A positive myth in both Agile as well as Waterfall is that teams always perform better. This only holds true with continuous attention to improvement. Otherwise patterns set, even if the performance of a team could be improved further. Agile supports this through retrospectives and having a scrum master, but only if the events and practices are upheld.
  • We are also requested to fulfill requirements from other projects – with different objectives and budgets. Prioritization and focus is kept well through Backlog and Product owner, so we don’t have the ‘traditional disruption problem’.  We did however, have to find a way to match the different budgeting methods of value-stream against the traditional project budgeting; fixed budget with variable scope versus fixed scope with estimated budget.

Below some of our top tips:

  • Make sure, that everyone in the team knows the Agile principles. The entire team should hear the same message. In Erste Group we are lucky to have several top-experts teaching Agile-methodology. Use them!
  • Let the team adopt the Agile techniques continuously and be demand-oriented. Don´t be dogmatic about following the Agile Manifesto!
  • You will learn to fail. The Agile methodology enables failing fast by showing continuously the business progress. The whole Agile process is about trying, failing and adopting.
  • Try to locate the team in ONE place – to encourage face-to-face communication! Permanent Lync-sessions can get tough!
  • You will more easily overcome the boundaries between business and IT. There is real team work regardless to which specific EG-entity you belong.