Agile Transformation Consulting

This is a senior Agile / Transformation Coach / Program Delivery Lead role (Enterprise consulting). The salary range (ZAR 1.28M–2.48M) signals you’re operating in leadership + transformation + consulting, not just delivery.

Here are the exact skills you need, grouped in a practical way:

1. Agile & Delivery Mastery (Core Technical Skillset)

You need to be fluent in:

• Agile frameworks (deep, not surface-level)

  • Scrum (Sprint planning, retros, ceremonies)

  • Kanban (flow, WIP limits, cycle time)

  • SAFe (Scaled Agile Framework in enterprise environments)

• Agile coaching (this is key for the job)

  • Coaching teams through resistance to Agile

  • Improving team maturity levels

  • Shifting teams from “doing Agile” → “being Agile”

• Program & project delivery

  • Managing multiple squads or workstreams

  • Dependency tracking across teams

  • Delivery forecasting and release planning

• Continuous improvement systems

  • Retrospective facilitation at scale

  • Process optimisation (Lean thinking)

  • Removing delivery bottlenecks

2. Enterprise Transformation Skills gets you paid the big salary

This is where senior roles separate from junior Agile coaches:

• Leading organizational change initiatives

• Designing and rolling out Agile transformations

• Aligning Agile ways of working with business strategy

• Driving adoption across multiple departments or business units

• Operating in matrixed organizations (many stakeholders, no single boss)

You’re not just coaching teams — you’re changing how the company works.

3. Leadership & Stakeholder Management (Critical)

You must be able to influence without authority:

• Executive stakeholder management (C-level, directors)

• Running steering committees and transformation boards

• Negotiating priorities between business vs tech teams

• Handling conflict between delivery teams and leadership

• Executive communication (clear, structured, data-backed)

This is often the #1 hiring filter.

4. Program Management Capability

Even though it’s “Agile coaching,” this role is heavily delivery-focused:

• Managing multiple concurrent initiatives

• Roadmap planning across teams

• Risk, issue, dependency management

• Reporting (KPIs, OKRs, velocity, delivery health)

• Budget and capacity awareness (at enterprise level)

5. Analytical & Systems Thinking

You need to think in systems, not tasks:

• Understanding how teams, processes, and tools interact

• Using data to improve delivery performance:

  • velocity trends

  • flow efficiency

  • lead time / cycle time

• Identifying systemic blockers vs individual issues

• Designing scalable solutions (not just team fixes)

6. Facilitation & Coaching Excellence

This is your “on-stage skillset”:

• Facilitating workshops with 10–100+ stakeholders

• Leading retrospectives, planning sessions, transformation workshops

• Coaching individuals and teams through resistance

• Powerful questioning and behavioural change coaching

• Conflict resolution and alignment sessions

7. Tools & Technical Environment Familiarity

Not always mandatory, but expected:

• Jira / Azure DevOps

• Confluence

• Agile reporting dashboards (Power BI often)

• SAFe toolkits or enterprise Agile frameworks

• Remote collaboration tools (Miro, Teams, Slack)

8. Soft Skills. What actually determines success

These are non-negotiable at this level:

• Executive-level communication (clear, structured, calm)

• High emotional intelligence

• Strong presence and authority in rooms

• Ability to handle ambiguity and pressure

• Influencing without formal authority

• Conflict navigation and diplomacy

9. Experience Level Expected

To be realistic for this salary band:

• 6–12+ years in:

  • Agile delivery OR

  • Project/program management OR

  • Transformation consulting

• 3–5+ years specifically in:

  • Agile coaching OR enterprise transformation

10. The Identity of This Role (Important insight)

This is not just a job title.

It is a hybrid identity of:

• Agile Coach

• Transformation Consultant

• Program Delivery Lead

• Executive Advisor

• Organisational Change Agent

You are essentially:

“Someone who helps large organisations change how they deliver work.”

If you want a shortcut insight

If you can confidently say:

• “I have led Agile transformation across multiple teams”

• “I’ve influenced senior stakeholders without authority”

• “I’ve improved delivery performance using Agile systems”

• “I coach teams and leaders through change”

…then you are in the right category.

