{"id":14403,"date":"2021-01-14T11:14:02","date_gmt":"2021-01-14T10:14:02","guid":{"rendered":"https:\/\/acent.de\/?p=14403"},"modified":"2023-10-09T14:35:05","modified_gmt":"2023-10-09T12:35:05","slug":"the-future-role-of-the-cio-10","status":"publish","type":"post","link":"https:\/\/acent.de\/en\/the-future-role-of-the-cio-10\/","title":{"rendered":"The future role of the CIO"},"content":{"rendered":"

Agile has become one of the most misused buzzwords in recent years. Everything seems to become agile and everyone claims to be agile. Have you ever heard someone say, \u201cNo, we are not agile\u201d? But what do we actually mean when talking about agility?<\/p>\n

The Wikipedia article on agile software development defines agile practices as follows:<\/p>\n

\u201cIn software development, agile practices approach discovering requirements and developing solutions through the collaborative effort of self-organising and cross-functional teams and their customer(s)\/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change. It was popularised by the Manifesto for Agile Software Development. The values and principles espoused in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.\u201d<\/p>\n

The underlying principles of agile software development were already published in 2001 as part of the \u201cManifesto for Agile Software Development\u201d.
\nIt is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a \u201cbig bang\u201d launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to changes quickly. Short iterative cycles (sprints) and reducing overhead and bureaucracy to a minimum and therefore delivering small parts of usable code with a true business value very quickly, is the essence of agile.<\/p>\n

Speed is of the essence to be competitive in today\u2019s business environment and that\u2019s one of the main reasons why agile methods have become so popular. However, often agile is misunderstood by business managers and mostly seen purely as an \u201cIT thing\u201d. They often believe that with their IT teams adopting agile methods, projects are simply delivered faster and cheaper with the same scope. However, this is an illusion.<\/p>\n

My personal experience going through an agile transformation as a CIO has taught me that to be able to reap the true benefits of agile methods, the whole company needs to become agile \u2012 and this requires far more than just transforming IT. It is not enough to simply implement Scrum in IT, run a few projects the agile way, and believe that the company will then gain speed to market.
\nAfter we had used rapid prototyping methods for years and had co-located our IT teams with the business units, we started to introduce agile methods back in 2013. We experienced some benefits very quickly; by being able to deliver smaller chunks of ready-to-use software much faster than when employing the traditional waterfall methods. However, when trying to put the code into production, we got stuck with our own IT-internal ITIL-based processes. Our IT operations colleagues, who were rightfully charged to guard the \u201choly grail\u201d of stable and secure operation, only allowed code to be promoted based on stringent processes and acceptance criteria at predefined points in time, e.g., when the monthly, or sometimes quarterly release cycles were due. We realised that we would only be able to overcome this bottleneck by including IT operations people in the agile teams (squads) and by making them and their processes part of the agile transformation. This was the advent of DevOps in the organisation.<\/p>\n

While I see many companies stopping their agile transformation at this stage, as they consider agile to be an IT methodology, we wanted to take it further because we noticed that some other parts of the company were still slowing us down, inhibiting us from reaping the true benefits of agile methods.
\nLet me give a few examples of such \u201cagile-inhibitors\u201d in traditional, hierarchically organised companies. Any resemblance with actual people or organisation units of any company I worked for are purely coincidental:<\/p>\n