Are you familiar with the business objective of “breaking down silos”? Are you familiar with the software development methodologies of “Waterfall”, “Agile”, or “DevOps”?
If you answered “Yes” to both questions, then you probably already know that while organizational silos aren’t exclusive to development teams, the Waterfall process is the clearest sign of development silos. Meanwhile, the Agile and DevOps processes are the latest trends in breaking down these traditional development silos.
Waterfall silos
Hi, my name is Jay, and I’m an IBM TRIRIGA information developer at IBM. After two years since IBM acquired TRIRIGA, and after two Agile-flavored software releases this year, I’m now beginning to wonder whether we’ve simply traded our function-specific Waterfall silos for project-specific Agile silos.
First, how can these silos be broken down?
You might be asking, “What do you mean by Agile silos? Silos can’t be Agile. Isn’t that a contradiction in terms?” Those are good questions, but the questions also depend on the types of organizational silos that you’re discussing. So let’s rewind a bit and take a look at the concepts of focused silos, multidisciplinary teams, and polyskilled team members.
Here are several excerpts from several insightful articles about “breaking down silos”.
- Breaking down silos, what does that mean? (04 Jun 2012)
“In the business context, a silo generally represents a wall or boundary put up by an organization to keep them focused on accomplishing their goals and keeping outsiders from interfering with progress… Project based silos tend to track with the length of the project, but can also be Business Unit/Hierarchical in nature depending on the project scope and participants… Silos are built for a reason. In a typical large enterprise, there are competitions for resources and success, competing priorities and lots of irrelevant activities that are happening that can become distractions from accomplishing the goals of the teams.”
- Lean Enterprise Anti-Pattern: The Lean Waterfall (24 Oct 2013)
“If it is the engineering department and only the engineering department that implements Agile methodology, how will they determine if the requirements given to them will actually provide value to the customer? Will they talk to customer support? Will they talk to sales? Does the design successfully convey the value proposition? Has the value proposition been defined at all? Or is that left to the marketing team?… In these terms, no department, in and of itself, can provide value. It takes a multitude of disciplines.”
- Agile DevOps: Breaking down silos (12 Feb 2013)
“Consider composing each team of (at least) business analysts, customer representatives, DBAs, developers, project managers, and quality-assurance (QA) and release engineers. With a cross-functional team, you reduce ‘it’s not my job’ syndrome and other ‘walls’ that stifle communication between teams both within and across physical locations… When team members become more polyskilled and silos are dismantled, communication is improved, and bottlenecks are removed from old-world software organizations.”
In essence, focused Waterfall-style silos can be broken down by implementing Agile-style or DevOps-style multidisciplinary teams that consist of polyskilled team members. To reiterate my favorite description, the idea is to minimize the “it’s not my job” mentality.
Second, what do I mean by Agile silos?
Now let’s get back to the questions, “What do you mean by Agile silos? Isn’t that a contradiction in terms?” As an IBM TRIRIGA information developer, I can only speak for myself and my own scrum team experiences. After all, our IBM TRIRIGA software teams only began to implement the Agile methodology earlier this year. So while our Agile implementation is far from perfect, this is where the silos become curiously redefined.
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.
Agile silos
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.
Third, do I see silos within information development?
In a previous post, I distinguished an information developer from a technical writer as follows:
“I think the essential difference is that IBM technical writers primarily develop content in topic-based DITA-XML source files, not in Microsoft Word, Adobe FrameMaker, or other less-modular source files. So I presume that technical writers who develop in DITA-XML at other companies or organizations are also viewed as information developers.”
I can’t speak for the hundreds if not thousands of other software teams across IBM, but within our IBM TRIRIGA software organization, I wouldn’t be surprised if our information development (ID) team has one of the most-structured ID content review processes in the company. What do I mean by “most-structured”? Yes, you guessed it. In the spotlight of “breaking down silos”, I’m beginning to wonder if we might have one of the most-siloed ID content review processes too.
In a two-week Agile sprint, after an IBM TRIRIGA developer finishes developing the code or flow for a particular feature, the feature behavior or experience is typically reviewed by the product manager or product designer and the QA tester. Depending on the feature, the ID writer might or might not participate with a review. Nonetheless, the developer might receive reviews from 2 or 3 different roles.
Waterfall silos in ID content reviews
Meanwhile, after an IBM TRIRIGA ID writer finishes writing the content for the related DITA-XML topics or GUI tooltips, the content is typically reviewed and approved by the developer and QA tester within the Agile sprint, plus three other roles outside the sprint, namely the ID architect, ID editor, and ID code reviewer. Because ID writers deal with modular topic-based DITA-XML source files, not only must the textual content be reviewed by the ID editor for quality and consistency, but their topic-based organization and DITA-XML code must be reviewed respectively by the ID architect and ID code reviewer as well.
Unfortunately, these three reviewer roles are forced to perform separate and sequential Waterfall-style reviews outside of the Agile sprint schedule because there are so few of them to cover our Agile teams for each sprint. Nonetheless, in this case, the ID writer might receive as many as 5 separate reviews, sometimes consistent, sometimes contradictory, for the same content. Based on my experience, it’s not unusual to repeatedly describe or defend my choices 2 or 3 times for the different ID reviewers. This Waterfall-style inefficiency is what worries me.
Fourth, how can these ID silos be broken down?
Comparing the role of the ID reviewer to that of the QA tester, I had an intriguing brainstorm. But because it involves a major shift in methodology, I’m not sure how our immediate ID community would react to it.
After an IBM TRIRIGA developer finishes developing the code or flow for a particular feature, the QA tester is typically responsible for all of the elements surrounding the feature behavior or experience. For example, the lease accounting QA tester is responsible for checking not just the lease portal navigation, or the accounting calculations, or the payment field labels, but everything that’s related to the lease accounting feature. In other words, we don’t assign a separate QA tester for navigation, another for calculations, another for labels, or another for other types of elements.
Proposed QID specialists in Agile ID reviews
Similarly, instead of depending on a separate ID architect, ID editor, and ID code reviewer for each type of ID content review, we might consider a more polyskilled ID quality specialist to cover all three types of ID content reviews. Currently, we already have several ID writers who are performing the dual roles of peer editor and peer code reviewer. Coincidentally, I’m a qualified peer code reviewer who is training to be a peer architect. So the notion of cross-training a few quality ID (or QID) specialists across all three types of reviews is not impossible.
Just as our IBM TRIRIGA software organization implemented Agile-style multidisciplinary teams for its development process, it’s not impossible for our ID team to follow a similar path for its content review process. Just as software developers have their QA counterparts, ID writers might benefit with cross-trained QID counterparts. After all, the idea is to break down the Waterfall-style silos and minimize the “it’s not my job” mentality, right?
Do I have an update?
Nearly four months after trading Waterfall silos, I was trading Agile silos for Spicy rotations!
Kabuki Japanese Restaurant
Related articles
- Blog: The myth of agile empowerment (gamasutra.com)
- 9 Low-Tech Tips for Agile Project Management (mxmossman.blogspot.com)
- Lean Startup in the Enterprise Anti-Pattern: The Lean Waterfall (grasshopperherder.com)
- Understanding the Differences Between Agile and Waterfall (codeyourself.wordpress.com)
jay.manaloto.ibm 
Hi Jay. Could you explain a little more about (the differences between) the three ID roles you mention: architect, editor and code reviewer?
Hi Paul, no problem. I can only speak for my IBM TRIRIGA ID team since there are probably hundreds of other IBM ID teams who might have slightly different processes or combine some of these roles.
But essentially, our ID architect (or information architect) checks the high-level TOC structure of our DITA-XML maps. In the lower levels, our ID code reviewer checks the tags within our DITA-XML maps and topics. Meanwhile, our ID editor checks not only grammar and spelling in our topics, but also IBM styles and GUI strategies like embedded assistance and progressive disclosure in our application labels and tooltips. So the roles are rather specialized.
Finally, I should also mention that the ID writer is also responsible for running the automated Acrolinx tool to clean up the more common grammar, spelling, and style issues before they reach the ID editor. So I think that covers everything. I hope this helps!