& Continuous Learning

One of the biggest hindrances to progress in software projects is bureaucracy. Rigorous processes that must be followed unswervingly, deliverables changing hands between independent groups and required approvals – hand-offs, sign-offs, and stand-offs – all get in the way of software projects making valuable progress. So how would you change that?

Most traditional project teams have members that are spread throughout various departments within the company. This approach is supported by the organizational theory of segregating work by expertise. Managers believe that it is more efficient to have staff do one thing and do it on multiple projects at one time. The problem with this is that it increases difficulty in communication and collaboration. And it requires staff to constantly task switch between projects. Add to that multiple sponsors all vying for their projects to be top priority and it makes for a difficult situation.

This works for many companies because they follow a waterfall approach of one discipline finishing their task before the next discipline starts theirs. This approach is facilitated by formal documents, required approvals, and rigid processes. As David Ingram (n.d.) points out, “Segregation of related organizational duties adds accountability to an organization by allowing different people to inspect the component parts of a multi-step process of system.” However, today’s business climate requires a much more agile process to be competitive.

With an agile approach, team members from various disciplines are co-located to form cross-functional teams.  Programmers, business analysts, quality assurance staff, database administrators, and system administrators all sit together with their project team. They all work on each phase of the project together rather than on only their part.  The proximity allows everyone to share his or her perspective. Communication and collaboration are improved, as they are all involved in the discussions rather than hearing about them after the fact.  The increased involvement greatly reduces the amount of misunderstanding.

By placing everyone together, there is no need to write lengthy formal documents, notify other team members, and wait for a response.  Instead, use note cards placed on a wall where the team is located. That way, rather than having to open a document or log into a project management tool, you can look at the wall to see the project's status. Not only does this help the team, but also anyone else that visits the team is immediately aware of the project status. The greater visibility provides a valuable feedback and motivation mechanism since the team’s progress is visible to everyone.

Note cards also intentionally limit what can be written down. By putting key words on note cards, they become starting points for conversations; conversely, in a waterfall process one would attempt to write everything down and hope the reader would interpret it correctly. This works because face-to-face is a much more effective means of communication.

An example of how well cross-functional teams work can be found right in Des Moines. Danenhauer (2013) explained how his team at John Deere is composed of 1 product owner, 6 developers, 1 or 2 technical leads, and 2 testers, with everyone on the team reporting to the same supervisor. Danenhauer, who is an automation test engineer, has become comfortable pairing with the developers on the team. He cited multiple benefits; such as having tests that can be understood by the users, creating requirements documents that are executable, and identifying conditions that had not yet been documented.  Ensuring that everyone understood the acceptance criteria was another benefit he discussed.

The transition from traditional project teams to agile project teams is not easy. But you can take small steps to make the transition less eventful.  Start by engaging more with other team members. Rather than make assumptions, start a conversation with your colleagues to make sure everyone has the same understanding.

Another easy thing to do is to start making the team’s progress more visible. Stay low tech and post note cards of the stories you are working on where others can see them. Use sticky notes to keep track of tasks that need done for the stories.

Eventually, if your organization wants to improve, your changes will start propagating to other team members, and even to other teams!

References

Danenhauer, Brian. (March 6, 2013).  Agile Test Automation.  Presented at Deep Dive Into Agile, joint meeting of VIVIT, DAQAA, and Agile Iowa.

Ingram, David. (n.d.). Segregation of Related Organization Duties.