Below is a structured “100 must-know concepts & skills” breakdown for an Agile Transformation / Program Delivery Lead / Agile Coach (enterprise level like Accenture). This is the full competency map hiring managers are implicitly testing.

A. Agile Foundations (1–15)

1. Agile Manifesto values & principles

2. Scrum framework end-to-end

3. Kanban system design

4. Agile vs Waterfall delivery models

5. Iterative vs incremental delivery

6. Sprint lifecycle (planning → review → retro)

7. Product backlog structure

8. User stories and acceptance criteria

9. Definition of Done vs Definition of Ready

10. Backlog refinement techniques

11. Sprint goal setting

12. Velocity tracking basics

13. Burndown and burnup charts

14. Agile estimation (story points, t-shirt sizing)

15. Agile ceremonies purpose and facilitation

B. Scaling Agile / Enterprise Frameworks (16–30)

16. SAFe framework fundamentals

17. Scrum of Scrums

18. Nexus / LeSS concepts

19. Cross-team dependency management

20. Agile Release Trains (ARTs)

21. PI Planning (Program Increment planning)

22. Feature vs Epic vs Story hierarchy

23. Value stream mapping

24. Portfolio Kanban

25. Enterprise backlog prioritization

26. Lean-Agile leadership principles

27. Agile governance models

28. Multi-team coordination patterns

29. Scaling frameworks trade-offs

30. Agile transformation phases

C. Agile Coaching Skills (31–45)

31. Coaching vs mentoring vs consulting distinction

32. Powerful questioning techniques

33. Active listening mastery

34. Observation of team dynamics

35. Team maturity assessment

36. Coaching stances (facilitator, teacher, advisor)

37. Conflict coaching in teams

38. Behaviour change facilitation

39. Psychological safety building

40. Coaching Agile adoption resistance

41. Facilitating retrospectives at scale

42. Team performance coaching

43. Coaching leadership teams

44. Feedback delivery frameworks

45. Identity and mindset coaching in Agile context

D. Program & Delivery Management (46–60)

46. Program governance structures

47. Delivery planning across multiple teams

48. RAID management (Risks, Assumptions, Issues, Dependencies)

49. Roadmap planning

50. Release planning

51. Capacity planning

52. Resource allocation in matrix orgs

53. Dependency mapping tools

54. Delivery forecasting techniques

55. Milestone tracking

56. Program KPIs definition

57. Status reporting for executives

58. Delivery health dashboards

59. Escalation management

60. Delivery risk mitigation strategies

E. Transformation & Change Leadership (61–75)

61. Organizational change management (OCM)

62. Kotter’s 8-step change model

63. ADKAR model

64. Transformation roadmap design

65. Agile maturity assessments

66. Culture change strategies

67. Stakeholder alignment techniques

68. Resistance management strategies

69. Operating model redesign

70. Governance transformation

71. Enterprise Agile adoption strategies

72. Change communication planning

73. Leadership alignment facilitation

74. Behavioural change at scale

75. Transformation success metrics

F. Leadership & Stakeholder Management (76–85)

76. Executive communication skills

77. Stakeholder mapping & analysis

78. Influencing without authority

79. Conflict negotiation

80. Steering committee facilitation

81. Executive reporting storytelling

82. Cross-functional alignment

83. Political navigation in enterprises

84. Decision-making frameworks (DACI/RACI)

85. Leadership coaching principles

G. Analytics & Continuous Improvement (86–92)

86. Flow metrics (lead time, cycle time)

87. Throughput analysis

88. Agile maturity metrics

89. KPI vs OKR frameworks

90. Process bottleneck analysis

91. Lean thinking principles

92. Continuous improvement cycles (Kaizen)

H. Tools, Systems & Delivery Environment (93–97)

93. Jira advanced usage (boards, workflows, reporting)

94. Azure DevOps / Rally tools

95. Confluence documentation systems

96. Power BI / Agile dashboards

97. Remote collaboration tools (Miro, Teams, Slack)

I. Professional Identity & Consulting Skills (98–100)

98. Consultant mindset (diagnose → design → implement)

99. Facilitation of large-scale workshops (50–100+ people)

