In this post, I will talk about what the Agile transformation journey involves.

In today’s fast-paced business environment, organizations are under constant pressure to respond quickly to market changes, deliver customer value, and innovate continuously. Many firms adopt agile methodologies to satisfy these needs, but implementing agile at the team level is just the start.

A complete transformation demands an agile transformation journey across culture, processes, and leadership that allows organizations to scale agility across the enterprise. 

Understanding the Agile Transformation Journey

An organization’s transformation journey is a path they embark on that brings them from their old ways of working to fully embracing agile practices in all aspects of its work. This isn’t about simply adopting singular frameworks like Scrum or Kanban; it’s about rethinking workflows, empowering teams, and enmeshing agility within strategic decision making. 

By recognizing the phases of this journey, organizations can address challenges and realize lasting gains. It is a non-linear journey, and it demands iterative advancement, continual learning, and adjustment. Each stage builds on the previous to help shape an environment conducive to collaboration, trust, openness, and value-driven delivery. 

Phase One: Assessment and Readiness

The agile transformation journey stage 1 is about understanding the readiness of your organization to embrace change. This is a review of processes and procedures, leadership alignment, team capabilities, and the culture of the organization. Leaders pinpoint where agility can have the greatest impact and identify potential challenges to adoption.

Institutions typically conduct workshops, surveys, and interviews with stakeholders during this stage as they explore problem areas and opportunities. The information derived from this process becomes the baseline to develop a transformation roadmap that is feasible, focused, and linked to strategic goals. 

Phase Two: Vision and Strategy

Once readiness is evaluated, the agile transformation process moves to vision and strategy development. Leadership define what success looks like whether that be faster product development, better customer satisfaction, or greater operational efficiency.

Having a vision gives teams both direction and motivation. It is a reminder that going agile must have a purpose and not just be a process-driven exercise. A clear strategy defines priorities, core initiatives and metrics for measuring progress and serves as a map to steer the organization through the transformation. 

READ ALSO: How to Pick Human Machine Interfaces Software in 2026 – 9 Things Experts Recommend

Phase Three: Pilot Implementation

The third stage of the journey to agile transformation is to run agile methods as a pilot with teams or work groups. The pilot programs enable organizations to try out frameworks, workflows, and tools in a simulated environment. Best practices identified during this phase feed into the wider rollout and consideration of how to scale agile.

Teams begin to deliver iteratively, they meet regularly for retrospectives, and they begin experimenting with collaboration across functional lines during pilot execution. This gives teams the chance to experience the benefits of agile and identify potential roadblocks that may need to be addressed before a full enterprise-wide rollout. 

Phase Four: Scaling and Integration

Scaling agile is a central part of the agile transformation journey. At this stage, organizations expand adoption across multiple teams, departments, and business units. Frameworks such as SAFe, LeSS, or Disciplined Agile guide coordinating cross-team efforts, aligning priorities, and maintaining strategic oversight.

“Scaling means that processes, tools, and governance models are aligned to promote consistent adoption of agile and enable teams to tailor practices to their environment. Integration may also require connecting agile practices to organizational strategy and portfolio management, and ensuring that agile delivery leads to tangible business results. 

READ ALSO: How to Choose Last-mile Delivery Solutions Designed for E-commerce Growth?

Phase Five: Cultural Embedding and Continuous Improvement

The final stage of an agile transformation is to weave the agile culture and continuous improvement into the DNA of the enterprise. Day-to-day business processes should run on agile principles like collaboration, transparency, and customer-centricity. Leadership, performance metrics, and reward systems should reinforce those values.

The result is continuous improvement through the mechanism of regular retrospectives, feedback loops, and performance measurement. Teams iterate on their workflows and practices as they learn from both challenges and successes. This stage validates that agility can be maintained and remain responsive to changing business needs. See guidance on the stages of progress of this resource on the stages of the agile transformation journey. 

Conclusion

The journey of agile transformation is a phased approach combining evaluation, planning, piloting, executing, and cultural embedding. In the process of following this path, organizations progress from uncoordinated agile approaches to full enterprise agility, enhancing responsiveness, collaboration, and customer value.

