BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
In one form or another, organizational silos have always dotted the IT landscape. And for as long as anyone can remember, a siloed approach to technology management has gotten organizations into trouble. Enterprise program managers know better than to build up organizational siloes on purpose, but new siloes seem be forming nonetheless.
Farmers use silos to separate and store different types of grain, and that's a good thing. But when silos appear within an organization— separating employees into seemingly self-contained and independent groups—poor performance inevitably ensues. The left hand doesn't know what the right hand is doing; effort is duplicated; people work at cross-purposes; productivity and morale fall. As a result, achieving business goals is much more difficult.
This problem is not a new one for software pros. They know what happens when separate groups for requirements, development, test, and production operate in relative isolation, interacting only at handoff points. Business stakeholders fail to effectively communicate what they want the software to do. Developers write code that doesn't meet end user needs. Testers, in turn, test the wrong set of requirements, and problems proliferate all the way down the line.
For most software organizations, the dangers of siloed development are well-understood. Agile approaches can help break down those barriers--albeit bit by bit. But now there is something new to worry about. A new kind of organizational silo is emerging: Separate teams for Web, desktop and mobile projects.
In a recent conversation, development expert Stephen Forte explained why this is a bad idea and offered advice on how to forestall a silo development approach from taking hold. In this edition of Quality Time, I share some highlights of my conversation with Forte.
One team, no silos
Business or IT silos of any sort cause problems. But separate dev teams for Web, desktop, and mobile have a particularly serious consequence, said Forte, chief strategy officer for Telerik, which sells mobile development software. "The stakes are much higher, and you have to treat Web, desktop and mobile as a single entity," he told me.
When teams focus on mobile from the get go, the "mobile first" mindset takes hold, and all they can think about is getting the app out there as quickly as possible. What should they focus on instead? The user's experience with the software -- no matter on which device the application will run.
Favorite apps from the user experience standpoint
Zeroing in on the user experience is a scary undertaking for enterprise development teams, which traditionally have not been asked to approach projects that way. To calm fears and generate ideas, Forte recommends this technique. Kick off the development project by asking team members which of the consumer applications they use offers the best user experience.
Forte likes Amazon because he can interact with its content as he moves from device to device. He starts watching a show on his Kindle, and later he can pick up where he left off on his phone.
The process of talking about good and bad user experiences from a consumer standpoint is helpful because a new mindset starts to take hold, Forte said. "Developers start thinking 'how can I build a great user experience into the application?'"
Look to Agile as a model
The best model for incorporating user experience expertise into a development team is Agile, Forte said. Agile has created a foundation for success through familiarizing developers with cross functional teams, where each member performs a range of functions. In addition, Agile teams are accustomed to incorporating experts on an as-needed basis.
This offers a way to get started with user experience -focused development. Don't let organizational silos – where hand-off points are often the only point of communication – build up within your organization. "Handoffs are the death knell for productivity," said Forte.
Is your organization taking a unified approach to application development? Are you actually finding success with separate teams for separate projects? Let me know what you think.