Practice 7. Everyone Owns the Product! Per Kroll Closer collaboration between team members and team ownership of the end product will result in a higher-quality product that better addresses the needs of the end users. Problem Many quality issues in software projects arise from items falling between the cracks. The gap often occurs because team members have too narrow a definition of what their job is or have difficulty transitioning work from one person to another. This is especially true with iterative development, where we move rapidly back and forth between requirements, design, implementation, and testing. This practice describes how to orient the responsibilities and mindset of team members to ensure that everybody takes ownership of the quality of the end product, broadens the scope of their responsibilities, and learns to collaborate more effectively within the team Background The other week, while waiting for a late-night flight, I was sitting in an airport restaurant. One of the servers was carrying a full load of dirty dishes back to the kitchen, and I was quite impressed that she could carry it all. Halfway to the kitchen a fork fell off one of the plates. Since her hands were full, she could not pick up the fork and continued to the kitchen. The fork remained on the floor. Five yards behind came another server, empty-handed. I know she saw what happened, because she took an extra long step to avoid stepping on the fork. But she did not pick up the fork either; she just continued walking, although she appeared not to be in any kind of rush and the restaurant was half empty. It was not her job to pick up the fork, so the fork just lay there waiting for somebody to step on it. One thing that differentiates an average eating establishment from a first-class restaurant is that in a first-class restaurant the entire staff are trained to consider it their job to give an extra hand to make sure that guests have a good experience. If a guest has an empty water glass, they offer to fill it up, even if it is not their table, or their job. If a guest seems to be looking for a server, they either inform the appropriate server or ask if they can be of assistance. They have learned that for the restaurant to continue to excel, all staff members must contribute what they can to create a great experience for their customers. A couple of months back, I reviewed a troubled project. As I discussed various project problems and possible ways to address them with individual team members I consistently heard them say, "But that is not my job." Each team member seemed to have a very narrow definition of what his or her job was, and it was clear that a lot of responsibilities were not included in anybody's definition. Nobody felt responsible for detailing the requirements, ensuring that requirements and test cases were synchronized, or improving developer tests to ensure that code delivered to the test team was of sufficient quality. To put it simply, the success of any project is everybody's responsibility, that is, everybody is responsible for doing whatever it takes to make the project succeed. This does not mean that you should not hold other team members responsible for doing their job, but when you see a task that needs to be done, either ensure that the responsible person does it, or do it yourself. Many quality issues in software projects arise when new system representations are created based on our interpretation of an existing representation of the system, such as creating a design based on interpreting the requirements, or creating the code based on interpreting the design. In iterative development we transition very rapidly between different system representations to refine the requirements, design, implementation, and test specifications of a system (and not always in that order!). If we do not change our view of what our responsibility is, we would end up with a lot of discrepancies between our representations. | Many quality issues arise when new system representations are created based on an existing representation of the system. |
Applying the Practice[27][27] This section is based on Kroll 2004.
This practice explains how the mindset of the team needs to be oriented to delivering a high-quality end product (see Table 3.1 for a summary). Responsibilities of each role have to adjust to the new mindset, and each person needs to take ownership of the end product. Let's have a look at how we need to orient the mindset of analysts, developers, architects, testers, managers, and customers in turn. Table 3.1. Summary of Required Mindset Orientation for Effective Iterative Development.Delivering a high-quality end product requires particularly close collaboration between analysts, developers, architects, testers, managers, and customers. This increased collaboration impacts responsibilities, means of communication, organization, and the way in which people see their role within the project team. In short, it creates new requirements for the mindset of each team member. |
|---|
Old Mindset: "It's Not My Job!" | New Mindset: "We'll Get This Done!" |
|---|
• Functional teams of either all analysts, all developers, or... | • Cross-functional teams consisting of analysts, developers, testers,... | • OK with low-bandwidth communication | • Must have high-bandwidth communication | • Communicate primarily through documents (requirements, design, . . .) | • Communicate through face-to-face meetings, evolving models, and tools | • Narrow specialists | • Generalists and specialists with bird'seye perspective[a] | • Focus on the specification | • Focus on the intent of the specification | • "Not my job" | • "We are all responsible for the end result." |
[a] See Ambler 2002.
The Analyst's New Mindset | An analyst is responsible for the right requirements being documented, understood, and properly reflected. |
The mindset of an analyst needs to change from somebody who is "responsible for documenting requirements" to somebody who is responsible for making sure that the right requirements are documented, understood, and then properly reflected by developers and testers. This means that as an analyst, you need to do the following: Establish an ongoing dialogue with, and seek the participation of, the end user to ensure that the right system is developed.[28] You need to do this not only to document the right requirements but also to ensure that end users appropriately see and use prototypes of the system as it is being developed. This approach helps you build the right system, since end users are frequently unable to understand the capabilities of an application based on reading a requirements specification, but they can understand prototypes. This dialogue also enables the end user to ask for the next logical set of enhancements, further increasing the business value of the application. [28] Stakeholder participation is a key part of Unified Process, XP, and Agile Modeling.
Encourage early implementation of key capabilities to understand what requirements will address business needs. Even though the project manager,[29] with the help of the architect, is responsible for determining in what order to develop what capabilities, an analyst needs to understand what requirement areas may need early prototyping to ensure that the end users understand what capabilities will be delivered. This information needs to be communicated to the project manager. [29] In XP it is the role of the customer or customer's representative to prioritize requirements. In Scrum it is the role of the Product Owner, in RUP it is the role of the System Analyst, and in OpenUP/Basic it is the role of the Analyst.
Work with developers and testers to optimize requirements. As developers and testers analyze the requirements and develop and test the application, they will make a lot of observations that may lead to requirements that are easier to implement and provide more value to the end users. The analyst needs to have an open and ongoing dialogue with the developers and testers to ensure that their observations are properly reflected in the product. Choose the right level of detail for requirements, based on the needs of your project and the phase you are in.[30] As an analyst, you need to understand that more detailed requirements are not necessarily better. If requirements are too detailed, it will take too long to understand the most essential requirements and cost too much to keep them up to date. When the requirements reach a certain level of specificity, the cheapest way of refining them is not by making them more detailed but by writing code that reflects the improved understanding. Spending too much time on the requirements details up front distracts the team from mitigating key risks. On the other hand, if the requirements are too vague, a lot of time can be wasted in guesswork, which may have regulatory, contractual, or other effects. [30] See practices Model with a Purpose and Maximize Stakeholder Investment in Ambler 2002.
The Developer's New Mindset | A developer is responsible for the development of a high-quality application that addresses the end user's needs. |
The mindset of a developer needs to change from somebody who is "just responsible for implementing the requirements" to somebody who is responsible for the development of a high-quality application that addresses the end user's needs. This shift means that as a developer you now need to do the following: Broaden your responsibilities to include detailed design, implementation, and developer testing. You want to minimize the number of hand-overs of information to different people to minimize potential errors and maximize efficiency. To minimize the number of hand-overs, make sure your team members take on as broad set of responsibilities as possible, so that you do not have one person doing the design and another doing the implementation. Make sure that whatever code you produce is of high quality; you need to test your own code and make sure that it works with the rest of the application. Become part of the requirements effort: help find solutions for requirements. As a developer, you often find ways to improve the application. You need to work with the analysts and the project manager to ensure that they understand any opportunities for improvements. Become part of the test effort. Modern best practices, such as test-first design, help you as a developer to focus on testing. With test-first design, you first specify what tests should be carried out and then build the software to pass the tests. This approach creates a strong focus on producing high-quality code and forces the team to concentrate on building high-quality applications. Also, advances in tool technology now allow Quality by Design,[31] making quality an integral part of the design process, allowing quality measurements to be made early in the design process, and enabling test drivers and test harnesses to be automatically generated from the design model. Quality by Design increases the quality and completeness of test code. [31] See Bryson 2001 for more information on Quality by Design.
Make reuse of existing solutions a higher priority than building from scratch. In the past, developers rightfully took pride in coming up with clever solutions to tricky problems. Unique solutions were produced from scratch to maximize system performance, minimize memory usage, or provide a good GUI. Of course, developers still need to come up with clever solutions, but the focus needs to move away from building solutions from scratch toward finding clever ways of tying reusable assets together into a workable solution through open source software, commercial-off-the-shelf (COTS) components, internally available components, and Web services. This shift away from custom-building assets to reusing existing solutions impacts not only the design and code but also the business, requirements, test, and management assets.
The Architect's New Mindset | An architect is responsible for making high-level design decisions and ensuring that they are properly reflected in the final code. |
The mindset of an architect needs to change from somebody who does high-level design and then leaves the project to somebody who is responsible for making high-level design decisions, balancing the multitude of technical and project constraints; somebody who mentors the developers on the project vision; and somebody who stays throughout the project to ensure that the chosen design decisions are properly reflected in the final code. This approach means that as an architect you now need to do the following: Be engaged in the project from start to finish. Many projects suffer because architects come in early in the project, lay out the architecture, and then leave. One of the fundamental concepts in iterative development is the need to allow some flexibility for change, but changes that may impact the architecture should not be made without discussing them with an architect and the affected developers. Also, a paper architecture has limited value. Only when the architecture is implemented and tested does it provide significant value, and the architect needs to stay with the project until this goal is accomplished, as well as to handle change requests that may impact the architecture. In general, as an architect you should contribute some time in the inception phase, a lot in the elaboration and early construction phases, and less and less as you move toward the end of the construction and transition phases. Prioritize and drive development of architecturally significant scenarios. To validate the architecture, you need to implement those scenarios that are deemed architecturally significant (see Practice 10Prioritize Requirements for Implementation). You need to determine which scenarios are architecturally significant and remain closely involved in their development, to ensure that the team makes and validates the right architectural decisions. Ensure that all team members understand high-level design decisions. As you make high-level design decisions, you need to ensure that all team members understand how to leverage those decisions. You may need to include training on available architectural patterns, such as patterns for interprocess communication or persistency and how to use them. You may also need to document and walk through the high-level architecturewhat subsystems exist and their interfaces, how you will deal with change requests to the architecture, and how you will communicate with external systems. Make sure that appropriate testing is done on the architecture. As an architect, you need to make sure that the architecture not only works on paper but also does the job it is supposed to do. You must work with the testers to make sure that architectural qualities, such as performance, throughput, capacity, reliability, and scalability, are properly tested early in the project to avoid the need for major changes late in the project. Coordinate discussions impacting high-level design decisions. Throughout the project, there will be reasons to revisit architectural decisions, such as changing interfaces between various subsystems or responsibilities of subsystems. As an architect, you need to take an active role in these discussions to make sure that you understand and properly communicate any architectural changes to the affected team members.
The Tester's New Mindset | A tester does testing from start to finish and guides other team members in regard to test-related issues. |
The mindset of a tester needs to change from somebody who "injects quality at the very end" of a project to somebody who does testing from start to finish as well as becoming the test expert guiding other team members in regard to test-related issues. As a tester, therefore, you need to do the following: Define a test strategy that incorporates the stakeholders' definition of quality as well as the project team's priorities. All too often testers impose on the project their own predefined measure of quality, which not all stakeholders may agree on. Team members can succeed and correctly focus their efforts only if all share a view of what defines quality and project success. Become the team's mentor on testing approaches and methodology. Testers should share their expertise with the entire development team, for example, guiding management in test-related decisions, advising analysts on writing testable requirements, and helping developers conduct effective developer testing, in addition to actually performing much of the integration and acceptance testing. Work with analysts and developers to ensure that requirements and design are testable. Testers are trained to think about how to measure requirements satisfaction. Modern integrated test and development environments also constitute a major shift for both developers and testers by allowing continuous testing of work in progress using baselined code configurations. Testers need to provide feedback to the other team members so that they can make the appropriate improvements to the requirements, design, code, and other supporting artifacts. Get involved in the test effort early in the project. Iterative development involves testing in every iteration, which means that you need to shift the test workload from (primarily) the end of the project to a much more even distribution throughout the project. Testers need to work hand in hand with analysts and developers so that all understand what needs to be tested in each iteration. One way to ensure that this happens is through test-first design. Early in the project, testing will focus on finding "big issue" problems, such as major architectural concerns, that need to be addressed. Later in the project, testing will focus on validation and verification that the code is ready to be delivered to end users. Focus on addressing defined test objectives. Rather than trying to fix all defectsan often impossible taskunderstand what your objectives are with the test efforts. Determine the right level of quality and whether any specific aspects of the application need to be of a higher quality. Focus your test efforts accordingly. Continuously automate testing of stable capabilities. Iterative development means testing the most critical capabilities early in the project. You therefore need to test and retest these capabilities in successive iterations to ensure that problems considered solved do not recur. Full regression testing is impractical, and often impossible, without effective test automation, so automated tests should be developed continuously throughout the project. These tests should focus on what will be stable as the iterations proceed, so that they do not have to be radically changed in every iteration. This task requires collaboration with the rest of the development team (see Practice 6Leverage Test Automation Appropriately for more information).
The Manager's New Mindset The focus of a manager needs to change from day-to-day management, secondary artifacts, and stable plans to leadership, results-based management, and team collaboration. As a manager, therefore, you now need to do the following: Be a leader.[32] As a leader, you need to make sure that the team understands and shares the vision of what is to be accomplished and is motivated to work together to reach the end goal. You need to establish shared valueswhat is acceptable and what is not acceptableand continuously reinforce these values through actions. Rather than micromanaging, you need to continuously assess your position, determine the appropriate end point (and your view of the "right" end point will shift as you proceed through the project), and steer the team in the right direction. Finally, you need to help the team cope with the huge amount of uncertainty that always exists in software projects. [32] See Cantor 2001.
| A manager focuses on leadership, results-based management, and team collaboration. |
Empower your team. Iterative development requires different skills and means of collaboration. As a leader, you need to make sure that your team has the knowledge and responsibilities they need to succeed. You need to create cross-disciplinary teamsthat is, teams with analysts, developers, and testerswho can work together to achieve results. Support the changes in responsibilities and behavior described throughout this practice. Be open about the risks the project is facing, continuously reassess risks, and use risks to prioritize project work.[33] The most important distinction of the iterative development approach is to drive out major risks early in the lifecycle. It therefore requires openness and honesty about the risks faced by the project. Risk will help you determine what to focus on in the next iteration, and risks and their mitigation should be an important aspect of the status meeting discussions. [33] See Cantor 2001 and Highsmith 2004.
Assess status through demonstrable results rather than through completion of activities. As a manager, your focus must now switch from activities to demonstrable results. Completed activities are a poor measure of success, since the mere completion of an activity generally does not say anything about the quality of the end result. Rather, as a manager you should concentrate on assessing the results that have been achieved. Since the primary result is the software itself, the first measure of success should be delivered working software. This measure provides a more reliable assessment of the project's status than do secondary artifacts such as requirements and designs, because even though a requirements document has been "finished," it may later need major rework based on feedback from working prototypes. Develop high-level plans for the entire project early on, but produce detailed plans only for the current and next iterations. Traditionally, many managers spend a lot of time initially producing detailed project plans for the entire project. But in reality, so much uncertainty accompanies most projects that such plans merely serve to provide a false sense of assurance, suggesting fictional precision where none exists. Instead, managers should produce a high-level plan for the entire project that briefly describes the expected outcome of each iteration and detailed plans only for the current and following iterations. Balance investments in requirements, architecture, design, implementation, and testing at any given time, to ensure that risks are being addressed.[34] In the waterfall approach managers pay much attention to planning and requirements. In iterative development, managers at any given moment need to focus on balancing the investments in requirements, architecture, design, and implementation in order to address your risks. A manager should ask: "Which types of activities will best mitigate key risks right now?" Maybe it's only by prototyping a solution that you can address risks related to stakeholder buy-ins, or only by designing, implementing, and testing the architecture that you can address architectural risks. [34] Royce 1998.
The Customer's New Mindset The mindset of a customer needs to change from somebody who is external to the project to somebody who is an integral part of it. As a customer, therefore, you now need to do the following: Become an integral part of the development team. Today, many customers expect minimal involvement in the development effort. They want to specify all their requirements up front, determine a fixed price, and then wait for delivery of the final system. Frequently, the result of this interaction model is a solution that does not address their true business needs and large discrepancies between what they were expecting and what was delivered, causing both the customer and the development team a great deal of pain. Instead, customers should seek to be active participants in the project. | A customer is an integral part of the project. |
Continuously provide feedback on capabilities that have been developed, such as working prototypes and user-interface designs.[35] No matter how crisp the requirements are, they have a multitude of interpretations and possible implementations. Rather than investing in even more detailed requirements, it is often more effective to invest in more frequent interaction between developers and key stakeholders, including customers. As customers view the evolving application, they gain a better understanding of what it should do and can provide constructive feedback to improve the solution. Also, in many cases business needs evolve rapidly, and the requirements need to evolve in tandem with the changing business needs during the project duration. [35] Feedback is an XP value; see Beck 2004.
Leverage progressive acquisition models in which an iterative approach to acquisition protects the interests of the buyer as well as the seller. Contractual agreements also benefit from an iterative approach, or what is referred to as progressive acquisition. The idea behind progressive acquisition is to have an umbrella agreement for the entire project outlining the overall legal conditions that govern the business relationship between the two parties. The actual project is divided into two or more subcontracts. Earlier contracts are defined by time and materials, since neither party knows enough about the overall solution and costs to develop it to make up-front commitments. Later contracts are for a fixed price, minimizing risks on both sides of overruns or disagreements on what should be delivered.[36] [36] Wideman 2003.
Guidance for Larger Teams The above guidelines point to a series of changes in the responsibilities of each team member. To avoid tasks falling between the cracks within a larger organization or project, you also need to consider additional changes: Produce precise documentation or models. In previous discussions concerning this practice, we have emphasized collaboration as a means to reduce the chances that tasks will fall between the cracks. As teams grow, you need to support this collaborative approach with precise documentation to ensure that everybody is clear on what other people do. Note that "precise" does not mean lengthy. Quite the opposite, in fact; it is typically preferable to have a one-page UML diagram that is precise than ten pages of text. | Produce precise documentation or models. Precise does not mean lengthyquite the opposite. |
Scalable collaboration infrastructure. Establish an infrastructure that allows effective communication across geographies and teams. Examples of such an infrastructure include team-based tools for requirements management, management of reusable components and other assets, defect tracking, and configuration management. It also includes automation of status information, since updating this type of information can waste huge amounts of time as teams grow. Enterprise architecture. By having an enterprise architecture provide guidelines on how to architect individual applications, you increase the chances that various applications will work together and that you can share common components across applications. You should also have cross-team review boards perform architectural reviews. Program management. Invest in program management to coordinate across teams. This coordination needs to take place across various functional areas, such as requirements, architecture, and testing. Invest in organizational experts. Many complex applications require the involvement of people with very deep skills. An individual project may not be able to acquire someone with these deep skills, nor take on a person, even part-time, with skills such as globalization or accessibility (dealing with how to make software accessible for people with disabilities).
Other Methods This practice is very well aligned with the broader agile community. The Crystal family of methods, XP, Scrum, Agile Modeling, Adaptive Development, and other methods all talk about the need to involve customers in the project, have the extended development team collaborate closely, and have all team members take ownership of the end result. The agile community has consistently promoted the softer issues around software development to reflect the reality that people issues are central to developing software. | People issues are central to developing software. |
XP values associated with this practice include communication, feedback, courage, and respect, while XP practices associated with this practice include sitting together, whole team, and test-first programming. The practice of whole team[37] describes the importance of building cross-functional teams, the practice of sitting together deals with how to make people interact more throughout the day, and the practice of test-first programming deals with how to tie requirements, design, implementation, and testing efforts more closely together. [37] Beck 2004.
Another interesting area is involvement of experts. XP involves experts by moving them temporarily into a project as they are needed and out again as they are no longer required. XP points out the disadvantages of having people working in a project part-time, which typically makes them inefficient. XP also involves external experts as pair programmers, allowing the team to learn from experts and to leverage their skills to develop more effective code. RUP is more open than XP to the notion that if certain types of expertise are in very short supply, you need to involve them on a part-time basis, maybe primarily as advisors or reviewers, especially in a large organization that can absorb the cost of building up deep expertise, even though the individual project cannot. Examples of such skills may include deep skills in globalization or accessibility. Jeff Sutherland, one of the creators of Scrum, uses a metaphor of pigs and chickens when talking about managers and team members. The metaphor comes from a story about a pig and a chicken: | Chicken: | | Let's start a restaurant! | | Pig: | | What would we call it? | | Chicken: | | Ham n' Eggs! | | Pig: | | No thanks. I'd be committed, but you'd only be involved! |
This story reflects that it is the actual project members (pigs) who are committed to a project's success. As a team, we are responsible for the end product, and we should therefore have the authority to make decisions that have an impact on it. In Scrum, team members are allowed to make decisions for themselves within an iteration (sprint), without having managers or other external parties (chickens), who are only involved, second-guess what they should do. As an example, chickens are allowed to attend, but not to speak, during the daily scrum status meetings. We authors salute the notion of self-managed teams and breaking down walls between team members, but we also feel that many people in the agile community assume that managers add little value and describe processes for managing around managers (as with the chicken and pig above). Even though some managers add only limited value to the execution of a project, our experience is that most add value through their daily work, and the team should seek to involve their managers more than only at iteration ends. We believe that rather than working around managers in general, we should instead assign them clear responsibilities, so that we can improve the behavior of poor managers, maximize the value of their contributions, and help make them into great leaders. Levels of Adoption This practice can be adopted at three levels:  Basic. Openly share information to encourage early discussion of ideas and evaluation of 10 percent complete materials. Avoiding guarding artifacts and code until they are perfect.
The basic practice of information sharing should minimize the need for later rework, which should lead to a more relaxed process and shorter iterations. Intermediate. Assemble cross-functional teams, including the customer or customer's representative. Hold each team member responsible for the end product. Assess status primarily based on demonstrable progress. This approach forces the team to look at the complete product rather than just individual pieces, such as the requirements or the design. As issues are identified, the team identifies how to best resolve them, which typically involves cross-functional collaboration. The intermediate practice of cross-functional collaboration is crucial for effective iterative development and should in most cases also result in minimal bureaucracy. Note that this process will, however, make a manager's job more difficult, since it has more moving parts.   Advanced. Adopt the practices described in the section Guidance for Larger Teams, including scalable platforms for collaboration, enterprise architectures, and organizational expertise.
The advanced practice, which is primarily for larger organizations and teams, increases overhead associated with change and thus drives the project toward greater discipline and longer iterations. The exception is the practice of scalable platforms for collaboration, which requires a higher skill level but makes meaningful collaboration much easier, hence reducing the iteration length.
Related Practices Additional Information Information in the Unified Process OpenUP/Basic captures the guidance in this practice, with the exception of progressive acquisition and the guidance in the section Guidance for Larger Teams. RUP adds guidance for progressive acquisition, as well as in-depth guidance on how to collaborate effectively using more in-depth models and documentation and a variety of software development tools. RUP also provides guidance on cross-project coordination, such as program and portfolio management. Additional Reading The following books capture guidelines around collaborative best practices and self-organized teams: Kent Beck with Cynthia Andres. Extreme Programming Explained: Embrace Change, Second Edition. Addison-Wesley, 2004. James A. Highsmith. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House Publishing, 2000. Scott Ambler and Ron Jeffries. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. John Wiley & Sons, 2002. Alistair Cockburn. Agile Software Development. Addison-Wesley, 2002.
The following books describe best practices around people management, project organization, and project leadership: Murray Cantor. Software Leadership: A Guide to Successful Software Development. Addison-Wesley, 2001. Walker Royce. Software Project Management: A Unified Framework. Addison-Wesley, 1998.
|