Each stage enables the next, allowing organisations to continually adapt, improve practices, and integrate agility into the organisation’s DNA. A successful, strategic agile transformation journey will result in the organization not just adopting new methods, but excelling in an ever-changing business environment. 

INTERESTING POSTS

The validation phase of continuous threat exposure management (CTEM) determines whether an attack could succeed in your particular environment. Your teams get proof of attack viability and can concentrate remediation efforts on exploitable exposures, not scoring severity.

The 2026 Verizon Data Breach Investigation Report revealed that exploiting vulnerabilities was the most popular initial access vector, used in 31% of breaches. However, Frontier AI models are boosting the rate of vulnerability discovery, meaning there are many more findings that need assessment.

Your CISO and security operations team need to know which exposures give a threat actor a feasible path to a critical asset. Common Vulnerability Scoring System (CVSS) scores cannot answer that question.

Where does validation sit in CTEM?

Security control validation, the fourth stage of CTEM, coming after scoping, discovery, and prioritization, but before mobilization.

As part of the scoping phase, organizations identify the elements of their attack surface that matter most to their business. In the discovery phase, teams identify vulnerabilities that lie within the scope of their attack surface. These vulnerabilities get prioritized on the basis of various parameters including threats, importance of the asset, exploitability, and business impact.

CVSS scores indicate the technical severity of a threat, but do not say whether an adversary can leverage this flaw in your environment. In addition, CVSS scores cannot account for all possible compensating controls, such as identity protections, endpoint defenses, or firewall rules, that could prevent exploitation of this vulnerability.

The validation phase of CTEM provides additional information on the feasibility of attacks. This evidence can help you distinguish between exploitable exposures and high-level risks that are mitigated by compensating controls. 

Why have security teams historically under-validated exposures?

Historically, offensive testing required specialist expertise, complex tooling, and significant time. Large, rapidly changing environments make all of that harder to manage continuously.

Penetration testing provides valuable evidence of exploitable weaknesses and attack paths, but a point-in-time engagement examines the environment only during a defined period. A single engagement doesn’t account for variables such as changes to cloud resources, identities gaining new privileges, new software releases, or shifting firewall rules. 

Teams often focus on remediation without having established whether a threat actor can actually exploit the vulnerability. More severe vulnerabilities rise in importance simply because their scores meet a certain threshold, and sometimes others take precedence based on the importance of the asset they affect. 

Both are valid concerns, but neither can prove if the weakness actually enables an attack.

Validating security controls provides another step in proving this by ensuring that defenses such as endpoint detection and response (EDR), multi-factor authentication (MFA), and firewalls disrupt attack techniques.

What does continuous exposure validation look like in practice?

Continuous exposure validation involves assessing exposure information alongside attack feasibility and defense coverage information. This process tests whether an attacker can exploit an existing vulnerability and move closer to an important asset.

Take a vulnerability on an internet-facing system. Its severity and your current threat intelligence may justify close attention, but the investigation cannot stop there. You need evidence of:

• Exploitability of the weakness against the deployed configuration
• Firewall blocking of the required traffic
• EDR interruption of the next technique in the sequence
• MFA prevention of attackers using captured credentials

These answers will change your remediation queue. An active control could block the sequence that would make a present vulnerability useful to an attacker. Elsewhere, a moderate-severity weakness could form part of an exploitable path to one of your critical assets where you have no effective compensating control.

Your teams can use validation to assess:

• EDR coverage against techniques like credential dumping
• MFA effectiveness against password spraying and credential stuffing
• Firewall rules that actually block the traffic attackers need to move through the environment
• Security information and event management (SIEM) visibility over assets tied to high-priority attack paths
• Pen test results that confirm which vulnerabilities are genuinely exploitable

Validation can eliminate dead-end attack paths. A graph may show a possible link between systems, identities, and vulnerabilities, but validating the relevant control can confirm that attackers cannot exploit that path.

