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.
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.”
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 Digital.ai. “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