Effective Development Teams, Part III
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 second articles can both be found online.
In this final part of the three-part series on effective development teams, we will dive into an area that I feel is one of the most important and many times the most neglected: building the software. Using the same format introduced in the second article in this series (on gathering and communicating requirements), I will discuss the many issues that can occur while building the software and how effective development teams work to stay on track.
Staying on the same page while building the solution
Once planning is complete, the majority of the user requirements are understood, and the solution has been validated and estimated, work can begin. The troubles I’ve seen at this point are all over the map, but the main trouble points are when team members fail to stick to the plan, developers get way ahead of test engineers, the team lacks value checks or user loopbacks, and the functional specification is frozen, even with problems.
Failure to stick to the plan
I’ve seen a number of ineffective development teams generate a plan (because they had to) and then completely ignore it (because it slows them down). Instead, the developers code as much as they can, finally realize that they didn’t plan very well but time is ticking away, and so deliver a late, unfinished and untestable product to the test engineers.
The test engineers then attempt to verify the functionality based on the “plan” and realize that it’s not possible, at least not until the next drop from development. The plan busted, the test engineers perform some ad hoc testing and record a number of defects in the product. Developers ignore these defects and continue to code new features as fast as they can, because they’re behind schedule according to their inadequate plan.
Effective developers telegraph their next move before they make it. Before writing code, they sit down with the test engineers and discuss what the next 15 days (or so) will bring. They talk about what feature they will deliver and provide a confident (re)estimate for that feature. They cover, in depth, how the feature may be slightly differ from what they thought, and why; design work for the feature; and other elements of the feature, such as the work the technical writer will do to generate help information.
The plan, therefore, is treated as a high-level framework, the details of which are determined just before work begins on a feature. Many teams then find it useful to record this discussion in some sort of “feature document” that captures the results of the workshop.
Developers get way ahead of test engineers
Ineffective development teams include test-engineering resources that are not dedicated to the team. Instead they are pulled in a number of different directions and have little time to do their core job: testing the developing product. Because of this, developers may continue coding way beyond the capacity of the test engineers, leaving them in a state of panic and worry. This leads to a lot of missed defects in the product, costing time and money to make right.
To ensure that this doesn’t happen, effective development teams put test engineers in charge of the development. Whereas product managers drive the requirements gathering phase and developers drive the solution validation phase, test engineers drive the development effort, by pulling the product through rather than allow developers to push it through. Effective development teams have dedicated test engineers who have the power to stop development on new features to ensure that defects found in older features are corrected. This helps to ensure that developers and test engineers stay on the same page, and it makes fixing bugs easier for developers (since they would have coded the bug very recently). This also improves the quality of the overall product as defects are found and fixed earlier rather than getting buried under mounds of code and eventually shipped to unhappy users.
Lack of value checks or user loopbacks
Even at this stage users are still “in charge.” It is vital to loop back frequently with them to ensure the evolving solution progressively meets their needs. Ineffective development teams believe that all that up-front work catches everything. Effective development teams know better: while they do a tremendous job in up-front requirements analysis, they still know that they probably missed some key points.
The functional specification is frozen, even with problems
This brings me to my final point. Ineffective teams believe that work can be frozen. They feel that if the functional specification or requirement is not frozen, features will come creeping in.
While this is a valid concern, effective development teams understand that it is not features that come creeping in, but a deeper understanding of the requirements and solution. At the beginning of any project, an effective development team will do its best to understand the needs of the users and devise a solution to meet those needs. This solution and the understanding of needs, however, will only reach a certain level of detail. It is not until the product is being built that a deeper level of understanding is reached. Therefore it is important to allow for change in the software’s functionality and at the same time beware of the costs of doing so.
Conclusion
An effective software development team is aware of the tools and processes at its disposal, but it doesn’t get caught up in the hype. It remains goal-oriented and understands the goals at each phase of the basic software development process: understanding user needs, turning those needs into a solution, validating the solution, and staying on the same page with one other and with users as the solution is built.
Active listening should be employed at every stage of development. Product managers and developers must use it to validate solution ideas with the users and their needs. Test engineers must use it to validate test cases against the proposed solution.
Checks and balances are also an important element of effective development teams. Each person understands his/her own role and how important it is that the other roles of the team are filled by other individuals. This provides the right environment for complete communication of needs and solutions.
Finally, and most important, are the many months from the time everyone understands the needs and solution to the time the product is shipped. Effective development teams generate a detailed plan and are diligent to stay on the same page throughout the development of the solution. This diligence keeps all team members alert and mindful of the tasks at hand, ensuring a higher-quality product in the end.
References
Karl E. Wiegers, “Stop Promising Miracles”, http://www.processimpact.com/articles/delphi.html
Charles Berger, Robert Blauth, David Boger, Christopher Bolster, Gary Burchill, William DuMouchel, Fred Pouliot, Reinhart Richter, Allan Rubinoff, Diane Shen, Mike Timko and David Walden, “Kano’s Methods for Understanding Customer-defined Quality”, Center for Quality Management Journal Volume 2 Number 4, Fall 1993
Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherland, “SCRUM: An extension pattern language for hyperproductive software development”, jeffsutherland.com/scrum/scrum_plop.pdf
Jeff Sutherland, “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies”, Cutter IT Journal, Volume 14 Number 12, December 2001
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.
|