100. Transformation leadership identity (trusted advisor to executives)

Key Insight (Important)

At this level, you are NOT being hired just for Agile knowledge.

You are being hired for:

“Can you change how an entire organisation delivers work — and influence executives while doing it?”

The Agile Manifesto is the foundation of all Agile ways of working (Scrum, Kanban, SAFe, etc.). It consists of 4 values and 12 principles that define how teams should deliver work in a flexible, iterative, human-centred way.

 Agile Manifesto — 4 Core Values

1. Individuals and interactions over processes and tools
   → People and communication matter more than rigid systems.

2. Working software over comprehensive documentation
   → Deliver something usable, not just paperwork.

3. Customer collaboration over contract negotiation
   → Work with customers continuously, not just at the start.

4. Responding to change over following a plan
   → Adapt quickly when reality changes instead of sticking to a fixed plan.

 Agile Manifesto — 12 Principles

1. Customer satisfaction through early and continuous delivery
   Deliver value frequently, not at the end.

2. Welcome changing requirements
   Even late in development, changes are seen as improvements.

3. Deliver working solutions frequently
   Prefer short cycles (weeks, not months).

4. Business and developers must work together daily
   Close collaboration between stakeholders and teams.

5. Build projects around motivated individuals
   Give people trust, support, and autonomy.

6. Face-to-face communication is most effective
   Direct conversation reduces misunderstanding.

7. Working software is the primary measure of progress
   Not reports, not plans — actual output.

8. Sustainable development pace
   Teams should avoid burnout and maintain long-term productivity.

9. Continuous attention to technical excellence
   Good design and quality improve agility.

10. Simplicity is essential
    Do only what is necessary; avoid waste.

11. Self-organising teams produce the best results
    Teams should decide how to do their work.

12. Regular reflection and adaptation
    Teams should continuously improve through retrospectives.

 Simple Way to Remember It

• Value = mindset (what matters)

• Principles = behaviour (how you act)

The Agile Manifesto: What It Really Means in Modern Organisations and Why Most Teams Get It Wrong

In most enterprise environments today, “Agile” has become a buzzword.

Teams run stand-ups.
They use Jira boards.
They do sprints.

And yet… many organisations are still struggling with slow delivery, misalignment, burnout, and constant change fatigue.

The issue is not Agile as a framework.

The issue is that most teams have forgotten the foundation it was built on:

 The Agile Manifesto.

The Agile Manifesto is not a process, it’s a mindset

At its core, the Agile Manifesto is made up of:

• 4 values

• 12 principles

Together, they define a very simple idea:

“Work should be adaptive, human-centred, and focused on delivering value continuously.”

But in many organisations, Agile has been reduced to tools and rituals rather than mindset and behaviour.

The 4 Agile Values and what they actually mean in practice

1. Individuals and interactions over processes and tools

It’s not about Jira.

It’s about whether teams are actually talking, aligning, and solving problems together.

High-performing Agile teams prioritise communication over administration.

2. Working software over comprehensive documentation

Documentation matters, but only if it supports delivery.

The real question is:

“Are we producing something usable that creates value?”

Not:

“Do we have enough documentation to feel safe?”

3. Customer collaboration over contract negotiation

In traditional environments, work is defined once and handed over.

In Agile environments, customers are part of the journey, continuously shaping outcomes.

The result:

• less rework

• better alignment

• faster value delivery

4. Responding to change over following a plan

Plans are useful.

But in modern environments, change is constant.

Agile organisations succeed because they adapt faster,  not because they predict better.

The 12 Principles that separate theory from real transformation

The principles behind Agile are where real maturity shows up:

• Deliver value early and continuously

• Welcome changing requirements

• Work closely with stakeholders daily

• Build motivated, empowered teams

• Focus on working output as progress

• Maintain a sustainable pace

• Strive for technical excellence

• Keep things simple

• Encourage self-organising teams

• Reflect and improve continuously

These are not “nice-to-haves.”

They are the difference between real agility and process theatre.

Why most Agile transformations fail

In enterprise environments, Agile often fails for 3 reasons:

1. Tools replaced mindset

