A personal and sympathetic view of taking a traditional AS\/400 development team to an Agile POD using a fully automated CI\/CT\/CD DevOps pipeline with Agile methodology on the IBM i.<\/p>\n
My 9 step journey as Global Head of DevOps Tooling and Engineering Services at HSBC helping to transition an \u2018AS\/400 development team\u2019 into an Agile IBM i Pod with fully automated CI\/CT\/CD DevOps pipeline.<\/p>\n<\/div>
It was never going to be easy to convince veteran developers of the need to make a quantum change to become a modern Agile Pod after decades of tradition. Developers who still preferred to use the term \u2018AS\/400\u2019 in passive protest against those demon marketeers who dropped the original name of the IBM i over twenty years ago were not exactly easily swayed by fashion. A wall of resistance initially came my way when I first introduced the idea of an Agile Pod. Their arguments sounded logical, rational, considered, fervent, convincing and at the same time\u2026 wrong. My gargantuan task was to steadily convince a global team of 1500 traditional developers to abandon these preconceptions and make the DevOps leap. Yet I know many who have come across these same objections in traditional teams of all sizes. Here are just some of the doubts we faced on our IBM i DevOps journey (do any of these sound familiar?):<\/p>\n
My challenge was to widen perspectives and turn these arguments on their head\u2026<\/p>\n
Every argument these veteran developers made seemed sensible, yet there was something in the back of my mind which made me think that a graphical development tool like Rational Developer for i (RDi) might be able to bring something more to this table. There had to be a way to make it add value to these veteran developers’ lives as they launched their many custom macros carefully crafted over the years.<\/p>\n
Why were they starting RDi multiple times a day? I noticed that the development team manager didn\u2019t spend all day programming so they would pop in and out of the task doing a bit of development here and there. This was where all the slow startup noise was coming from.<\/p>\n
My thinking was that if we could increase the productivity of the developers then surely their manager wouldn\u2019t need to keep popping in and out of a development tool. This would eliminate the need for them to act as a part-time developer and give them more time to manage the team.<\/p>\n
I noticed the developers spent all day at their desks writing specifications, coding, setting up test environments, testing, drinking coffee and writing documentation. Hence, they would only need to start RDi up once a day. There must be a way I thought to get them to see the productivity benefits of a graphical development tool with its color, its formatting, and its improved access to systems. Even if most programming was still fixed format RPG the benefits of a graphical development tool should simplify and accelerate their coding. They would still have to switch to green screen to do their tests and environment setups but since RDi would be open all day, developers would not be exposed to slow startup times compared to green screen except once per day.<\/p>\n
My plan was to make a start and get RDi installed on all the developer laptops so that some would at least try it out. Additionally we took some time to deliver a couple of quick RDi training sessions, just to cover the basics to see if we could wow them.<\/p>\n
Initially there was an assumption that daily meetings, however short, were a waste of time because these veterans already knew what to do. There was also a high level of mistrust initially about introducing new reporting tools like Jira, a false assumption that there was a bad faith motive behind it.<\/p>\n
I persisted. In the first few weeks the daily scrums (short morning meetings with all team members to discuss priorities for the day ahead) might not have been everything that the DevOps books had said they should be, but it was a start. The intended 15 minutes, initially was 20 minutes but after a short time the scrums became shorter and more productive. Gradually team members became more comfortable with the concept of sprints (short time-boxed periods where the scrum team works to complete a set amount of work). Eventually every team member started to feel more involved in the sprint goals (two sentence descriptions of what the team plans to achieve during this sprint).<\/p>\n
As trust increased we introduced Jira which allowed us to track \u2018issues\u2019 (a generic Jira term for a piece of work such as a project task or helpdesk ticket) in an automated way. This helped us find improvements in the way we would close off work. We could actually see who was working on what, and that made conflicts easier to resolve. We also found an opportunity to stop any blockers (anything which slowed us down) taking hold and bringing the development stream to a halt. The performance of the team was improving as the pathway to completion became a little less obstructed and little more coordinated.<\/p>\n
The team unit became stronger and we had more time for input from the end users. Some of the team still couldn\u2019t refer to them as \u2018customers\u2019 yet, just too \u2018trendy\u2019. As a result of that input however, we were able to start prioritizing changes which delivered the most business benefit and we focused on delivering smaller enhancements faster.<\/p>\n
We could now monitor the workload better, our estimating had improved, and in turn that allowed us to deliver more of what we promised and more of it was on time.<\/p>\n