How to foster collaboration in software development

Go back to the drawing board

Collaboration is working with someone to produce or create something. In the classic app-dev approach, professionals all too often end up working against each other to create something. In this process, the tester and the programmer are at odds with each other, even though the two roles are often aligned in product and project management.

For example, a former colleague used to roam the halls and tell us to "know your role; be your role," and wrote the slogan on whiteboards. The implication was that, if a role fails, it should be allowed to fail, and senior management would then take corrective action. But this isn't really how systems work. Dedicated roles that don't respond to team needs become single points of failure unnecessarily. So, when I saw the manager's huge writing on the whiteboard, I wrote in smaller letters, "See what the team needs. Do that."

Back then, I was a programmer in a team without a tester role. The manager should have recognized that analysts had different skills and should have looked for ways to use our skills in a complementary way. On this team, we covertly allowed our skills to overlap and even trained each other a bit. If an analyst was sick, I could fill in a little bit so the project could still progress that day.

In some other teams I worked with, testers learned enough coding to create queries or do bug fixes. Some database administrators learned a little code; all of us learned a little SQL and so on. In this approach, everyone sought to prevent problems from escaping the team level, and we all worked toward a shared goal. Our objective was to put working software in the hands of customers -- not simply accomplish our own individual tasks.

Start with the end

In Stephen Covey's The 7 Habits of Highly Effective People, he recommended that you envision your own funeral. Who do you want to be there, and what do you want them to say? From there, you work backward to create a life worthy of the legacy you want to leave.

Not everyone considers a software project to be existential, but teams can still borrow this funerary framework to better shape the aims for the granular aspects of an application, as well as the overall vision. Many projects fail to establish either, and as a result, the software misses the mark. For example, the finished software might not correctly handle rounding or error messages, or it could have a clunky UI -- all of which means rework.

There are easy steps to encourage collaboration in software development. Before the project begins, create a shared understanding of what the software should do. Even if nobody writes anything down, the conversation will improve how well the first version of the software corresponds to its intended purpose -- plus reduce unnecessary arguments after that initial build. The principles of context-driven testing support this approach and treat the product as the answer to a problem.

At the feature level, teams can create concrete acceptance criteria that are more detailed than something like, "The user can log in." Brian Marick, co-author of the Agile Manifesto, wrote: "The focus of my work is the power that concrete examples have to cut through the Gordian Knot of misunderstanding that ties up so many software projects." Once the project starts, people need to talk to each other even more.

Keep up the chatter

The Scrum framework recommends that every team member answer these three questions every day:

• What did you do yesterday?
• What are you doing today?
• What are you blocked by?

The answers to these questions establish who should be accountable for what, as staff members who commit to things are then obligated to complete them. But there's a greater purpose to these questions: to accelerate the sprint. All team members state their answers, and occasionally, someone responds in a way that sparks a conversation and potentially solves a problem. For example, a confusing interface for one worker is an easy fix for another, or a daunting test data setup for one engineer leads to a quick group project to automate the task.

However, it can be a challenge to achieve this level of knowledge sharing, reverse engineering and collaboration in software development.

Break down barriers to collaboration

A performance-obsessed culture in the workplace is often the first barrier to collaboration. People worry about getting their own work done to garner top standing for promotions and other accolades. A competitive environment provides workers with a negative incentive against sharing or helping their peers.

Even if management actively promotes collaboration in software development teams, you still must get workers to shift mindsets; at first, some might still spend more time on looking smart than moving a project forward. There need to be incentives to work together, without going too far as to encourage groupthink. If critical thinking falls by the wayside, collaboration that has been fostered could end up being used for software that doesn't really solve a problem or meet customers' needs.

Keep the end user happy

With a methodology such as extreme programming (XP), which has more rigorous programming standards and a quicker release schedule than Scrum, it's important to orient a project team to be responsive to customer feedback. If possible, XP adherents even have a customer on-site with the project team. Ideally, this person is engaged with the daily work of the project.

For external customers, a company might need to designate a product owner who surveys end users and ascertains what they want in the product. With internal customers, the sponsoring organization will lose a person for the duration of the project -- and the risk is that this organization chooses someone fairly expendable to send to work with the developers.

In this model, without an engaged customer, the software team is figuratively a ship without a rudder. And it is then likely that organizations take the application unintentionally -- and unknowingly -- down the wrong fork in the river.

Without shared understanding, teams cannot build a software product that everyone expects. Once the software team reaches the shore -- to continue the boating metaphor -- which is the end of a long process, the customer shakes his head and explains how the team did it wrong, and a new feedback loop begins. It all boils down to this: Don't debate; collaborate.