Amazing journey with my last big project

With this post I try to describe how I was asked to manage a vital project within the organization, which proved to be the last project old-style. I wish to bring across how the organization changed meanwhile and how this influenced me, for example how it changed my view on #NoEstimates.

I spent most of my working career within software development. Later on the company I worked for then requested me to lead initiatives on the infrastructure side of ICT, but I missed the functional side and software development specifically more and more.

Then came the opportunity to join a company working in a rapidly growing, fast-paced, highly volatile environment (online payment industry). It really was appealing for me as I saw many chances to use my interests and strengths. In the end it took the company two years to get where I could actually put them to good use.

When I started to work here I thought that the company used Scrum ‘by the book’ and they had taken huge steps towards an Agile form of software development. I soon came to realize that this wasn’t the case.

Imagine a company where the following is in place:

• Rigid form of project governance, including toll gates (initiation, design, development, internal test, external test, deploy, close). You can only move to the next phase after passing the toll gate of the previous phase.
• Toll gate meetings once every two weeks, basically meaning that when you finished a stage you needed to wait up to two weeks before you could proceed.

• Many mandatory documents, for example 2 requirement documents, 2 architecture documents, design document, test-plan, test execution report, project closure document, toll gate sign-off documents. Many of them overlap in content.
• Hard hand offs. One document had to wait for the other to finish.
• No budget for next phase before toll gate signoff
• Exceptions were there, but discouraged
• Scrum teams working Scrumfall, which meant we had analysis sprint, design sprint, development sprint, QA sprint

• Business, development and operations literally sitting in different buildings
• Scrum teams without a product owner. Yes, read this again! There were Business Analysts, but they were located in another building and didn’t have a similar role as the PO would have.

I had to start my last project with the above in place. Essentially the project was the companies’ own Y2K problem. We needed to increase the possible values of a crucial field to allow future growth. A field that touched many parts of the software environment. It was a massive exercise. The expected software development work on this was calculated to be 1500 MAN-DAYS. Testing about the same! And then we had to do work on operations side and deployment as well. It was an uphill battle from the start.

When I got the assignment some colleagues felt bad for me. The project was tried before and abandoned. It was seen as a certain failure from the start. This had to do with the magnitude of the project, but also with the track record of the previous years, where only a handful of projects finished successfully, no matter the size. This fact by the way sparked my interested in #NoEstimates. Essentially it didn’t matter what we planned, we wouldn’t finish most of it anyway. On top of that estimates/plans were often misused as ‘set in stone’. Imagine what this does to motivation. I saw the same pain tackled within #NoEstimates.

But as said: we needed to do it, we needed to bite the bullet.

Here comes a big thing: around the same time a new CTO joined the company. Someone that saw the situation at the time as deadly. He set us on a road towards -as he called it- Agility and this was my saving grace.

First thing that I proposed within my project, together with my software development colleagues, was to step away from a big bang approach. To step away from designing everything, then building it, then testing it and then deploying it all in one go. We saw this as virtually not doable and it would put the company at risk on top of that. Instead we suggested:

• Step one: Change small portions of software piece by piece to have it prepared for the new format (but still also able to work with the old format) and deploy them early, piece by piece
• Step two: switch to the new format when all application changes are deployed

This was a big departure from the existing way of doing projects. We were going to deploy software to production constantly.

Technically the company was already able to deploy fast, which was effectively used to resolve incidents and problems. And also to deploy updates on existing products. The issue was first and foremost with the project governance. My approach couldn’t fit in the project toll-gate structure anymore. As a result PMO needed to change the project governance to allow iterations going to production. This wouldn’t be allowed without the CTO enforcing practical solutions.

Meanwhile the CTO had initiated an organizational change, with basically entailed that we would now have a Product Owners. Finally. Furthermore the teams were resized and Scrum was re-introduced, now properly. It certainly materialized, especially with the teams able to work independently on their initiatives.

The project made use of four Scrum Teams working on several parts of the software and also vendors of the external software.

Two practices I introduced to manage the project were to create a Scrum of Scrums board and to organize a 15 minute Scrum of Scrums to have a daily alignment between teams, the product owner, myself and other stakeholders.

The first Scrum of Scrum within the organization. It proved to be a vital 15 minutes per day, because a lot of issues were identified and resolved by just updating each other there and there. It often went like this:

John, Representative team FO: we identified a potential issue with acquirer X. They may not be able to handle our solution.

Product Owner: Thanks for the info. I will investigate this topic by reading through their guidelines and if needed contacting them.

Me: OK, I will create a sticky for the board that the PO is doing an assessment on feasibility of the solution for Acquirer X. It will remain tracked until closed.

After some days: PO: I found out you are right John. They can’t handle the solution. What to do?

Me: Let’s sit together with some SME’s and stakeholders to find a solution to the issue. The sticky for the assessment can be closed, I will create a new sticky to discuss alternatives for this issue.

etc…

This is how we moved on, sticky after sticky, day after day, month after month. We moved on steadily and were able to show progress on a daily basis. We implemented small pieces of changed software and this had barely any impact on the platform.

Sadly this didn’t work everywhere. We also had to tackle a major obstacle, which had to do with a legacy environment that didn’t allow us to deploy in small pieces. This forced us to add many additional months to the schedule. It also came with major issues and headaches. It in the end only showcased even more how superior the incremental deployment was. Needless to say that this legacy environment will get a major overhaul to prevent big bangs in the future.

The organizational change was a success and we saw the productivity grow. This lead to a next step, which was an even bigger leap to our form of Agile delivery. This meant:

• the removal of the existing/traditional project governance
• ending certain so-called mandatory documentation and handover moments.
• completely move to story prioritization with a backlog
• self-managing teams –now called tribes
• organizational management style from directive to more assisting role
• encouragement to identify and tackle any impediment to improve
• framework was still Scrum, but stepping away from Scrum-fall towards delivering stories that entailed a certain value for the business

This is a major change and it took a lot of blood, sweat and tears to set in motion and also to incorporate into the organization. We are not done yet, but I already see many things going into the right direction.

Bear in mind that we still have to justify what we are working on and how we do this work. We are a financial company and we have to comply to a number of vital rules to be allowed to do what we do. But this is not the same as having a rigid process and way to many documents.

Also we have an infinite amount of potential initiatives to pick up, so we always need to prioritize. This requires us to assess the potential value, which includes estimating the cost vs potential income it will generate (or other non-financial benefits). Therefore we have around 10 initiatives on the road-map at any time, to be picked up by the tribes.

This whole transition took place while I was managing my mega-project. I was ahead of the rest of the projects with my Agile practices, but the company caught up and went beyond. Now comes the moment to close the last project within the organization. Project old style that is.

Simultaneously with this journey at the company, working on a massive project in a changing environment, I started to realize where one should seek for a solution to estimating misuse. This misuse is simply a symptom, as is apathetic staff or structural overwork. The source of this all is often an organization that doesn’t allow you to function as a professional. Fix that and you also fix the symptoms. I am not saying this is easy, but I have been fortunate enough to work in an environment where exactly this happened.

Originally published at ageling.wordpress.com on September 19, 2017.