![]() I noticed the developers spent all day at their desks writing specifications, coding, setting up test environments, testing, drinking coffee and writing documentation. This would eliminate the need for them to act as a part-time developer and give them more time to manage the team. ![]() My thinking was that if we could increase the productivity of the developers then surely their manager wouldn’t need to keep popping in and out of a development tool. This was where all the slow startup noise was coming from. Why were they starting RDi multiple times a day? I noticed that the development team manager didn’t spend all day programming so they would pop in and out of the task doing a bit of development here and there. 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. Move to a graphical development tool and show developers the benefitsĮvery 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. My challenge was to widen perspectives and turn these arguments on their head…Ģ. “Is there a way I could get my changes pushed back to Test after I commit them to Production?”.“So, we’re all going to have (the burden) of storing the full source code on each of our laptops”.“There’s nothing wrong with a SAVF (IBM i save file) for putting changes into production”.“Why can’t we just copy our changes to the test library?”.“You’re tracking our time trying to look for excuses to get rid of us”.“Why do we need daily meetings? We don’t have time for that”.“Once I have my green screen up it’s just a WRKMBRPDM command and bang, I’m back where I logged off yesterday”.I can’t be expected to start RDi multiple times a day” Here are just some of the doubts we faced on our IBM i DevOps journey (do any of these sound familiar?): Yet I know many who have come across these same objections in traditional teams of all sizes. My gargantuan task was to steadily convince a global team of 1500 traditional developers to abandon these preconceptions and make the DevOps leap. Their arguments sounded logical, rational, considered, fervent, convincing and at the same time… wrong. A wall of resistance initially came my way when I first introduced the idea of an Agile Pod. ![]() Developers who still preferred to use the term ‘AS/400’ 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. 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. Acknowledge the resistance and listen to the arguments We are always interested in hearing from skilled candidates who are looking for an exciting opportunity and who would like to be part of our dynamic team. Our success is down to the technical excellence and customer focus of our team.
0 Comments
Leave a Reply. |