How does validation expose toxic combinations?

Separate weaknesses interact in ways that can build major exposure. On their own, a vulnerability, an excessive privilege, a weak identity control, and an exposed service each seem manageable, but together, they form an exploitable path.

Conventional vulnerability queues separate those findings. Your vulnerability management team sees a software flaw, your identity team sees an overprivileged account, and your cloud team sees a misconfiguration. Looking at each in isolation obscures the opportunity for attackers.

Exposure validation proves whether these conditions allow attackers to proceed further. If your control measures do not break the chain, you need to focus on this combination.

Validation also reveals at what point the path is stopped. For example, EDR stops credential theft, MFA stops account misuse, and network controls halt any movement along the attack path. Dead-end attack paths must not fight for limited remediation resources with validated, exploitable exposures.

How does validation improve prioritization and mobilization?

The prioritization process becomes much more precise when you can test if an exposure can launch a successful attack. The mobilization phase uses this knowledge to get the relevant teams working together.

Remediation could include patching a vulnerability, reducing privileges, configuring something correctly, expanding your EDR monitoring, implementing MFA, or changing firewall rules. Attack path evidence enables your teams to determine the best way to disrupt attack paths.

The approach is nothing like conventional “patch everything” programs. This approach is risk-based remediation that concentrates resources on the exposures that could realistically damage your business. External intelligence gives context by pinpointing exposed assets, leaked information, and other outside-in signals to help your teams understand where to focus their defensive efforts.

Why does exposure validation matter more as Frontier AI accelerates discovery?

Faster vulnerability discovery puts pressure on your security teams to distinguish feasible attacks from findings that current defenses already neutralize. Your remediation capacity does not increase just because you find vulnerabilities faster.

Frontier models also accelerate vulnerability research and discovery. Threat actors use large language models (LLMs) to support parts of their work. Security teams must assess new findings quickly without treating every technically valid weakness as equally urgent.

Continuous validation keeps your assessment process relevant to current conditions by confirming when a newly discovered vulnerability creates an exploitable path to a critical asset, when a control change closes an existing path, or when a new identity relationship turns several lower-severity weaknesses into a toxic combination.

As vulnerability discovery quickens, security teams need current evidence about which exposures deserve action. The validation stage moves past “we found it” and gives evidence by testing the feasibility of attacks against your current environment and controls.

INTERESTING POSTS

The supply chain doesn’t break at logistics anymore. It breaks at login.

According to the Thales Digital Trust Index 2026 report, 89% of partner users have delayed or abandoned work due to access issues. Let that sink in and imagine the impact on your topline.

This elevates the issue from an IT convenience to revenue at risk, forcing organizations to examine how friction in their partner/supplier/reseller onboarding and authentication processes might be undermining bigger, more long-term gains. 

Smooth Partner Onboarding is the Exception, Not the Rule – Unfortunately

The Thales report reveals that among partners, only 22% receive working login details immediately; the rest have to wait.

In addition:

• Only 30% get full permissions the first time
• 66% lose access to external partner systems while they still need it
• 92% experienced access issues overall

The problem (beyond what’s already been laid out) is that in these situations, partners find workarounds. When faced with access friction, nearly two-thirds (66%) have shared or borrowed credentials, with over half citing slow official processes as the cause. 

These issues present even more business risks. Not only does delayed access prevent partners from doing their work or delivering value, but it also leads to the kind of technical fence-jumping that could cause companies to lose value they’ve already gained. 

Beyond the productivity hit, delayed access and credential workarounds accumulate what the report calls ‘silent security debt’, a growing exposure to breaches and compliance risk that rarely gets priced into onboarding cost calculations.

When it takes an average of 30-60 days for third-party assessments alone and 1-6 months to bring them on board, these kinds of delays are as expensive as they are inexcusable. 

Putting a Price Tag on Onboarding Delays

If your partners aren’t logging in cleanly and immediately, they’re not fully onboarded. And if they’re not fully onboarded, you’re not seeing full ROI.

