As I discussed in The Agile Stimulus Package, there are key drivers or influencers that lead you towards an agile approach to work. In a subsequent post, I outlined three different approaches to work that agile teams use in actual practice.
In this post, I’d like to tackle a challenge that I’ve been encountering with greater frequency in recent years: How do we beneficially apply agile principles and practices to non-software knowledge work?
My first foray into the non-software agile realm was with a marketing group that had split into three different teams. Within minutes of engaging with this group I learned that they had certain assumptions about agility and what my role was going to be.
Here’s a condensed version of our initial conversation:
“It’s great that you’re interested in being agile!” I began. “Tell me about your work!”
“No,” the manager of the group replied, “you just need to tell us about agile.”
“Well,” I countered, “there are options, and it’s difficult to know what would be useful without a little background.”
“Just walk us through it and we’ll figure out how to apply it.”
The situation was clear – in their eyes I was a Subject Matter Expert whose knowledge they could extract and apply to their circumstances.
Even though I strongly felt that we weren’t getting off on the right foot, I ended up “telling them about agile” by walking through the Scrum Framework. My gambit was that any time that we spent talking about agility would open the door for them to share more about their work and needs, creating the opportunity more informed discussions.
During the Scrum walk-through, they kept saying things along the lines of, “I don’t see how that won’t help us” and, “We’re already doing that.” While their initial enthusiasm was waning, they became more receptive to my, “Tell me about your work” queries as we continued.
The good news was that they had already re-organized to form highly collaborative teams. We quickly validated that the teams were correctly formed in terms of closely aligning individuals who needed to regularly collaborate on developing specific marketing assets.
As we continued to explore the specifics of their situation, a key issue emerged. As a part of forming highly collaborative teams, they emphasized the ability for each team to focus. In practice, this translated to teams being very disciplined about protecting themselves from outside distractions. While this isn’t necessarily a bad idea, they were experiencing pain as a result.
The missing ingredient was something they had stopped doing in their quest to “be agile.” While the teams could independently create marketing assets, there was a need to coordinate and synchronize the collective efforts of the teams into marketing campaigns.
In their pursuit to keep each team independent and focused (agile, as they interpreted it), they ended up introducing unnecessary overhead and delays to address the inter-dependencies that existed between teams by generating additional artifacts to share between teams to help coordinate activities. And between the time spent creating, updating, and passing these artifacts back and forth they had managed to increase the total delivery time of their marketing campaigns.
They needed to support the value of, “Individuals and interactions over processes and tools” along with a key principle that guides our behavior in support of this value, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
I’m sure you can guess where we went next!
Yes, a simple, lightweight scaling mechanism known as the Scrum of Scrums paid off handsomely. They had been doing this in the past (calling it a sync. meeting), and once we talked about what the Scrum of Scrums was all about, they immediately recognized the benefit. The surprise for the marketing group was that this was considered “agile,” but once they re-instituted this practice, all the pieces fell into place and they obtained the results they were looking for.
I’ll dive into additional aspects of applying agile principles and practices to non-software work in a future post.
