Effective Development Teams, Part II

By David Florey, principal software architect, Sage Software

Editor’s note: This is the first of a three-part series on Effective Development Teams. The first and third articles can both be found online.

Productively gathering and communicating requirements is no simple feat. It requires hard work, diligence and, most important, effective communication. Problems in this area may seem small at first, but can grow to become painful and costly. In my experience, the most troublesome among them stem from a reliance on anecdotal or technically driven requirements, an overemphasis on process or tools, a lack of requirement prioritization or, simply, “dropping the baton.”

Anecdotal or technically driven requirements
Ineffective development teams operate by rumor. Someone may go to a conference and overhear a user speak of distaste for the data-entry form for the XYZ application and take that information to the product manager. Without any further research the product manager tells the team that the data-entry form needs to change. Someone on the team, perhaps a developer, suggests that the form be rewritten the form in .NET, or another preferred approach. The rest of the team agrees and off they go, wasting everyone’s time.

Effective development teams operate by fact. Rumors are immediately confirmed with a solid cross section of users and are questioned by the rest of the team. Feature change requests or enhancements will first arrive through odd or interesting channels such as customer support or cocktail parties, and there may actually be some truth to the requests. With this information in hand, an effective product manager solicits information from a good cross-section of users, prioritizes this feature with all other requested features, and uses active listening techniques to ensure he/she heard the users correctly.

The effective product manager immerses him/herself into the users’ world. He/she visits a cross-section of users on site, watches them work, and asks questions while taking copious notes.

Returning to the rest of his team, the effective product manager discusses the issues he/she discovered with an effective developer, and the two discover a number of potential solutions for the highest-priority issues. In short order, the product manager provides the cross-section of users with a prototype (paper or digital) that depicts a potential solution and validates that solution against what he/she heard the users say. The effective product team has actively listened to users: first hearing the users and then telling the users what was heard.

Overemphasis on process or tools
Far too often I’ve seen teams get caught up in the minutia of policy, tools and details. When you observe that the task of creating a User Requirements Document (URD) becomes more important than actually speak with the people who will read it and attempt to understand it, you are working on an ineffective team. Additionally, detailing out too much, too soon in either a functional specification or URD can weigh a team down in unnecessary detail instead of enabling them to grasp the big picture and focus on the details only as necessary.

Effective development teams focus on proper communication and understanding of requirements, not on how requirements are recorded or how quickly they can crank out a requirements document. If the people reading the requirements document cannot understand it, then the people producing it have failed. Communication of requirements should be done in dialog and workshops, not just through read-and-review mechanisms. By the time communication is complete, the requirements document should become an afterthought, an anticlimactic document that no one on the team really needs to read because the information is so well understood by the team. Obviously, writing this information down provides a good reference, but it is far less important than the communication itself.

Lack of requirements prioritization
Finally, ineffective teams assume that all requirements and features are created equal, and would therefore rank all requirements as essential. What’s worse, a product manager might not know the ranking of requirements and so will arbitrarily state one requirement as essential and another as optional.

Effective development teams strive to completely understand the user requirements and how the user would rank one against another. Kano Surveys are a perfect way to do this, with such question pairs as How would you feel if the revenue report displayed quickly? and then later in the survey, How would you feel if the revenue report displayed slowly?

Users answer from a set of multiple choices and, based on their answers, a given feature is ranked as one of the following:

• Attractive. Slight functional improvements will dramatically increase user satisfaction, but lack of the feature won’t drive users away (e.g., drag and drop, multilevel undo).
• One-dimensional. An increase in functionality will drive a similar increase in satisfaction (e.g., performance enhancements).
• Must-be. No amount of functional improvement will satisfy the user, but even the slightest deficiency will anger the user (e.g., accurate data display).

Kano surveys, however, are just a tool. The effective development team may use them or any other tool to find the right balance of features to offer the target cross section of users.

Dropping the baton
Ineffective teams are either not given enough time or simply do not care much about a successful hand-off. Instead of being a resource of information, the product manager dumps every piece of information he/she can into a requirements document, hands it off to the team and busies him/herself with the next project or feature. The software developers and test engineers read the requirements document alone in their respective cubicles and apply their own interpretations to the requirements, ultimately ending up with the wrong solution and the wrong way to test it.

On the other hand, as the product manager of the effective team gathers requirements from the user and ensures that the rest of the team understands those requirements through workshops (i.e. productive meetings in which all involved are dedicated to achieving a goal before they leave the room) and dialogues, the software developers begin to formulate ideas of a solution.

In an effort of active listening, the software developers begin to validate their solution against the requirements by running workshops that include the entire team with the goal of finding the best solution to meet the user’s needs.

