We are changing the organization of work in MCA

Lessons Learned

Author: Michal Šimoník

   Over the past year, our largest customers (ČS and ČSOB) started to use the word agility more and more often. First, new terminology appeared, followed later by considerations of requiring agile from suppliers. At the same time, our delivery requirements were changing - the complexity and intricacy of the requirements within Release increased manifold, which broke our ability to deliver the way we were used to. Not just to deliver efficiently, but to deliver on time and to quality in general.

What was the problem?

   When I jumped into the role of a project manager on the MEP project at Česká spořitelna, I had a lot of tools like WBS, Confluence, JIRA, MINDA, ..., which were supposed to facilitate project management. In addition to that, we had countless meetings that were often unproductive and ineffective, for a number of reasons - participants were not fully focused (open laptops and dealing with other things), unclear meeting objective, dealing with technical details in the project meeting, etc. The volume of deliverables was significant and having a detailed overview of the details of each component was almost impossible. The old Release was not even over yet and the new one was already in full swing. Add to that production bugs and the preparation of more complicated topics with a longer term perspective. All of this contributed to frustration, deterioration of the team's mood and sometimes even conflicts.

   We were looking for a way out of this merry-go-round. The company management invited an experienced consultant (Mr. Michal Vallo from Aguarra), under whose guidance we received initial training. This showed us, among other things, where we might have problems and how to start thinking about them. Mr Vallo, with an unbiased outside perspective, produced a report that summarised our situation. It was not a pretty read - it confirmed my real experience that the current project management system is opaque and inefficient. But it also pointed to possible areas for improvement, guided us on how to think about changes and a possible way to improve this situation.

The important point was to BEGIN!

   In cooperation with our consultant, we started to design and implement changes. We wanted to visualize the activities to see how the problems arise, to get more time to work and to remove unnecessary activities.

   We have started to divide the work into two-week SPRINTs, which suits us so far. SPRINT itself is divided into 2 parts: in the first part (1 week) the development team tries to to devote as much time as possible to the development of the business requirements themselves, so that at the end of this part of the SPRINT the Service Pack can be released. In the second part, the development team tries to clear development defects and at the same time works on other activities (comments, DFD/HFD acceptance, creation of technical designs (PBI) and preparations for the next SPRINT). The Service team in the first part of the SPRINT is devoted to the preparation of test scenarios, DFD/HFD revisions and in the second part of the SPRINT to testing the development package, so that at the end of the SPRINT the customer gets a fully tested and 100% functional delivery.

   Each SPRINT is always preceded by analytical preparation, so unprepared TASKs cannot enter SPRINTs. We have redefined the whole process and identified critical points in it, for which we have prepared checklists, similar to the ones pilots have in an airplane. We call them Definition of Ready and Definition of Done, and they determine what can be taken over, turned in, and when. There are also roles associated with this - i.e. who is responsible for what.

   Another change was the designation of JIRA as the "single point of truth" where we now track the status of individual TASKs and their progress. According to the knowledge and experience we have gained, we have modified WORKFLOW for both EPICs and TASKs, BUGs, and so it is possible to look into JIRA to see what stage each requirement is at, who is currently working on what, and whether we are on track. We have completely abandoned parallel WBS and priority systems.

   The morning StandUPs of the individual streams are proving to be very handy, where we just briefly recap what has been completed and what is still in the pipeline. With just 10 - 15 min, a glance at the JIRA and each team member is clear on what is expected of them.

   Within SPRINT we have established rituals - Sprint Planning (at the beginning) and Retrospective (at the end). Each was set for two hours. Initially, we were not able to fit into this time frame, but we're currently finishing before that time is up.

   Sprint, Sprint Planning, Retrospective, all of these are moving us forward in clearing requests. The team is able to estimate the timing of individual TASKs much better, in many cases we are able to complete what is planned within the SPRINT (sometimes there are exceptions :-) ); we can clearly see who is working on what and the status of individual requirements, and with this comes the ability to respond to issues in a timely manner if they arise during the SPRINT.

   Although it doesn't seem like it at first glance, we have already done a significant amount of work and the progress in a positive direction is considerable. We are trying to make the synergy of 5 teams from multiple locations as efficient as possible, plus adding the customer to the mix.

   We're still not done with the changes. We haven't yet blazed all the trails, we haven't gotten around to implementing agile management, and we haven't yet managed to completely free ourselves mentally from delivering "mandays" and presenting added value to customers. It turns out that it's not enough to change the process, we also need to change the way we think about work, change the activities and the approach. The number of meetings has remained at a minimum, the number of open issues in retrospectives is down, we have visibility of who is doing what, who is waiting for whom and where help is needed. People's approach to work is changing, the predictability of delivery and the quality of delivery is much better. And we are currently trying to help introduce "best practices" into the CSOB project. Our target is to deliver all projects in this way. As we have verified in real life, the newly deployed working methods do not need to be modified in any major way even for the home-office- coronavirus working mode.

   In total, it took us 6 months to implement and settle these changes. We still have many ideas for further improvements. In the future, we would like to implement full-fledged agile management and allow other company departments to be inspired by our practices, which together can then help us to further improve our work efficiency and value creation.

   We decided to share our experience, and maybe even boast a little. And so we wrote this article. We've come a long way. But there's more to come. Looking back, there is a huge amount of work to be done in conjunction with our agile transformation. And we are proud of that. We've done the work.

This article was originally published in company internal magazine in April 2020.