As a Pega lead business architect, I’ve taken many walks through the forest of digital transformation. And often, I’ve met a river impeding my progress: a lack of collaboration from information technology (IT) groups that delivered solutions using different methods than my Agile team.
I suspect that many of you have met that same river.
As I shared in a presentation at the recent Agile Alliance conference, the solution is not to stand on that river’s bank and curse it. The solution is to build a bridge over it to meet those non-Agile teams where they are.
The river is the problem
That river is, in fact, cultural friction. It's created when two groups look at the same thing and see it differently. If you can help each group see what the other sees, you’re well on your way to reducing friction.
Any of those non-Agile IT teams you’ll need to collaborate with have a culture defined along three dimensions:
- Stability
- Partnership
- Courage
The relative importance of these dimensions to the group defines its culture. If you understand that culture, you’ll understand how to work with the group.
Groups that value stability emphasize solution delivery that is stable and free from disruptions. They produce efficient, resilient IT environments, but they often lack process speed, flexibility, and a focus on innovation.
Groups that value partnership emphasize nurturing and teamwork. They contain engaged employees that provide strong customer service in an environment of openness and trust. But the cost of consensus building in a group like this is high, and these groups sometimes develop an “us versus them” mentality.
Finally, groups that value courage emphasize passion and risk-taking. They focus on growth-based goals, which means that they tend to produce good business performance along with innovative products and services. Unfortunately, these groups often take excessive, impractical risks and lack the ability to execute basic IT functions.
A bridge is the solution
Collaborating effectively with these groups involves building a metaphorical bridge to access them. Since we’re talking about culture, which means that we’re talking about people, you must start with a foundation of respect and a sincere desire to understand. Above all, assume that every group you work with has positive intentions.
Each of the team cultures I described appreciates distinct aspects of agility. Emphasizing these aspects appropriately can increase the odds that these groups will be open to experimenting with Agile techniques.
Stable cultures like that feedback and testing on Agile teams occur early and often, and they appreciate the structure that things like sprints and backlogs provide. Partnering cultures appreciate the collaboration that is inherent in Agile solution delivery. And courageous cultures love the fact that agility encourages experimentation and risk-taking.
Making use of this knowledge can do wonders as you lay the foundation of your bridge.
Build your bridge stone by stone
But your bridge needs more than a foundation. It is constructed of stones: small-scale applications of one or more techniques common to Agile teams. I’ll share five with you – they are all straightforward ideas, relatively easy to implement, with little or no cost associated with them.
Try them out. Keep the ones that work and drop the ones that don’t.
My fab five techniques:
- Provide frequent demos and releases.
Demonstrate working software early and often, and release production-ready software on short timelines. Remember that a release doesn’t have to be deployed, but it’s clean enough to be.
Frequent feedback gives stable groups confidence that things are moving in the right direction.
Frequent demos emphasize the business/IT collaboration that partnering groups value.
Frequent demos and releases show courageous groups that focus still is on the solution.
- Integrate early and often.
Integrate the parts of your solution on a regular basis – no matter what platform you’re using.
Stable groups see that frequent integration provides confidence that the new application won’t break the existing ecosystem.
Partnering groups understand that frequent integration keeps teams talking and working together.
Courageous groups view frequent integration as a safety net for experimentation.
- Use backlogs at project and iteration levels.
Develop backlogs (prioritized lists of use cases, features, epics, or user stories) for both the project as a whole and for each iteration/sprint.
Backlogs, once they’re understood, give stable groups confidence that delivery is not chaotic.
Prioritizing backlogs by business value – even technical items – appeals to partnering groups.
Backlogs provide courageous groups a terrific way to develop and document a solution’s future vision.
- Make status and progress visible.
Utilize visual tools (even simple, hand-drawn diagrams) to define the team’s work clearly and to show the team’s progress.
Stable groups appreciate that everyone can identify goals and see progress toward them.
Partnering groups like that status and progress are measured in the context of the solution, not just a platform.
Courageous groups approve of quantitative progress measures, which facilitate continuous improvement.
- Employ continuous testing.
Commit to continuous testing that involves in-iteration testers from the business. This makes testing more efficient, finding bugs faster, and fixing bugs less expensive than alternative methods.
Stable groups value quickly identifying risks to overall stability.
That testing becomes an ongoing, visible collaboration between the business and IT resonates with partnering teams.
Constantly checking assumptions provides courageous groups with yet another experimentation safety net.
These are not the only techniques that could compose a list like this, of course. If these don’t work in your situation – or if there are other techniques that you’ve found effective for you – go right ahead and try those instead.
What matters is finding ways to improve collaboration between your team and those other groups; the bridge is more important than the stones It's built with.
Recommended resources:
Here are a few of the best resources for understanding the IT cultures around us:
- “Assuming positive intent when working across teams”
Jonas Rosland; The Open Organizations Guide to IT Cultural Change, 2017
https://opensource.com/open-organization/resources/culture-change
- “IT Culture: From Glue to Grease”
Khalid Kark, Judy Pennington, Robyn Wagner Skarbek; CIO Journal, 2017
https://deloitte.wsj.com/cio/2017/05/16/it-culture-from-glue-to-grease/
Don’t forget
JOIN THE CONVERSATION on Collaboration Center
FOLLOW @PegaDeveloper on Twitter
SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS