Insurance or not, many organizations are transforming themselves with agile models. We spoke to a top leader of an international insurance firm that is leveraging Agile approaches more often and in more projects. Here are some learnings we discovered.

What challenges did you need to overcome to be successful?

As we looked to scale Agile across our organization, one of the biggest problems that we experienced was that our tool wasn’t, well, agile. It was little more than a fancy looking spreadsheet and our staff spent their time battling with the tool rather than leveraging the tool to help the business. That just wasn’t sustainable.

In what ways do you address these issues?

Just like any other aspect of business, the ability to deliver work effectively using Agile requires a combination of the right information driving the ability to make sound decisions in a timely manner, and a tool that allows people to focus on doing their work rather than interacting with the tool. We needed to find a solution that could easily integrate with our other enterprise tools, and that could help us become more effective and efficient.

What was your end solution, and what impact did it have?

For us, Rally Software from Broadcom was the answer. We recently ran our first PI planning session using the tool and we cut the duration of the planning session by two hours. Multiply that across the number of people and the number of times we plan PIs and it becomes a material saving. And of course, that efficiency means staff time can be redirected into work that adds value to the business.

Rally integrates with our other tools — delivering information, consuming information, and generally improving workflow and automation. That means people have the information they need in a way that works for them, allowing them to focus on their tasks. We’re also planning to leverage Rally as a decision-making tool for the business — helping teams to prioritize and refine user stories and drive more improvements.

How is this driving your success?

We’re breaking down silos. With the ability to collaborate in a tool that actually helps us deliver, we are strengthening relationships between business and IT. That improves understanding and ultimately drives engagement in ensuring that the best possible solutions are delivered — so we can keep increasing customer and business value.


Through effective implementation of agile solutions such as Rally Software, teams can enhance innovation, optimally balance resources, and fuel dramatic improvements in delivery. Going agile is the first step toward more impactful Value Stream management — so what are you waiting for? If you find yourself in a similar business scenario and would like to learn best practices to unlock excellence with Agile analytics, be sure to download our eBook, “How To Interpret Data from Burnup / Burndown Charts.

Collaboration Software

If it looks like a duck, swims like a duck, and quacks like a duck, then it’s probably a duck. The same is not true, sadly, for many agile project management and development initiatives.

Too often, an organization may launch something that looks like an agile program, calls itself an agile program, claims to operate like an agile program, yet really isn’t an agile program in the least.

Could your organization be fooling itself into believing that its agile practices and methodologies are the real deal? Read on to see how to detect the seven telltale signs of a fake agile in enterprise IT today.

1. Ignorance

CIOs with inadequate knowledge of agile, including its basic principles, requirements, and benefits, are almost certain to encounter fake agile in practice in their enterprises. Organizations that want to be agile, but are at complete odds with the agile philosophy, can also be fooling themselves about their agile practices, observes Jenny Herald, vice president of evangelism at Gtmhub, a provider of tools for setting and measuring enterprise goals and results.

Along with a well-defined strategy, the best way to prevent fake agile is to make sure agile is actually the right fit. Agile is often viewed as a cure-all, but the reality is that it’s not a good fit for all organizations. It requires a mindset shift, Herald notes. “The shift is not just about transitioning to a new set of practices — there must be a change in attitude and mindset around agile values and principles.”

Agile success starts at the top. “A CIO needs to ensure there’s leadership commitment, and not just from themselves but from leaders across the C-suite and the company as a whole,” Herald says. “Leaders must be committed to the enablement of agile teams.”

2. Losing the forest for the trees

When the focus shifts to granular facets of agiles, like Scrum ceremonies, instead of actual content and context, agile’s true principles are lost, says Prashant Kelker, lead partner for digital sourcing and solutions, Americas, at global technology research and advisory firm ISG.

Agility is about shipping as well as development. “Developing software using agile methodologies is not really working if one ships only twice a year,” Kelker warns, by way of example. “Agility works through frequent feedback from the market, be it internal or external.”