Over a quarter (26%) of companies report losing $500k or more due to partner integration issues. Slow onboarding leads to missed deals, delayed time-to-revenue, and partner churn, incurring additional costs along the way. 

It costs thousands of dollars to onboard a supplier, and companies are looking to make that up with quick time-to-value. Login issues, false starts, and ongoing friction not only delay start times but also throw off long-term timelines, wreck projected productivity, and force teams to redo expectations. The result: work waste and revenue loss.

To highlight just one area of loss, password resets still cost around $70 per incident, and, applied to real user populations, that equates to $37,800 annually for 3,000 registered users. Whether those users are your employees or third-party employees using those credentials to log in to your systems. 

It is worth noting that most IAM administration is still done in-house, but research shows that more partners are willing to take this on. More on this in the next section. 

In the worst cases, too much friction could lead to missed opportunities, and this holds true across the board. A quarter of businesses report losing a deal due to slow legal onboarding processes. According to Fenergo’s 2025 Financial Crime Industry Trends report, 70% of financial institutions globally lost clients due to slow or inefficient onboarding. 

And like the opening stat introduced, “89% of partner users have abandoned or delayed a work task with an external partner in the past 12 months due to a website or app issue.” No matter the industry, or if it’s B2B or B2C, IAM friction in the onboarding process is a cost center, but it’s one that can be avoided.

What Partners Want out of B2B Access?

The Thales research revealed an interesting trend that could help companies offset the cost of B2B access: shifting more of the burden to partners themselves. Perhaps not surprisingly, partners want that. 

According to the report, partners want more self-service access, so access is increasingly in their hands. Over half (54%) wanted the ability to reset authentication factors themselves, and 52% wanted to see their current entitlements.

Delegated User Management, a key component of Extended Enterprise Access, fills this need, allowing organizations to maintain overarching control over identity systems while the responsibility for third-party access is offloaded to the third parties themselves:

The host organization decides which IAM controls can be delegated. A delegated manager within the partner organization takes the lead on that, acting as a proxy admin for their users. That partner has the power to grant, revoke, or update access for their team, and all requests go through them. 

This leads to offset costs for the host while resulting in greater (and faster) ROI. IT gets fewer repetitive tickets; access issues get resolved faster, so teams can get back to work sooner; and third-party IAM issues don’t result in greater costs as the partnership scales. 

Offloading IAM may be step one. But no matter where the onus resides, automation has to be step two. 

Making Automated B2B Access the Norm

When surveyed by Thales, only 22% reported that system access was automated or “provided immediately.” That means four out of five had to wait. And in an era of AI and hyperautomation, many are wondering why. 

The absence of these automated workflows takes a toll in other areas as well: only 19% reported that access changes keep pace with working needs. This can be a problem. A sale could be lost if the distributor can’t retrieve the proper inventory information. Or a competing vendor may be quoted when a reseller can’t access pricing tools.

Partner/B2B IAM is a Financial Issue

All this underscores the fact that B2B IAM extends far beyond convenience and PX. IAM failures delay projects and billing cycles. They propagate outdated information and force host companies to bear supplier costs they shouldn’t.

This makes partner IAM not just an administrative issue, but a financial one with revenue at stake. 

Because people are accessing these systems, friction leads to frustration, errors, time loss, and a domino effect of lost productivity. It sets everything off on the wrong foot, and in the case of many deals, things won’t recover. 

Partnerships don’t have to come with a buffer for operational drain. To ensure they don’t, senior leaders have to take B2B access out of the IT weeds and into the boardroom. 

INTERESTING POSTS

In this post, I will show you how I’d use the GLM-5.2 API for a long-running coding agent.

If I were setting up a coding agent today — the kind that’s supposed to run for hours, work through a real codebase, and come back with something actually finished rather than a half-baked first attempt — GLM-5.2 api is where I’d start.

Not because it’s the flashiest name in the room, but because long-running agents fail in a very specific way, and this is one of the few models actually built with that failure mode in mind.

The Problem Nobody Warns You About Until It Happens