Teams adopt Jira but not the behaviours behind it.

2. Leadership stays command-and-control

Teams are told to be “Agile” but are still controlled like Waterfall.

3. Delivery is prioritised over learning

Speed is rewarded more than adaptability.

What real Agile looks like

True Agile organisations show:

• Fast feedback loops

• Empowered teams

• Clear outcomes, not just outputs

• Continuous learning culture

• Strong collaboration between business and delivery

Most importantly:

They are comfortable with uncertainty.

Final thought

Agile is not a methodology you implement.

It is a way of thinking you cultivate.

And when done properly, it changes not just delivery,  but leadership, culture, and organisational behaviour itself.

If your organisation is “doing Agile” but not seeing real results, the question is not whether Agile works.

The question is:

“Are we actually living the Agile values and principles, or just performing the rituals?”

🧩 Scrum Framework End-to-End

Scrum is a lightweight Agile framework used to deliver complex work in small, iterative cycles called Sprints.

A full Scrum cycle is built around:

• Roles

• Events (ceremonies)

• Artifacts

• Continuous feedback loops

 1. Scrum Roles (Who is involved)

 Product Owner

• Owns the product vision

• Manages and prioritises the Product Backlog

• Decides what delivers the most value

• Represents the customer/business

 Scrum Master

• Facilitates the Scrum process

• Removes blockers

• Coaches the team in Agile ways of working

• Protects the team from distractions

 Development Team

• Builds the product (software, service, or output)

• Self-organising and cross-functional

• Delivers “Done” increments every Sprint

 2. Scrum Artifacts (What is being worked on)

 Product Backlog

• Master list of all work needed

• Ordered by priority/value

• Continuously refined

 Sprint Backlog

• Selected work for the current Sprint

• Commitment by the team for the next iteration

 Increment

• The finished, usable product output

• Must meet the Definition of Done

• Potentially shippable

 3. Scrum Events (The Sprint Cycle)

A Sprint is typically 1–4 weeks.

1️. Sprint Planning (Start of Sprint)

Purpose:

• Decide what will be delivered this Sprint

Key activities:

• Product Owner presents priorities

• Team selects work from backlog

• Sprint Goal is defined

Output:

• Sprint Backlog

• Sprint Goal

2️. Daily Scrum (Daily stand-up)

Purpose:

• Synchronise the team

Each team member answers:

• What did I do yesterday?

• What will I do today?

• What blockers do I have?

Duration:

• 15 minutes

3️. Development Work (Execution phase)

This is where the real work happens:

• Coding / building / designing

• Collaboration across team members

• Continuous integration and testing

Key focus:

• Move items from “To Do” → “Done”

4️. Sprint Review (End of Sprint)

Purpose:

• Show what was delivered

Activities:

• Demonstrate completed work

• Stakeholders give feedback

• Product Owner may adjust backlog priorities

Output:

• Updated Product Backlog

5️. Sprint Retrospective (After Review)

Purpose:

• Improve how the team works

Focus:

• What went well?

• What didn’t go well?

• What should we improve?

Output:

• Action items for next Sprint improvement

 4. The Full Scrum Flow (End-to-End Cycle)

1. Product Owner prioritises backlog

2. Team selects work in Sprint Planning

3. Sprint Goal is set

4. Team works daily in Sprint cycle

5. Daily Scrum ensures alignment

6. Increment is built continuously

7. Sprint Review validates output with stakeholders

8. Retrospective improves process

9. Back to backlog refinement and next Sprint

This loop repeats every 1–4 weeks.

 5. What “Good Scrum” actually looks like

High-performing Scrum teams have:

• Clear Sprint Goals

• Stable team structure

• Strong backlog refinement

• Fast feedback loops

• High transparency

• Low dependency delays

• Continuous improvement mindset

 Common Misunderstandings

• Scrum is NOT just daily stand-ups

• Scrum is NOT a tool like Jira

• Scrum is NOT a project plan

• Scrum is NOT fixed scope delivery

Scrum is a feedback-driven delivery system.

 Simple Summary

Scrum =

A structured way to deliver work in small cycles with continuous feedback, inspection, and adaptation.