- Rapid Development: Taming Wild Software Schedules
- Preface
- I. EFFICIENT DEVELOPMENT
- 1. Welcome to Rapid Development
- 2. Rapid-Development Strategy
- 3. Classic Mistakes
- 4. Software-Development Fundamentals
- 5. Risk Management
- II. RAPID DEVELOPMENT
- 6. Core Issues in Rapid Development
- 7. Lifecycle Planning
- 8. Estimation
- The Software-Estimation Story
- Estimation-Process Overview
- Size Estimation
- Effort Estimation
- Schedule Estimation
- Estimate Refinement
- Further Reading
- 9. Scheduling
- 10. Customer-Oriented Development
- 11. Motivation
- 12. Teamwork
- Software Uses of Teamwork
- Teamwork's Importance to Rapid Development
- Creating a High-Performance Team
- Shared, Elevating Vision or Goal
- Sense of Team Identity
- Results-Driven Structure
- Competent Team Members
- Commitment to the Team
- Mutual Trust
- Interdependence Among Members
- Effective Communication
- Sense of Autonomy
- Sense of Empowerment
- Small Team Size
- High Level of Enjoyment
- How to Manage a High-Performance Team
- Why Teams Fail
- Long-Term Teambuilding
- Summary of Teamwork Guidelines
- Further Reading
- 13. Team Structure
- 14. Feature-Set Control
- 15. Productivity Tools
- 16. Project Recovery
- III. BEST PRACTICES
- Introduction to Best Practices
- 17. Change Board
- 18. Daily Build and Smoke Test
- Using the Daily Build and Smoke Test
- Managing the Risks of the Daily Build and Smoke Test
- Side Effects of the Daily Build and Smoke Test
- The Daily Build and Smoke Test's Interactions with Other Practices
- The Bottom Line on the Daily Build and Smoke Test
- Keys to Success in Using the Daily Build and Smoke Test
- Further Reading
- 19. Designing for Change
- 20. Evolutionary Delivery
- 21. Evolutionary Prototyping
- 22. Goal Setting
- 23. Inspections
- 24. Joint Application Development (JAD)
- 25. Lifecycle Model Selection
- 26. Measurement
- 27. Miniature Milestones
- 28. Outsourcing
- 29. Principled Negotiation
- 30. Productivity Environments
- 31. Rapid-Development Languages (RDLs)
- 32. Requirements Scrubbing
- 33. Reuse
- 34. Signing Up
- 35. Spiral Lifecycle Model
- 36. Staged Delivery
- 37. Theory-W Management
- 38. Throwaway Prototyping
- 39. Timebox Development
- 40. Tools Group
- 41. Top-10 Risks List
- 42. User-Interface Prototyping
- Using User-Interface Prototyping
- Managing the Risks of User-Interface Prototyping
- Side Effects of User-Interface Prototyping
- User-Interface Prototyping's Interactions with Other Practices
- The Bottom Line on User-Interface Prototyping
- Keys to Success in Using User-Interface Prototyping
- Further Reading
- 43. Voluntary Overtime
- A. Bibliography
- Index
On a lot of team projects, there are two or three regular developers and one developer who has some management responsibilities. This person is usually called a "lead" or "technical lead." The person is usually assigned to this role on the basis of technical rather than management expertise. Straddling the fence between development and management is a tricky business for this person and one that can destroy the project if not handled well—either because the lead relates poorly to the team or to upper managers.
Managers and technical leads don't always work closely together. A lot of problems—overlapping responsibilities, motivation, customer relations, low quality, poor alignment on project goals, and so on—can be improved when they communicate effectively about the issues they're dealing with.
One of the biggest obstacles to effective performance of the technical-lead role is the lack of a clear division of responsibilities between the technical lead and the manager. There is often a muddling of responsibilities. For example, the manager may know little about how the team functions day to day but may still be responsible for conducting the team members' performance reviews.
In its purest form, the technical lead is responsible for the technical work and is responsible for a single team. The manager is responsible for the nontechnical direction of the team and is responsible for two or more projects. From the team's point of view, the manager's role is to unburden the technical lead by handling certain nontechnical tasks. From the organization's point of view, the manager's role is to control the team so that it conforms to the goals of the organization. Some of the team models, particularly the professional athletic team and the theater team, are better than others at helping to keep the distinctions between the two roles in mind.
Since the specifics of the technical-lead/manager relationship vary so much, it's useful for the technical lead and manager to discuss their roles at the beginning of the project. That helps to avoid responsibility clashes in which both people think they're responsible for the same thing and responsibility vacuums in which both people think the other person is responsible.
John Boddie published an interesting diagram that described his view of the relationship between the project manager and the technical lead (shown in Figure 13-3), and I think the diagram brings some key issues to light (Boddie 1987). You can use the diagram as a focal point to discuss and clarify the technical lead's and manager's responsibilities.
Figure 13-3. Project manager's and technical lead's responsibilities. Since specific roles can vary from project to project, a discussion that uses this illustration as a focal point can help to clarify the division of responsibilities on a particular project. Source: Adapted from Crunch Mode (Boddie 1987).
Case Study: Good Match Between Project Objectives and Team Structure
Across the company from Bill's Giga-Bill 4.0 project, Claire had been tapped to oversee an update to the inventory control system (ICS). Like every other project in the company, this one needed to be completed as soon as possible—in about two months. Unfortunately, none of the original team members for ICS 1.0 were available to work on version 1.1, so Claire brought in Charles, a software engineering consultant, and asked him how she should set up the team.
"Well," Charles said, "it sounds to me like this is a straightforward product update. You have a good idea of what the users are asking for, right? This is version 1.1, which is an incremental release, so it doesn't seem like there's any great call for product innovation. But the update does require more work than just a few bug fixes. I'd say that the best kind of team structure for this project is a tactical-execution team. You could set it up as a chief-programmer team, a SWAT team, or a professional athletic team. I don't think it makes sense to set up full-fledged feature teams on this project because there just isn't that much work to do. It seems like that would be too much overhead. Who are you going to put on the project?"
"I'd like to have Kip lead the project," Claire said. "He is a competent all-around programmer. He's careful and good at working with end-users, but I don't think he is strong enough to be a chief programmer. I also plan to use Sue, who is good at debugging and making fixes, and Tomas, our in-house reporting expert. The biggest work items are working through a list of low-priority bug fixes that we didn't have time to fix in version 1.0. We also need to add some new reports. There are some minor user-interface enhancements, but they aren't as significant as the reporting changes."
"Based on what you've told me, I think you should use an athletic-team model," Charles said. "Each person has an existing area of expertise. Why don't you make Tomas the reporting specialist. Since there isn't as much work in the UI area, make Sue the bugmeister and the user-interface specialist, too. Make Kip the team captain; he's careful, so he can be the primary reviewer of Sue's and Tomas's code. He can also be the main link to both you and the customers." Claire agreed, and set up a meeting with Kip, Sue, and Tomas.
The developers liked the idea of specializing in specific areas and were happy with the roles Claire suggested. Claire emphasized that the project needed to be completed as fast as possible, so they dove in.
They had a clear picture of what they needed to do, and they spent their first few days reviewing the old project. Then they began designing the reporting and user-interface enhancements. Tomas proposed a safe but clumsy design for the reports. Sue and Kip pointed out some design alternatives that would cut the reporting work by about half. Tomas accepted their suggestions gladly since he didn't want to be the person everyone was waiting for at the end of the project. He began coding. Kip read through Tomas's code about once a week, and Tomas was grateful that Kip, rather than the users, was catching his bugs.
Sue plunged into the long list of bug fixes, and Kip reviewed her fixes one-by-one. Sue was good, but at first about a quarter of her fixes seemed to produce unintended side effects. Kip's reviews caught almost all of those. Sue gained momentum as she worked, and by the 4-week mark she had been over so many different parts of the system that she seemed to be carrying the whole system around in her head. By that time she was making bug fixes at a brisk pace and with hardly any errors.
Tomas and Sue began to rely on each other for advice. Sue helped Tomas think through the systemwide ramifications of his detailed designs, and Tomas helped Sue spelunk through old reporting code.
Kip made regular status reports in person to Claire and the end-users. The end-users appreciated being able to talk to a live person and ask questions about how the project was going.
When they got deeper into the details of the project, the developers found that their assigned roles didn't completely cover all of the work that needed to be done. There were some database updates that involved considerably more work than "bug fixes" normally would. Kip volunteered to take on that work, and Sue and Tomas agreed.
As the 2-month mark approached, the team was performing in high gear. They voluntarily worked the last two weekends just to make sure they would have time for any unexpected problems, and they finally delivered ICS 1.1 2 days ahead of schedule.
-
No Comment