Too often organizations focus on going through the motions without an eye toward achieving business results. Agility is not only about adhering to a methodology or implementing particular technologies; it’s about business goals and value realization. “Insist on key results every six months that are aligned to business goals,” Kelker says.

3. Team leadership void

When a team lacks a dedicated product owner and/or Scrum master, it will struggle to implement the consistent agile practices needed to continuously improve and meet predictable delivery goals.

CIOs need to ensure they have dedicated team members, and that the product owner and Scrum master thoroughly understand their roles. “If not, make sure they receive some training and, if possible, arrange for an agile coach to provide guidance,” advises Jerry Walker, consulting director at software development advisory firm Nexient.

Walker suggests spending time with team members to view and understand how they operate. “Ask to see their team metrics,” he says. KPIs can be a good measure of agile success: Are the user stories well written, correctly sized; and how good is the acceptance criteria?

4. Forgoing feedback

Of course, metrics can also be misleading, depending on their use. One of the clearest signs of fake agile, for example, is when an IT department concentrates on team productivity KPIs rather than on value and predictable delivery accompanying each release.

If a CIO recognizes that the IT department is siloed in business goals and objectives, this is fake agile, states Patrick Guidon-Slater, director of agile transformation services for IT service management company TEKsystems. “Agile requires two-way communication, meaning that the IT department and CIO must receive and implement feedback from the customer while also sharing updates and developments,” he explains.

A CIO should also quickly integrate fresh feedback, deliver value, and then move forward to the next value-measured priority, Guidon-Slater recommends. “This can be accomplished by listening to the concerns of internal stakeholders, providing customer feedback, and ensuring that product backlog priority is aligned with the enterprise’s strategic objectives, product roadmaps, and a well-defined portfolio vision.”

5. Rigidity

Fake agile can also appear when an organization overemphasizes doing agile “correctly.” Real agilists focus on being agile, not blindly following accepted protocols to the ultimate degree, says Troy Frever, vice president of engineering at project management software firm LiquidPlanner.

Rigid rules frequently lead to ossified processes and an overall lack of agility. “If there are lots of hard and fast rules, no room for customizing to fit the context, and a ‘my way or the highway’ attitude, then there’s a good chance it’s not the real thing,” Frever says. Agile should be primarily focused on learning, feedback loops, and responding to change. “If you don’t see those things happening, something is likely wrong,” he warns.

Hire experienced trainers with great references who understand agile deeply and are also good at teaching it, Frever advises. “Understand that real agility involves a fundamentally different way of working and get buy-in from both the sponsors and the work teams.” Don’t expect the transformation to occur overnight. “After training, hire experienced coaches and/or Scrum masters that can nurture new agile teams and help them grow over time,” he says.

6. Talking the talk — and overlooking the tech

CIOs should suspect that something’s wrong when teams begin devoting more time to agile catchphrases and events than on improving customer value and experience. Enthusiasm is a powerful team motivator, but leaders need to ensure that zeal doesn’t obscure the fundamental mission.

CIOs should coach agile teams on what’s important to the organization and its clients and shift the conversation from how software is developed to obtaining feedback on the software itself, says Wing To, vice president of engineering at DevOps platform provider “Reviews too often focus on checking if something is delivered, or how it was delivered, rather than checking if it’s iteratively moving towards strategic goals and delivering what users want,” he notes.

Agile’s language and processes provide a strong and necessary foundation, To says. Yet, whenever possible, organizations should also equip their agile teams with tools designed to simplify or accelerate activities. Such products and services “are essential to enable teams to focus on the customer value and feedback,” he says.

To also recommends using automation to streamline the delivery of quality software. “For larger enterprises, tools need to be in place to facilitate planning and adapting plans across multiple team,” he adds.

7. Feeble commitment

Fake agile is frequently rooted in a lack of organizational support. Weak commitment can include a lack of understanding, missing or reluctant buy-in from senior management, or a desire to cut corners simply to save time and money. It can also be identified by a lack of collaboration, poor customer engagement, and a focus on processes rather than outcomes, says Gregory Lenzo, CFO at IBR, a personal and student loan provider.

