Variety! Last weekend, my little brother flew into town to attend a Las Vegas conference, and this rare occasion gave us the perfect excuse to explore a variety of mouth-watering restaurants. One thing we heartily agreed on was the enjoyment of rotating our food styles, for example, from the local I Love Sushi rolls to Settebello pizza to the Bellagio breakfast buffet to Kabuki sushi rolls.
In a nutshell, variety is the spice of life! Similarly, before IBM acquired TRIRIGA in 2011, despite our Waterfall-style methodology, “I enjoyed a broader cross-project and cross-product perspective of the release-wide documentation changes” where I wasn’t “pigeon-holed into a project-specific Agile silo”. In other words, I experienced a more-stimulating variety of project and product challenges.
Hi, my name is Jay, and I’m an IBM TRIRIGA information developer at IBM. So if this “spicy” attitude works well with my dining choices, why can’t I apply it to my Agile team choices? Even if software developers and quality assurance testers don’t have a preference, why shouldn’t I break out of my own Agile silo and rotate my product-specific Agile teams as an information developer?
What do I mean by Agile silos?
Several months ago, after two Agile-flavored software releases, I discussed a curious “flaw” in our IBM TRIRIGA implementation of the Agile software-development methodology — Agile silos.
- Trading Waterfall silos for Agile silos (04 Dec 2013)
Although our function-specific Waterfall silos of development, quality assurance (QA), and information development (ID) were rearranged into cross-functional Agile teams that transcended the traditional functional barriers, I also felt as if the project-specific Agile teams naturally grew focused and isolated from each other.
For example, because I was the ID writer on the lease accounting team, I had a very limited need to communicate with the installation team, accessibility team, or other Agile teams. Consequently, ID issues in one Agile team that impacted the ID tasks on other Agile teams weren’t detected in the daily scrums, but only in the weekly ID-functional meetings, if they were discovered at all.
By comparison, before I was assigned to a specific Agile team, I enjoyed a broader cross-project and cross-product perspective of the release-wide documentation changes. In other words, because I was pigeon-holed into a project-specific Agile silo, I lost the continuous visibility of the “big picture”.
To be clear, I’m not necessarily saying that the sacrifices outweighed the benefits. But from my perspective, what I am saying is that the transition from a Waterfall-style to an Agile-style methodology triggered not only positive interactions but negative side-effects as well. Organizations that are planning for a similar transition should be prepared for the tradeoffs as well.
Have my thoughts changed since then?
Since then, my assessment hasn’t changed much at all. Our Agile implementation is still far from perfect. While we’ve become accustomed to Agile tools like Rational Team Concert (RTC) and Agile processes like 2-week sprint cycles and 15-minute scrum meetings, we still make Waterfall-style promises or commitments to provide a certain set of deliverables by a certain release date.
Based on my own scrum team experiences, I estimate that the IBM TRIRIGA software development methodology is still about 70% Waterfall and 30% Agile. This ratio is complicated by the fact that certain ID tools like DITA-XML editors or ID processes like language translation, cannot easily be distributed to non-ID team members or broken into sprint cycles, and thus can never truly be Agile.
Because of these various Waterfall-style pressures, the idea of a pure Agile implementation is easier said than done. On the contrary, these Waterfall-style pressures naturally perpetuate these focused-yet-isolated Agile silos. For more than one deadline, I’ve caught myself feeling the instinct or reflex to avoid questions from other teams unless it affected my current documentation project.
But here’s the most-personal side-effect of Agile silos — feeling burned out by the same product area, release after release. As I mentioned above, before IBM or Agile, “I enjoyed a broader cross-project and cross-product perspective of the release-wide documentation changes”. My concern is that if or when I’m burned out by the product area, I’m going to hate it, and I don’t want to hate it.
Should I add some Spicy rotations?
Let’s take another look at my “Agile silos” diagram. In our current IBM TRIRIGA implementation of Agile methodology, Agile team resources tend to stay within their area of expertise or experience from release to release, which makes sense. For example, “Agile Team A” will typically retain many, if not all, of the same developers, testers, and writers from release 1 to release 2 to release 3.
In terms of the “Real Estate Lease” team, its main developers and testers have been consistent. Although I’ve been its writer for the last 2 releases, I was also the writer to perform the 8-month conversion of the source content from Microsoft Word DOC to DITA-XML topics about 4 releases ago, before we began to implement Agile. That’s nearly 3 years with the Real Estate product.
Although I’ve performed other DITA conversions along the way for the Reservation, Installation, and Space-Move products, my only Agile team has been the “Real Estate Lease” team. So I’m feeling burned out by the Real Estate product and beginning to miss the cross-product interplay and variety of other IBM TRIRIGA products. I miss the refreshing scenery and spice of the “big picture”.
What’s my solution for breaking out of my own Agile silo? It sounds pretty simple — rotate my product-specific Agile teams, just like I rotate my favorite restaurants. Returning to my diagram, I would rotate from “Agile Team A” in release 1 to “Agile Team B” in release 2 to “Agile Team C” in release 3. Obviously, my rotation request must be approved. But it’s better than not requesting it.
Won’t I feel uncomfortable rotating from one Agile team to another? Maybe at first, but not nearly as uncomfortable as feeling burned out and hating the product. Luckily, my advantage is that I’m one of the original TRIRIGA technical writers from before the IBM acquisition. So I’m familiar with all of our products, except for our recent explorations in OSLC and mobile. But I’d love to learn those too.
If you think about it, I haven’t really altered the Agile methodology. I’ve only added a “spicy” element to it. Even if Waterfall-style promises or pressures prevent developers, testers, and writers from sharing role-specific tools or processes, I can still break out of my product-specific Agile silo and explore other IBM TRIRIGA products. Doesn’t that follow Agile’s cross-functional intent too?
In fact, to address this flaw in Agile methodology, it might be amusing to coin this dining-inspired cross-product and cross-team rotation as the “Spicy methodology”. I mean, it doesn’t sound any stranger than Waterfall or Lean or Agile, does it? After all, whether we’re talking about information development or favorite restaurants, I’d like to enjoy the “spice of life” variety as long as I can!
Finally, here are a few photos of my brother and myself devouring a few delicious dishes. :)