The big move: from Waterfall to Agile and what it means for IT Governance

Publish date:

As the great migration to Agile continues, IT risk and security must adapt to survive. But what does Agile IT governance look like, and where do organisations begin?

Take a UK automotive financing firm, running 100% Waterfall methodology for IT projects: the governance team checks risk at regular gateways and progression halts until all boxes are checked.

Now add an 80% Agile methodology target within 18 months. How do you manage risk without removing agile from Agile?

Numerous IT governance teams face this question today. The phrases ‘just enough governance’ or ‘governance 2.0’ come to mind, but how does this actually manifest itself?

Navigating Agile terminology and avoiding the ‘Wagile’ trap

A big challenge when adapting to Agile is fully transitioning. It’s common to encounter organisations ‘doing’ Agile, not being agile. In contrast, the most successful Agile frontrunners scale Agile beyond software development into organisational agility, according to a new report by the Capgemini Research Institute.

Organisational culture plays a huge role: replacing well-honed checkpoints or shifting responsibilities amongst teams is a leap of faith. Major changes are a justifiable concern. What can occur is a hybrid of old and new, for better or worse: Agile meets Waterfall, or ‘Wagile’.

Terminology affects this, merging interpretations and methodologies. One organisation’s product team is another’s developer team. One person’s Agile is another’s DevOps or Scrum, without distinguishing their differences. As a result, developers’ experience may differ considerably.

This holds true for organisational interpretation of Agile IT governance, where DevSecOps is the buzzword but implementation may fit into the broad pot of IT Governance 2.0.

Example in action: unwinding the historic approach in identifying key risks in IT transformation

The automotive financing firm’s historic approach, dictated top-down by the wider Group, fixated around systems’ CIAA – confidentiality, integrity, availability and authenticity. The IT governance team assessed these typical security considerations at the design stage. This risk assessment output determined projects’ security controls and engagement levels between the project team and IT governance.

The assessment’s key problem was the rigid drop-down criteria, ignoring wider risks like internal processes supporting the change, target users, cloud or web-facing exposure for a well-rounded risk picture.

The process’s key problem was the communication channel. Long gaps without engagement between stage-gates and the one-off formal assessment at design stage disabled evolution over project lifespans, and disconnected project teams from risk management.

This wouldn’t hold in Agile. But with no guiding Group policy, our firm was an Agile pioneer for the wider organisation.

Reinventing the governance wheel: do you care about what you’re told to care about, or what you know matters?

The fundamental question asked of the IT governance team was this: if you can’t review everything, and you aren’t restricted by CIAA terminology, what do you actually care about when prioritising risks?

This identified the key trigger of concern – data. The next question: what else?

In one workshop, 8 key concerns with the new product-centric Scrum teams were uncovered:

  1. Data – the highest classification affected
  2. System integrity – e.g. for regulatory reporting or payment transactions
  3. Scrum team – team experience, skills, availability
  4. Work complexity – from repetitive tweaks to new web-facing customer implementations
  5. Methodology – team tools and process maturity, e.g. code review and product backlog management. Capgemini’s DevSecOps maturity assessment is an easy way to review this
  6. Sprint management – velocity, say-do ratio and risk-related user stories
  7. Third party involvement – prior experience or arrangements, and extent of reliance on them
  8. Delivery – blockers like environment refreshes, related work streams and communication channels.

These formed a new iterative risk assessment and engagement determination process. Aiming to assess three key features per product team per cycle, an assessment spreadsheet with automated weighting and criteria was created. This would determine the engagement level required from the IT governance team per feature (every sprint, monthly, quarterly), and provide an overall summary of the product team risk portfolio.

To avoid prior communication concerns, a feedback loop was created between IT governance and product teams for enhancing the process and obtaining buy-in. A quarterly cycle to determine risk and engagement was agreed.

It’s tempting to comment that this process still firmly places IT governance with Subject Matter Experts (SMEs). Whilst the DevSecOps idyll isn’t achieved, the engagement’s effect on product teams shouldn’t be downplayed. An emphasis on removing blockers and early frequent product team involvement in IT risk identification and remediation, has shifted risk and security conversations from SMEs at agreed gateways to iterative group conversations. Product teams actively engage with governance.

Will this balance hold? A question for another day. With basics in place, our next steps are to provide product teams with education and tools to embed security into their everyday mindset, putting security where it works best: at the risk source.

The Capgemini offer – implementing security touchpoints in the SDLC

Capgemini’s experience in Agile and DevOps indicates that risk and security must be integrated into the Software Development Life Cycle (SDLC) across seven touchpoints.

Our automotive financing firm focused on the Agile risk analysis touchpoint: translating technological design decisions into re-measurable risks, for decision-makers to understand changing risks as products evolve.

For a holistic view of how secure your DevOps is, take a quick but thorough survey benchmarking your DevSecOps maturity against peers, covering:

  1. Security blueprint and framework
  2. Culture, collaboration and education
  3. Security by design
  4. Risk-based security testing
  5. End-to-end monitoring
  6. Continuous security improvement.

 

Author


Charli Douglas

Future of Technology Senior Consultant

A Digital Trust and Security consultant at Capgemini, specialising in IT risk management transformation, assurance and data protection.

Related Posts

Cybersecurity

Benefits of proactive compliance to an organisation

Date icon October 25, 2019

Anna Gassem, Associate Consultant, showcases the benefits of proactive compliance to a...

Cybersecurity

A new era in data privacy enforcement: your open source code may be your new weakest link

Date icon September 6, 2019

As you may have heard, an airline company was assigned a potential £183 million fine by the...

Automotive

Modelling a smart motorway – the conference

Date icon July 24, 2019

Ed Richardson, SAP Functional Consultant, shares a few ideas about applying the IoT to drone...

cookies.

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.

Close

Close cookie information