When a project is afflicted with fake agile, the CIO should first attempt to identify the root cause of the problem, Lenzo suggests. Once the issue has been clearly identified, the CIO can then begin taking steps to resolve the problem. “This may include educating employees on agile [techniques], getting senior management to buy in, and emphasizing the importance of collaboration and customer engagement,” he explains.

Agile Development, Project Management, Software Development

How do attackers exploit applications? Simply put, they look for entry points not expected by the developer. By expecting as many potential entry points as possible, developers can build with security in mind and plan appropriate countermeasures.

This is called threat modeling. It’s an important activity in the design phase of applications, as it shapes the entire delivery pipeline. In this article, we’ll cover some basics of how to use threat modeling during development and beyond to protect cloud services.

Integrating threat modeling into the development processes

In any agile development methodology, when business teams start creating a user story, they should include security as a key requirement and appoint a security champion. Some planning factors to consider are the presence of private data, business-critical assets, confidential information, users, and critical functions. Integrating security tools in the continuous integration/continuous development (CI/CD) pipeline automates the security code review process that examines the application’s attack surface. This code review might include Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Infrastructure as a Code (IaC) scanning tools.

All these inputs should be shared with the security champion, who would then identify the potential security threats and their mitigations and add them to the user story. With this information, the developers can build in the right security controls.

This information also can help testers focus on the most critical threats. Finally, the monitoring team can build capabilities that keep a close watch on these threats. This has the added benefit of measuring the effectiveness of the security controls built by the developers.

Applying threat modeling in AWS

After the development phase, threat modeling is still an important activity. Let’s take an example of the initial access tactic from the MITRE ATT&CK framework, which addresses methods attackers use to gain access to a target network or systems. Customers may have internet-facing web applications or servers hosted in AWS cloud, which may be vulnerable to attacks like DDoS (Distributed Denial of Service), XSS (Cross-Site Scripting), or SQL injection. In addition, remote services like SSH (Secure Shell), RDP (Remote Desktop Protocol), SNMP (Simple Network Management Protocol), and SMB (Server Message Block) can be leveraged to gain unauthorized remote access.

Considering the risks, security teams should review their security architecture to ensure sufficient logging of activities, which would help identify threats.

Security teams can use the security pillar of AWS Well-Architected Framework, which will help identify any gaps in security best practices. Conducting such a self-assessment exercise will measure the security posture of the application across various security pillars – namely, Identity Access Management – to ensure there is no provision for unauthorized access, data security, networking, and infrastructure.

Although next-gen firewalls may provide some level of visibility to those who are accessing the applications from source IP, application security can be enhanced by leveraging AWS WAF and AWS CloudFront. These services would limit exposure and prevent potential exploits from reaching the subsequent layers.

Network architecture should also be assessed to apply network segmentation principles. This will reduce the impact of a cyberattack in the event one of its external applications is compromised.

As a final layer of protection against initial access tactic methods, security teams should regularly audit AWS accounts to ensure no administrator privileges are granted to AWS resources and no administrator accounts are being used for day-to-day activities.

When used throughout the process, threat modeling reduces the number of threats and vulnerabilities that the business needs to address. This way, the security team can focus on the risks that are most likely, and thus be more effective – while allowing the business to focus on truly unlocking the potential of AWS.

Author Bio


Ph: +91 9176292448


Raji Krishnamoorthy leads the AWS Security and Compliance practice at Tata Consultancy Services. Raji helps enterprises create cloud security transformation roadmap, build solutions to uplift security posture, and design policies and compliance controls to minimize business risks. Raji, along with her team, enables organizations to strengthen security around identity access management, data, applications, infrastructure, and network. With more than 19 years of experience in the IT industry, Raji has held a variety of roles at TCS which include CoE lead for Public Cloud platforms and Enterprise Collaboration Platforms.

To learn more, visit us here.

Internet Security