Figure 1 - Effective Development Team Timeline. “Solution validation” falls in the timeline of software development. Developers begin to think about and refine the solution during the requirements gathering phase and continue to refine it during development.

Understanding the solution
As the influence of the product manager wanes, the influence of the developer gains momentum. The lead developer’s job is to invent a creative solution to meet users’ needs, ensuring that the solution is easy to maintain, performs well, uses as much existing technology as possible (i.e., is fast to market), and is easy to use.

Ineffective development teams typically miss the mark because they fail to validate the solution with the rest of the team or fail to understand the details behind the solution before they estimate or build it.

Failure to validate the solution with the rest of the team
If any point in this article is thematic, it is that everyone on the team should practice active listening. Far too often, I’ve seen requirements documents thrown over the wall to developers, who interpret the needs poorly and then generate specifications that are tossed to test engineers, who generate inadequate test plans based on the requirements document and specification. These ineffective development teams churn out software that barely addresses users’ needs and are tested against a set of test cases that scratch only the surface of the solution. This leads to a poorly conceived, bug-ridden solution, a wasted investment, and unhappy customers who will think twice before buying your software again.

Effective development teams include a development lead who works with the product manager to create a solution to meet the users’ needs. That lead is then responsible for communicating and leading the validation effort for the solution. Ideally, emotions are set aside in such meetings and everyone in the room is focused on determining the best solution for the users. This helps to ensure not only that requirements are interpreted in the same way from test engineer to developer to technical writer, but also that the functional specification, that is, the solution, is also consistently interpreted.

Failure to understand the solution details
Ultimately, before development work begins in earnest, a time estimate should be given so that those concerned with marketing, resource allocation and scheduling have an idea when the product will be ready. To provide this estimate, development teams must fully understand the details of the solution to ensure that functionality and design approaches and strategies are both understood.

Ineffective development teams exhibit two primary weaknesses when it comes to this stage in the process. First, they don’t bother to break down the work, argue points, and ultimately come out with a time estimate and a plan for completing the work. Second, they forget that the time estimate can and should be adjusted as they progress through development.

By contrast, effective development teams follow these practices:

• They analyze the solution and break the work down into a hierarchical structure along feature lines.
• They use white-boarding techniques (rousing discussions with dry-erase pens) to work out the finer design and functional strategies.
• They use wideband Delphi estimation techniques and adhere to the code of ethics therein to provide quality time estimates.
• They stick to a plan that (1) works with test engineers by delivering vertical slices of functionality to the test engineers on a periodic schedule and (2) is fluid and involves user loopback points.

By using a work breakdown structure, such developers miss very little in the design and functionality of the product. Ideally, the developers also break the project down in a workshop. If there is only one developer on the team, he/she solicits help from another developer to ensure nothing is missed. Checks and balances are an important ingredient to an effective development team.

White-boarding involves nothing more than a discussion of the finer points between two developers over a whiteboard. This is preferred over stuffy design documents or UML diagrams for this phase of the process (though the stuffy design documents are quite useful once ideas are solidified).

Wide-band Delphi estimation is a process that involves at least three individuals: a moderator and two estimators. The three agree on a WBS and then the two estimators estimate the work separately. The estimates are compiled by the moderator, who then walks through each estimated item, asking the estimators to discuss any items whose estimate varies greatly among the estimators. Anonymity is paramount during the discussion to prevent coercion or strong-arm tactics. Discussion is meant to ensure everyone is estimating the same thing. Once all of the points are discussed, the process iterates until the team agrees that the numbers cannot be brought closer to one another or until they reach a certain threshold.

The key point in this process, of course, is ensuring that everyone is estimating the same thing, interpreting the solution in the same way.

In my experience, every effective development team generates a detailed plan before they begin coding. This plan is a high-level agreement between developers and test engineers and is the starting point that ensures everyone is on the same page. The plan typically identifies not just a work breakdown, but the sequencing of features or functionality that will flow from development through the test engineers and (in some cases) to users for loopback checks (to ensure everyone remains on the right path).

The features identified within the plan are always testable and are typically vertical slices of functionality that include the data layer/database work, business logic and UI for a given feature. These features can be delivered in parallel or sequentially depending on how many resources are available and the dependencies amongst the features.

About the author
David Florey is a principal software architect at Sage Software in Beaverton, where he is focused on using the latest technology and practical development methods to deliver high-quality software to Sage customers. He has more than 12 years of experience building software and working with effective development teams. While hard at work with Sage, he is also working on his master’s degree in computer science at Portland State University. He can be contacted at dzflorey@yahoo.com.