Agile Transformation Audit

Due diligence assurance on information technology functions and Agile transformations 

Technology departments are expensive to run and managers should be improving their performance continually. Agile transformed IT 20 years ago, yet we still hear of:

• too many large and important projects failing;
• a gap between what the business wants and what IT delivers;
• unhappy users who wait too long for features that don't work properly.

Although all of these problems can be readily addressed, we find legacy thinking and processes get in the way, causing waste and inefficiency. Failed transformation attempts and bastardised Scrum and SAFe implementations tend to hide these underlying problems. But rising costs and decreasing quality indicate there's a problem worth fixing.

We report the causes of those problems, the impact they will likely have, and provide actionable options for executives to overcome them. 

Firms organised and governed by 19th and 20th century models are less productive and less adaptable than their digital age contemporaries. They are: 

• struggling to hire and retain the talent they need to develop new products and services; 
• struggling to maintain profits from existing Business As Usual (BAU) revenues because of legacy ways of working, thinking and technology; and 
• struggling to live-up to their rhetoric for corporate social responsibility or diversity and inclusivity in a world of transparency and social injustice.

Transformation is obviously needed, but by which method and with what assurances? 

Imagine your firm aims to become 200% more effective. You have a Head of Transformation, a budget, agreed measures, and monthly progress meetings with the Executive leadership team.

There's a real upturn as these new initiatives ramp up amongst the delivery teams. Why does this ALWAYS happen? Not because of Agile, Scrum, Kanban, or SAFe. It's because of management's collective focus on improvement.

Inertia against change builds whilst managers' focus returns to Business As Usual and they realise they cannot change the system. Revenue targets and staff appraisals take priority over updating outdated security, accounting, and hiring policies. Agile Transformation programs inevitably run out of momentum. They don't fail, so much as fizzle out.

The Agile Manifesto of 2001 was an engineer's solution to an engineering problem. A response to the tension between the heavyweight and overly controlling methods of the time and the empirically better ways of developing software products that were emerging. The result; better ways of delivering better software.

But Agile delivery is only part of the bigger picture. Revenue comes from selling existing products and services, and profits come from being efficient in operation. That's where Lean is useful, delivering value to customers as quickly and cheaply as possible.

So, both Lean for Business As Usual and Agile for new products are needed, simultaneously.

And, managers have a crucial role in transforming both ways of working.