Here’s what nobody tells you before you build your first long-running agent: the failure isn’t usually a dramatic crash. It’s slower and quieter than that. The agent starts strong, makes good decisions for the first stretch of a task, and then somewhere around hour two or three, it starts losing the plot.

It forgets a constraint it agreed to earlier. It re-does work it already finished. It confidently “fixes” something that wasn’t broken. None of this shows up in a quick demo, because demos are short. It only shows up once you actually let the thing run.

That’s the exact scenario GLM-5.2 was built around, which is why it’s the model I’d reach for first rather than whatever’s topping a general leaderboard that week.

Why I’d Trust It to Actually Stay on Track

What sold me isn’t a single benchmark number, it’s the pattern across all of them. GLM-5.2 keeps showing up strongest specifically on the evaluations that simulate messy, hours-long engineering work rather than quick, self-contained problems.

On the kind of test that mimics an agent looping through a real repository — reading, planning, executing, checking its own work — it holds up close to the very best models out there, closed or open. That’s a different skill than being clever on a single tricky question, and it’s the one that actually matters once your agent’s task list is measured in hours instead of minutes.

Giving It Room to Actually See the Whole Project

The other piece I’d lean on hard is how much it can hold in view at once. A long-running agent working across a real codebase needs to see more than the one file it’s currently editing — it needs the surrounding context, the conventions the rest of the project follows, the pieces it touched three steps ago. GLM-5.2’s context window is big enough to hold a genuinely sizeable project in view all at once, instead of forcing the agent to work blind, one small slice at a time, and hope nothing important got left out of frame.

That’s less “nice to have” and more the actual difference between an agent that understands what it’s working inside of and one that’s just guessing.

If you’re building this kind of setup yourself, it’s worth spending a little time in the GLM-5.2 api listing before committing to anything — seeing what it sits next to, and what the nearby options trade off, tends to clarify what you actually need a lot faster than reading a single spec sheet in isolation.

The One Feature I Didn’t Expect to Care About This Much

GLM-5.2 can also be paired with a web-search tool during a task. Instead of switching to a separate model version, the agent can invoke search when it needs current documentation, recent release notes, or an external source to verify an assumption. That sounds like a small add-on until you picture what a long agent run actually needs.

A coding agent working for hours doesn’t just need to reason about the code in front of it — it occasionally needs to check something outside its own head. Did a library’s API change since the model’s training data was collected? Is there a known issue with the exact error it just hit? Rather than the agent confidently guessing at an answer that might be out of date, it can actually go look, mid-task, without a separate setup. For anything that touches fast-moving dependencies or recent library changes, that’s the difference between an agent that occasionally hallucinates its way past a stale assumption and one that just checks. 

Where I’d Actually Draw the Line

I wouldn’t pretend this is the right tool for everything, and I’d be doing you a disservice if I acted like it was. If the job is a tight, well-specified algorithmic problem — something closer to a competitive programming puzzle than an open-ended engineering task — there are other models built specifically to be faster and cheaper at exactly that kind of question, and I’d route to one of those instead rather than defaulting to the same model for every job.

The honest way to think about it is that GLM-5.2 is the specialist for staying coherent across a long, messy, multi-step project, not the fastest or cheapest option for every single request an agent might make along the way. A GLM-5.2 API for coding comparison against a more math-and-algorithms-focused alternative is worth reading before you commit your whole pipeline to one model, because the right answer genuinely depends on which of those two failure modes worries you more.

What I’d Actually Build

If I were setting this up for real, I wouldn’t hand every single request to the same configuration. I’d let the long-horizon planning and the bulk of the repository work run through GLM-5.2, with the web-search variant switched on specifically for the moments the agent needs to check something outside its own training — a library version, a recent breaking change, a fix someone already published.

And I’d keep a faster, narrower model on standby for the quick, tightly scoped questions that don’t need any of that context or reasoning depth. That’s not a compromise so much as it’s just matching the tool to the job, one more time, the same way I’d want any agent I trust with real work to be built.

INTERESTING POSTS