It’s amazing how quickly things get transmitted throughout the office, from gossip to Internet memes to the common cold. In recent years, something else has started to spread from department to department at an accelerated pace—something almost as contagious and much more beneficial. Something, in fact, that helps teams of all shapes and sizes tremendously improve their business outcomes.
I’m talking about Agile work methodology.
This work management approach has roots in the IT world going back to the 1990s, leading to the creation of a manifesto in 2001. Since then, more and more teams have discovered the advantages of Agile, particularly those teams focused around marketing and product development. (The Agile Marketing Manifesto was written in 2012.)
The advantages of Agile include, among many others:
- Faster time to market
- Greater adaptability and innovation
- Vast productivity improvements
- More customer-centric products
- The ability to stay competitive in a cutthroat industry
As neighbouring business units see developers, marketers, and product teams enjoying these benefits, they naturally want in on the secret. Who better to teach them the ropes than IT and development teams who have been immersed in Agile for decades?
If IT departments will be willing to lend their expertise, they can greatly elevate the success of the entire company by mentoring other teams and sharing best practices to ensure a smooth and successful transition.
However, this effort doesn’t have to take hours of precious time away from other pressing priorities. Here are four bits of advice that will help IT professionals be useful to other departments who are showing interest in catching the Agile bug—without overwhelming either team.
Get on the same page
When another team approaches you for some advice about Agile, don’t assume they know what it is. Start with a quick vocabulary lesson. Is the other team interested in “agile” or “Agile”? In other words, do they just want to be more nimble and adaptable when new opportunities or challenges arise, or are they interested in learning an established methodology with a defined set of principles and practices? If you’re talking about one and they’re talking about the other, the conversation will go nowhere.
Also, make sure to ask the other team about their motivations. What is driving their interest in Agile work processes? They might tell you it was a directive from a boss, or that their team is struggling with productivity, or that they’ve just heard good things about it. Understanding the other team’s goals—and the urgency surrounding them—will help you know what to recommend.
Take baby steps
While you may be deeply immersed in all of the nuanced practices of Agile, having fully bought in to the philosophy, a team that’s new to the idea needs a way to try it on for size. Remember that Agile is not an all-or-nothing proposition. Rigidity in practice or definition runs counter to the point of the whole endeavor.
A centralized Kanban board with visual queues to help organize and prioritize tasks is a great place to start. It costs nothing more than a white board and a stash of sticky notes, plus a willingness to experiment. Set the team up for a quick, easy win that allows them to see an immediate uptick in productivity and visibility, and they’ll have a great foundation to build upon—plus the enthusiasm to take the next steps.
Share your tools
Perhaps the quickest, easiest way to assist another team on their Agile journey is to share the tech tools you use to support your efforts. If you onboarded a particular software solution, hook the other team up with the implementation specialist who helped you design your process.
On top of that, share the tricks and tools you use to measure productivity and through-put, explaining how you arrive at the data that helps you demonstrate ROI and justify resource allocations. You’ve likely become an expert at these things, armed with years of visibility into data and analytics that other teams have lacked. Show marketers and product development teams how you’ve learned to demonstrate business value and influence business decisions, and you’ll give them the ability to help raise the profile of the entire organisation, which ultimately benefits your team, too.
Don’t force it
Say you hired a certified Scrum master who was professionally trained and follows the framework to the letter, and it works perfectly for your needs. That’s great for you, but it doesn’t mean the same approach will work for the department upstairs. Never force your favorite solution on another team without first understanding their needs. Listen as much as you talk.
You may find out that a strictly dogmatic Agile approach won’t be the best fit for the other team—or that Agile in general isn’t going to work for them right now. It’s better to find out early that the other team needs to make a few organisational changes before taking the Agile plunge than to waste your time (and theirs) on a failed implementation.
Catching the Agile Bug
The Agile approach is getting more and more infectious, spreading from IT teams to marketing to product development and more. As the resident Agile authorities, IT leaders are positioned to offer useful guidance that can pave the way for a smooth transition—one that will benefit everyone involved. After all, when productivity, agility, customer-centricity, visibility, and collaboration increase within teams and across departments, the entire organisation reaps the rewards.
