Agile Basics

Waterfall v Agile DOCUMENTATION

WATERFALL: -Prepares a series of formal written documents AGILE: -Relies on visual documentation

Waterfall v Agile PROJECT LIFE CYCLE

WATERFALL: -Employs distinct cycle phases -Completes tasks in a sequenced order -Does not revisit a phase once it has been completed AGILE: -Uses a series of rapid iterations with design/build/test segments aimed at incremental releases -May revisit work or work phases as needed

the daily stand up: best practices / make your daily meeting live up to its potential

-The daily stand-up serves a very important function in the Agile cycle, but it can become a significant distraction if not done well. This meeting should help the team achieve its goals, and not become a chore that it must perform to satisfy a management directive. -COMMUNICATIONS *Focus the daily stand-up on communicating, not reporting. *If your meeting becomes simply a forum to present individual progress reports, you are wasting valuable time—send an email instead. Email reports can provide an adequate record of progress. If, however, you use the daily stand-up to let team members discuss daily progress and request additional assistance, you'll encourage team interaction, provide transparency for your project, and keep the project on track. *A daily stand-up should meet five goals: recommit the team members to the project as a team, communicate the project status, identify any obstacles the team has encountered, set the day's direction, and help the team build cohesiveness. Reporting meetings may be able to meet some of these goals, but to satisfy all of the goals, your meetings need to be collaborative and interactive. -DISCUSSION *Don't let daily stand-ups become in-depth problem-solving discussions. *Daily stand-ups should uncover any obstacles that team members are facing, but should not be a prolonged discussion of how to solve problems. Use the meeting to discover how (in general terms) a problem could be dealt with and who can help with an issue, but leave the specifics for addressing the problem outside of the group meeting. (Discuss the problem-solving specifics immediately after the daily stand-up, while the details of the problem are still fresh in everyone's mind and solving the problem will allow further progress). Remember that the stand-up should be brief, to allow people to share information and then get back to creating products and satisfying customer requirements. -LOGISTICS *Be consistent with meeting logistics. *Select a location and time for daily stand-ups and stick to them. Consider holding the meeting in a common area near the project story boards to allow presenters to use the boards to clarify points. Also consider holding the meeting at the start of the workday, when energy levels are high and the entire day is available to solve problems and complete tasks. Be sure that you start and end the meetings on time; people will be more likely to attend if they know that the stand-up is timeboxed and they can get back to work. (For distributed or dispersed teams, don't forget to consider time-zone differences when scheduling the meeting.) Consider arranging team members so that presenters are grouped in the center of the area, with observers behind them, to ensure that the meeting is about team collaboration, not about input from outsiders. -GUIDELINES *Set guidelines for the stand-up *Make sure that team members record their progress on the burndown chart (or burn-up chart) before the meeting begins so that the most current information is available for discussion. Establish rules that will determine who will speak first, then who will speak next, and so on. (For example, perhaps the person who arrives to the stand-up last must begin the conversation, or the person who occupies a specific spot in the room must speak first, then select the next speaker.) Make sure the communication is among the team, not to the project manager or product owner. (If this proves difficult, you may want to instruct the manager to look away or walk away from the presenter while he or she is speaking, to reinforce that this is a collaborative team meeting, not a management progress report.) Set ground rules that describe which issues members can raise in the meeting—can members discuss only issues they need help with, or can they also share information about any problems they can overcome themselves? And make sure that any issues or impediments uncovered are fixed before the next day's stand-up.

Agile v traditional project management

))-"Agile development and project management are built on an underlying premise that individual capability is the cornerstone of success, and furthermore, that individuals are unique contributors. It follows from these premises that rather than molding people to a set of common processes and practices, processes and practices should be molded to the team itself. Although an organization might insist that project teams follow a guiding framework, there should be flexibility as to what individual practices are used to meet the needs of each phase." -In deciding where to employ Agile, a project manager must understand the similarities and differences between an Agile approach and a traditional project management approach at different stages of the project process. SIMILARITIES: -Step: Explain why the project is needed and what the end product will be; Agile: Create a product roadmap and product vision; Traditional Project Management: Create the project charter (A document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.) -Step: Decide what is most important to the customer and what the project/release will contain; Agile: Prioritize the user stories and plan the release; Traditional: Define the project scope (The sum of the products, services, and results to be provided as a project. See also project scope and product scope) and create a management plan -Step: Break the project work down into smaller components; Agile: Plan the iterations; Traditional: Decompose the work and develop any necessary subprojects -Step: Create increments of the product along the way; Agile: Develop potentially releasable or marketable products within an iteration; Traditional: Develop interim deliverables (Any unique and verifiable products, results, or capabilities to perform a service that are produced during a process, phase, or project.) -Step: Collect and incorporate feedback to improve products and processes; Agile: Perform iteration reviews (Informational meetings in which team members demonstrate to stakeholders which stories were completed in just-concluded iterations and begin to prepare for the next iterations.); Traditional: Use rolling wave planning (A form of progressive elaboration planning where the work to be accomplished in the near term is planned in detail at a low level of the work breakdown structure, while the work far in the future is planned at a relatively high level of the work breakdown structure, but the detailed planning of the work to be performed within another one or two periods in the near future is done as work is being completed during the current period.) and perform integrated change control (Reviewing all change requests, approving changes, and managing changes to the deliverables, organizational process assets, project documents, and project management plan.) -Step: Create the end product and monitor its development; Agile: Complete the development iterations and conduct retrospectives; Traditional: Manage and control the project execution -Step: Complete the project; Agile: Combine the iterations into a release and perform a retrospective; Traditional; Transition the final deliverable to the stakeholders and review the lessons learned DIFFERENCES -Step: Decide on the optimal project management methodology to use; Agile: Develop complex products in fast-paced, uncertain markets; Traditional: Develop well-defined products, products with minimal changes, or products in highly regulated industries -Step: Develop customer requirements; Agile: Capture customer requirements as the project or product evolves; Traditional: Collect customer needs early in the project (during scope development) -Step: plan the project/release; Agile: Determine the schedule or budget, then decide what features can be delivered within these constraints; Traditional: Decide what features are contained in the project scope, then determine the project cost and budget -Step: create the product; Agile: Use shorter product-development iterations to deliver more-focused features in smaller, faster increments; Traditional: Use longer durations to plan and develop products that include more features Step: Collaborate with stakeholders; Agile: Collect feedback continuously to help prioritize and clarify customer requirements, and adapt the product to ensure that customer requirements are incorporated; Traditional: Collect customer needs in the project initiation stages and monitor project progress to ensure the final product meets these needs -Step: assess changes; Agile: Promote change and allow the product to evolve and deliver the best value to the customer; Traditional: Avoid change and institute corrective action (Documented direction for executing the project work to bring expected future performance of the project work in line with the project management plan) to ensure the product conforms to plan -Step: Define the role of the project manager/leader; Agile: Allow the team to direct the work; provide the boundaries for the project and remove impediments to the team's progress; Traditional: Direct and monitor the project work; tell the project team what activities to do, when to do them, and how they should be done

Managing scope in Agile projects: best practices

-All projects experience changing requirements and even though Agile projects embrace change as a way to ensure customer satisfaction, teams still need to minimize scope creep. Uncontrolled scope changes can create project delays, trigger drastic cost increases, cause frustration for team members, and lead to quality problems. -The following Agile best practices can help in avoiding these problems and keeping projects on track: CUSTOMER REQUIREMENTS: *A constant focus on customer requirements *Keep customers actively involved in the process by continually soliciting their feedback. Consider inviting them to daily stand-ups (as observers) so they are informed of the project's current status and future plans, and are less likely to propose last-minute changes. If they understand the impact of scope changes and the tradeoffs needed to offset scope creep, they should make better choices when it comes to change requests. *Verify the project scope with stakeholders during iteration reviews and subsequent iteration planning. Scope creep often results when stakeholders try to add features that they didn't think of earlier in the project. Verifying scope at the end of each iteration allows customers to clarify their ideas and know that their requests will be addressed in the future. CHANGE REQUESTS: *An effective process for dealing with change requests *Use the product backlog to prioritize new requests and prevent secondary problems. Funneling all change requests through the prioritization process ensures that they do not supersede higher priority items. It also prevents new requests from causing unexpected problems for the team. *Channel all change requests to the product owner. The product owner's job is to collect requirements and ensure that customer needs are considered for inclusion. Channeling scope changes through the product owner will ensure that requests are analyzed and incorporated without interrupting the current flow of the project. CUSTOMER FEEDBACK: *Assurances to customers that their requests will be heard *Explain to stakeholders that, when the process does not allow for immediate changes, they can be incorporated in subsequent iterations. Agile teams should remember: "don't say 'no,' say 'not yet'" when dealing with customers. Assure customers that their suggestions are not being ignored; they will be discussed and prioritized before the next iteration begins. *Use iterations and the product backlog to manage stakeholder expectations. Reiterate that iterations are short and set in timeboxes, and all requests are captured in the product backlog so none are lost. TRADE-OFFS: *An understanding that changing requirements may necessitate trade-offs *Keep everyone informed. When new features are added, others may have to be removed or returned to the product backlog to make room. Discuss these trade-offs with the entire team so that everyone is aware of changes and can present new viewpoints that may uncover emerging risks. Effective trade-offs substitute requirements of higher value for ones with lower priority. *Make sure any trade-offs fit within the plan. Requirements added to the work effort must be of roughly the same size as the requirements they replace. If there is a significant difference between the requirements (or if there is not enough time left in the timebox to incorporate the new request), it may not be possible to complete the work in time. -Very few projects are completed without the potential for scope creep; all projects experience requests for change in some form. Agile is efficient in its ability to adjust to change, but changes must be coordinated and controlled. Uncontrolled change may create customer satisfaction in the short term, but can create larger problems in the long run.

Initiating an Agile project: best practices

-FOCUS ON THE PEOPLE *Select the right people for the team. Build the team with key people first, then supplement the group with members who are motivated to learn. If possible, recruit generalists (or people who are interested in becoming generalists) rather than specialists, to ensure that all team members can successfully complete any task in the task list. Engage critical stakeholders early in the process and ensure their commitment throughout the project. *Train the team. Prepare them for the needed change in working style (Agilists work in teams, not as solo developers) and changes in responsibilities and expectations (team members rely on each other for expertise and work closely with teammates to ensure requirements are met) that Agile projects require. You may want to employ an experienced Agile coach who can help team members transition to Agile methods. *Communicate expectations clearly. From the start, it is crucial to clarify project requirements and expectations for the team. Team members should be empowered to develop innovative solutions to problems and to collaborate to find their own way of meeting goals. -THINK ABOUT THE PROCESS *Plan for entire releases (releases are one or more iterations. Only fully tested and supported versions of the product should be released to the customer.). Identify any dependencies across iterations (work cycles) and develop plans to share resources. Use the team's expected velocity to forecast subsequent iteration completion dates. Consider adding an initial iteration to early Agile projects to deal with any start-up or design issues, or a final iteration to refine products before release. *Keep initial expectations in check. Don't expect all early iterations to result in potentially shippable products; especially in complex projects that build upon existing products, iterations can be considered successful if they create end-to-end flows that refine practices. Adjust initial iteration timeboxes to reasonable lengths—two-week iterations may be too short (especially in early iterations) to incorporate training and show progress. *Clarify the boundaries of the release so everyone involved understands the project. Explicitly define the acceptance criteria to avoid surprises, and set a release date to prevent unlimited revisions to the project scope (The sum of the products, services, and results to be provided as a project. See also project scope and product scope.). Define "done" (All portions are complete (as agreed to by all parties) with no perceived changes or corrections necessary. The product can be used by the customer as intended.) consistently (especially when there are multiple teams) and limit multitasking to prevent harm to team cohesion and velocity. -ESTABLISH THE ENVIRONMENT: *Provide an effective team work area. Bring team members together to a co-located work space or develop tools so distributed or dispersed teams can feel co-located. Post all necessary information (story boards, plans, team ground rules) in a clearly visible part of the common area. Be pragmatic about the use of documents—use Agile templates and wikis whenever possible, but don't ignore documentation that is clearly needed. *Create a culture of organizational trust. Encourage team members to explore options and make it clear that this exploration occurs without repercussions. Work to make sure that management is committed and patient enough to see the Agile cycle through to its completion, and is willing to expend the necessary resources on training, mentoring, and coaching to adopt Agile.

Scrum

-Scrum is one of the most popular and widely used Agile methodologies. It is a highly structured yet adaptable way to develop complex projects. Like most Agile methodologies, Scrum relies on an empirical approach—one based on observation and experience—that creates products incrementally and puts the authority to make critical decisions directly in the hands of the development team. In contrast to many other forms of Agile, Scrum offers clear rules and guidelines within its framework, to create a shared sense of understanding and to provide guidance for team members. -Scrum is: *More management- and customer-focused than Extreme Programming (XP) *More product-centered than the Dynamic Systems Development Method (DSDM) *Less process-focused, but more timebox-dependent than Lean Software Development -Scrum is widely applicable. -"Scrum has been used from simple projects to changing the way entire enterprises do their business." Scrum methods have been adopted by many companies to simplify product development and produce tremendous impact in a very short period of time. -The Scrum process mirrors the generic Agile cycle, but uses a different terminology. -The Scrum process begins with a product vision and detailed customer requirements, prioritized in the product backlog by the product owner. The product owner and team select those items they can accomplish in the sprint, and compile them into a sprint backlog. Team members begin their work, completing daily scrums as they move forward and relying on the scrum master to handle any process impediments or obstacles. Once a sprint is completed and sashimi is produced, the product owner, scrum master, and team present the product to key stakeholders for their review and assessment in a sprint review* meeting. Upon completion of the sprint review, the scrum team undertakes a sprint retrospective to review their processes and prepare for the next sprint. *scrum master: Scrum-specific term for the person responsible for ensuring that the Scrum process is being followed and that the team is working at the highest level possible. The scrum master provides guidance during an iteration, removes impediments to team progress, and helps the team learn to self-organize and solve problems. Also called the Agile project manager. *sashimi: Scrum-specific term for the potentially shippable result of an iteration. The potentially shippable result must be complete and able to be used by the customer with no additional adjustments or corrections. Also called a potentially shippable product. *sprint review: Scrum-specific term for the informational meeting in which team members demonstrate to stakeholders which stories were completed in the just-concluded iteration and begin to prepare for the next iteration. Also called an iteration review. *sprint retrospective: Scrum-specific term for the meeting at the end of each iteration in which the team discusses how well it worked together to create the product and what changes they could make to improve in subsequent iterations. Also called an iteration retrospective. *product owner: The person who represents the customer, user, or other stakeholders in a project. The product manager/owner manages the product backlog, answers the team's questions, and works with the team to decide what each iteration (sprint) will entail. Agile term: product manager *sprint: A time-delineated development cycle that produces a complete product that could be marketed or released to the customer. Agile term: iteration -For larger projects that include multiple teams, Scrum practitioners employ an additional meeting—a scrum of scrums. This daily 15-minute team-progress meeting involves representatives from the independent scrum teams and coordinates activities across teams. Attendees collaborate and share team information by answering the same three questions that they answered in their team scrum meetings—what the team accomplished yesterday, what they will accomplish today, and what obstacles are impeding team progress—but add a fourth question—is the team creating impediments that will obstruct the work of other teams?—to the scrum-of-scrums discussion. -Scrum practitioners often describe project participants as either pigs or chickens. Pigs are individuals (like the product owner, scrum master, and team members) who are actively involved in the project—they are responsible for the day-to-day work of the project and are accountable for its success. Chickens are individuals (such as senior management, customers, and users) who have an interest in the project, but are not involved in the daily work and are not held accountable for the project's results. The terminology originates from a classic joke about a chicken suggesting to a pig that they open a restaurant together and call it "Ham and Eggs." The pig declines because, although the chicken would be involved in the project (laying eggs), the pig would have to be committed to the venture (sacrificing himself to provide the ham for the menu).

XP scalability

-XP is limited in its scalability; it can be scaled to tackle larger problems and projects, but is not ideal for projects with larger teams. Because XP uses very little documentation and relies on team interaction to share knowledge, project information resides within the team members themselves—not in documentation. Adding additional members to the group makes sharing that knowledge much more difficult. As the group grows, it is harder to interact with every team member on a regular basis and the knowledge that could be shared among team members in those interactions is lost.

XP core value: simplicity

-XP practitioners perform only the amount of work needed to meet that day's requirements, with an understanding that more work may be needed on subsequent days to fix or adapt the product. Because they avoid creating features that may go unused, products are kept simple and adjustments should be minimal.

XP core value: courage

-XP requires courage on the part of the development team to make the difficult decisions needed to deliver value to customers. Developers are expected to move quickly and decisively, with the courage to make adjustments as they see fit, and try new ways to get results. They must have a belief in their abilities and be encouraged to push forward to deliver results.

Waterfall v Agile HUMAN RESOURCES

WATERFALL: -Employs a project manager to direct, manage, monitor, and control work -Makes use of a hierarchical structure of roles and responsibilities AGILE: -Uses an Agile team leader to coach, facilitate, and protect the team -Utilizes a cross-functional, often co-located, team -Avoids creating a hierarchy of roles

Waterfall v Agile CUSTOMERS

WATERFALL: -Depends on heavy customer involvement in the planning phase, but has only limited customer involvement after the planning phase AGILE: -Relies on customer participation throughout the project

Agile senior management and Agile transitions: best practices

-Because Agile projects are less predictable than traditional Waterfall projects, the transition to Agile practices can be difficult for some executives, especially those who are accustomed to detailed reporting and tight controls. -Agile projects include a degree of uncertainty; there are no detailed project plans or lists that specify what will be created, when it will be available, and how much it will cost to produce. As a result, executives who have spent their careers in a traditional project environment may struggle to adapt their management style to this less-documented approach. -To help these senior managers better understand Agile practices and deal with the organizational transformation, be prepared to answer the following questions: BUDGETING *How do I create a budget for an Agile project? *For some projects, budgeting is easy; the budget is predefined and the release will include as many features as can be created within the budgeted total amount. The product released typically will satisfy many (if not all) of the most important customer requirements, because each Agile iteration is designed to include as many of the highest priority items from the product backlog as possible. *For those Agile projects that release products only after a certain number of features have been completed, budgeting can be problematic. Management may be reluctant to commit resources to projects that, by their very nature, are open-ended—the requirements are incompletely defined and the release date is unknown. To overcome this reluctance, it may be helpful to have the team develop a high-level view of the project first to set the project boundaries. You can then suggest that senior management use these boundaries to decide how to fund the project. This will still allow the team room to adapt its work to best achieve the project's objectives, but will assure management that the project will not exceed the preset boundaries. *As an alternative, you can suggest to management that they set up initial funding for the project, then review project progress after a certain number of iterations to decide if funding should be continued. In this way, management can terminate funding for any projects that are not meeting expectations at any point and free up funding for projects that better meet the organization's objectives. BUDGET TRACKING: *How do I track the budget for an Agile project? *It is actually easier to track budgets in Agile projects than in traditional Waterfall projects. Daily updates to the burndown chart (or burn-up chart) show how many tasks are completed each day; by tracking how much of the budget was expended to complete each task, management can compile an accurate picture (rather than an estimate) of the value that was produced for the costs incurred. (This can also help determine how much it will cost to complete each story point, which can then be used to forecast expenditures for future stories and iterations.) SCHEDULING: *How do I create a schedule for an Agile project? *Some projects set a release date and then work to satisfy as many requirements as possible within the allotted time (similar to using a predefined budget as a constraint, as described previously). *However, if the schedule is not set as a constraint, senior management should decide whether it will use cost or scope as the boundary for the project, then have the team schedule a preliminary planning meeting to discuss how many iterations they believe it will take to create the product. Although this discussion will result in only a rough estimate, the estimate can be refined as the project continues. *Alternately, because the Agile cycle produces potentially shippable products at the end of each iteration, management can decide when the product will have enough minimally marketable features to be of value to the customer. They can use this point as the low end of a range, and set the date when all of the features will be completed as the range's high end. The range can then be refined and updated as the project progresses. SCHEDULE TRACKING: *How do I track the schedule for an Agile project? *Much like tracking budgets in Agile projects, tracking Agile schedules can also be easier than tracking Waterfall project schedules. Iteration reviews, team velocity, burn charts, and timeboxes make it easier to track real progress against the remaining schedule and to forecast future results. COMPENSATION: *How do I provide adequate rewards and compensation for performance? *Because Agile practices stress teamwork and collaboration, it may be very difficult for senior executives to adequately measure individual performance and provide appropriate compensation. Even with significant input from the Agile project managers and product owners who work with the team every day, developing an appropriate reward and promotion system can be difficult. Individual rewards recognize team members who demonstrate exceptional skills and achieve outstanding results but may cause competition among the team. That can inhibit teamwork and the sharing of information. Team-based rewards foster a "team-first" attitude, but may hamper growth and learning if teams resist adding new teammates who they feel will slow their progress. *One approach is to develop Agile compensation and promotion systems that reward both team and individual accomplishments. Management could, for example, provide compensation to the team, then let the team decide how it will divide the reward among its members. However, for this to be successful there must be complete trust among team members that the distribution is fair for all involved. -For Agile organizations to be successful, senior executives must adapt their management style to align with the work of its Agile teams. For many managers, this transformation can prove difficult. They have to leave old management ideas behind and adapt to new methods and practices. Those that are able to adapt create options and opportunities for organizational success.

closing an Agile project: best practices

-Before handing a project over to a production or operations department or to an external customer, effective Agile teams conduct one last retrospective to officially close the project. This final project retrospective allows the team to review the project as a whole and helps team members resolve any remaining issues before moving on to new assignments. -Steve Pavlina has several suggestions for conducting this final retrospective (or "postmortem," as he calls it). We have summarized his suggestions below (and added a few of our own comments) to help you complete this final activity and successfully bring your project to a close: INVOLVING PARTICIPANTS: *Be sure to invite everyone who contributed to the project to the project retrospective. *Schedule the retrospective and invite contributors as early in the project as you can, so they can set aside time in their schedule to attend. Solicit any ideas that they may have for improving future projects. Consider using a three-part questionnaire to collect their impressions—ask them to rate the experience on a scale of 1-10, have them answer targeted questions to capture targeted feedback, and include a comments section to let them provide open-ended/qualitative feedback about the project. *Be sure that the retrospective includes someone in the organization who has the power and authority to get things done. *Retrospectives often surface issues that are outside the team's control so you may need to escalate these problems to someone who can ensure that they are handled appropriately. RECORDING RESULTS: *Record the results of the retrospective and make them available to other teams. *Document all contributions in writing and consider ways to make lessons learned accessible across your organization. Placing the results on a company intranet allows you to link to additional resources and information as needed. STARTING WITH PROJECT OVERVIEW: *Start with a project overview to reacquaint everyone with the project's intended objectives. *Review the project's purpose and intended customer. Describe the initial design suggestions, the estimated budget, the scheduled start and finish dates, and other relevant information. RECORDING PROJECT DETAILS: *Record the project details. *Include a final project description and list any problems or defects you encountered. Document the final budget and final release dates. List the development tools and processes you used and describe any innovations or process modifications you may have implemented. Be sure to list the contributions of everyone who worked on the project to ensure that they receive proper credit and to document individuals that future teams can turn to for expertise. DESCRIBING FAILURES/SUCCESSES: *Describe the project failures and successes. List at least 10 things that went better than expected, and at least 10 things that went worse than expected. Review all of the iteration retrospectives and record all results and suggestions. Document any surprises you encountered during the project and how you responded. *Take time to evaluate individual and team performance. *Record your impressions of teamwork, individual contributions, and newly acquired individual and team skills while they are still fresh in your mind, in case you are asked to assist in performance assessments and reviews. EVALUATING RISK MANAGEMENT: *Evaluate your project risk management activities. *Document the risks you took, record how they turned out, and make suggestions about how you would change your approach on future projects. DEVELOPING CONCLUSIONS/RESOLVING OUTSTANDING ISSUES: *Develop conclusions and make suggestions. *Review the team's velocity and the project story boards, and use that information as you forecast new projects. Describe what you think you should start doing, what you should keep doing, and what you should stop doing on future projects. *Make sure all grievances and conflicts are addressed before moving on to new projects. *Retrospectives may become emotional and conflicts may arise as teams review their performance. Reiterate with the team that retrospectives are a time to discuss what happened in the project, not to place blame for issues or problems. Moving on to new projects without resolving conflicts can cause hard feelings to be carried over and negatively affect team members. *Don't release team members to other projects until you have completed all project closure activities. *Make sure the team is available to complete any last minute items, clarify inconsistencies, and discuss lessons learned. PLANNING FOR FUTURE PROJECTS: *Develop a plan of action for future projects. *Decide how you will incorporate the lessons you learned from this project into upcoming projects. Make sure that any items and requests that weren't included in this release are included in subsequent release planning. -Most importantly, you have to ensure that project retrospectives are not just meetings to rehash material that the team has already covered. Unless attendees see actions and results from these meetings, they will consider retrospectives to be unproductive and may stop attending. Retrospectives should be constructive meetings that collect information but also provide plans for putting that information into action on future projects.

Agile methodologies

-Under the Agile umbrella, there are multiple methodologies that can be employed to manage projects. Most of the methods listed below were used initially in software development, but many of the tools and techniques can be adapted for other projects. *Extreme Programming (XP): a software development methodology that emphasizes simplicity, often employing pair programming (where code is written by two developers working at a single workstation) and a cycle of frequent testing and feedback. "a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation." XP is one of the more popular Agile methods and is used extensively, especially in information technology and development organizations. **pair programming: One person creates the product, and the other reviews the product as it is being created. It provides continuous, real-time product review, increases product quality, and improves team communication. *Scrum: a lightweight, incremental framework for project management, making it a very popular choice for people who are new to Agile assimilation. Named after the scrum in rugby, Scrum relies on the close interaction of project participants to develop, monitor, and adapt to evolving working conditions. The Scrum Alliance explains the methodology as a framework in which "Work is structured in cycles of work called sprints—iterations of work that are typically two-to-four weeks in duration. During each sprint, teams pull from a prioritized list of customer requirements, called user stories, so that the features that are developed first are of the highest value to the customer. At the end of each sprint, a potentially shippable product is delivered." *Dynamic Systems Development Method (DSDM): an iterative and incremental methodology that stresses continuous user/customer involvement. It was initially based on rapid application development (RAD), which employs minimal planning to allow for rapid prototyping. The DSDM Consortium emphasizes several key principles that include meeting business needs/value, actively involving users, empowering teams, ensuring frequent delivery, employing integrated testing of components/products, and collaborating with stakeholders. A fundamental assumption of DSDM is that nothing is built perfectly the first time and that the focus should be on delivering the 80% of the software that can be deployed in 20% of the time. *Feature-Driven Development (FDD): a model-driven, short-iteration approach to software development. FDD utilizes five stages—modeling, feature lists, planning, design, and software construction—in its approach. *Agile Unified Process (AUP): a simplified modification of an iterative software development process framework known as the IBM Rational Unified Process (RUP). AUP employs test-driven development (TDD), Agile Model Driven Development (AMDD), Agile change management, and database refactoring. **refactoring: The rewriting of existing source code to improve its design, readability, or structure without changing its fundamental behavior. *Lean: applies the principles and practices of Lean manufacturing—a methodology that focuses on eliminating waste (i.e., all of the steps or processes that do not add value to the final product or service)—to the development of products. Removing waste from development processes ensures that process outputs reflect only those characteristics that customers want or value, and reduces the time to market for product releases. *Crystal: a family of methodologies that focuses on the people involved (rather than the processes, architecture, or tools) in a project. Crystal methodologies start with practices that are slightly smaller than needed and "stretched" to a size that is just big enough to encompass the project. By stretching the practices, teams decrease overhead and bureaucracy while still meeting project needs and demands. *Kanban: uses a kanban board to limit the amount of work in any one stage or phase of a project. Limits are placed on the amount of work that can be underway at one time, and new work can only be initiated after existing work has been completed. This "pulling" of work ensures that practitioners do not get overwhelmed or try to multitask (which may cause delays and/or a decrease in the quality of outputs). The Kanban method is especially helpful in situations where the workload or introduction of new requirements varies; teams focus on moving a limited amount of current work through the system without worrying about how many tasks or responsibilities are waiting in a work queue. **kanban board: A story board that shows how many user stories are included in each phase of a project. Also known as a task board. *Scrumban: a hybrid of the Scrum and Kanban methodologies. Work is organized into short sprints or iterations (as it is in Scrum), and kanban boards are used to visualize and limit the amount of work in each portion of the project (as per the Kanban methodology). Teams hold daily collaboration meetings in front of the kanban boards to plan and monitor ongoing work. When the amount of work in a stage falls below preset limits, work is pulled into the stage and the project continues. *Scaled Agile Framework (SAFe): allows an organization to scale its Agile practices to larger or more-complex levels. It synchronizes work and deliverables across large portions of an organization, employing a "systems thinking approach" that takes into account the interactions between projects and among organizational departments to ensure the best overall cadence of work and work cycles. *Large Scale Scrum (LeSS): extends the Scrum framework across several teams simultaneously to deliver one large-scale deliverable. It coordinates multiple teams who are working together on the same requirements, using agreed-upon tools and techniques in a minimalistic way to achieve objectives. *Disciplined Agile (DA): a streamlined approach that combines aspects of several other Agile methodologies to allow for simplified decision making and incremental/iterative solutions. It can be scaled to enable organizational learning and application of Agile practices across an entire project life cycle. It applies common patterns across a network of cross-functional teams in complex environments.

Waterfall v Agile PLANNING

WATERFALL: -Establishes requirements at the start of the project -Estimates the cost and schedule of the project -Uses highly disciplined planning to control the project AGILE: -Establishes cost and schedule at the start of the project -Begins with user goals and tasks ("user stories"), then focuses on surfacing features through the process (rather than "pre-planning" them) -Responds to changing requirements as the project evolves

Executing the Work in an Iteration (Stage 3 of the Agile development cycle)

-After the iteration is planned, the project team must ensure that work will be completed. Individuals on Agile teams take responsibility for finishing their work on each iteration. Daily stand-ups (Daily Agile project meeting held to provide a status update to team members; also known as daily scrum or daily huddle.) help to keep team members focused; these 15-minute meetings (which should be attended by all team members) allow each team member to explain: 1. What he or she accomplished yesterday 2. What he or she is working on today 3. What issues are impeding work progress -These meetings not only make completed work visible to team members but also make sure relevant information is shared on a regular basis. They create peer pressure among team members; each team member is expected to show progress each day and is held accountable by other team members (not by the product owner or other stakeholders) for getting work done. -Teams can demonstrate their progress to stakeholders on story boards (A graphic visual display (such as an information radiator) that summarizes the team's work. Usually presented in a quick, easy-to-understand format that communicates work status and team progress.). Two of the most commonly used story boards are burndown charts and burn-up charts. Burndown charts show how many tasks the team has completed each day and how many tasks remain until the iteration is done. Burndown charts are often drawn as line charts, with time listed on the x-axis and the number of tasks on the y-axis. As the project progresses, the slope of the line decreases until it intersects with the x-axis at the completion of the iteration. Some teams track both the planned burndown and the actual burndown to show how close they will be to an expected iteration completion date. -Burn-up charts also show team progress, but show the accumulation of completed stories rather than the number of stories yet to be completed. The slope of the line in a burn-up chart increases (instead of decreases) to show team progress.

Agile criticism: Agile isn't scalable to larger ventures. It only works for small projects.

-Agile can be used on projects of any size, but it is true that practitioners must develop additional coordination and infrastructure to accommodate the increased complexity. For example, large Agile projects don't use bigger teams; they add more teams and plan integration and communication practices to ensure that teams still work quickly and collaboratively. Work is distributed and synchronized across teams in team coordination meetings such as the scrum of scrums. Organizations often create sub-teams that have their own product managers/owners, project managers, and team members who focus on delivering an increment of work to another team. An additional coordinating iteration may be required to prepare the organization for scaling Agile practices and may even add items to the product backlog to deal with scaling issues. But no matter how large these projects may be, the basic tenets of Agile still apply—practitioners must self-organize into teams that deliver complete increments of products in quick iterations.

Agile customer and stakeholder involvement

-Agile development involves customers and stakeholders early and often in the project work (rather than waiting until the end of the project to solicit their approval). Early stakeholder involvement allows teams to uncover issues quickly and to find them early in the project, when the time and effort to make adjustments is minimal. Products should evolve with the correct functions and features, not "guesses" of what the team thinks the customer wants. -Inherent in the idea of Agile development is the knowledge that the customer's needs and wants have been properly collected and compiled. The project's vision for what the product should be is an extremely important part of Agile projects. That vision often comes from the project's product owner (Scrum-specific term for the person who represents the customer, user, or other stakeholders in an Agile project. The product owner manages the work queue, answers the team's questions, and works with the team to decide what each iteration will entail. Also called the product manager.)—the person who represents the customer, user, or other stakeholders; who prioritizes their requirements; and who answers questions the team may have so they can progress in the appropriate direction. The product vision may also come directly from customers, through a technique called the Voice of the Customer (VOC) (A market research technique for establishing a detailed set of prioritized customer wants and needs.).

What is Agile?

-Agile development is a form of project management/product development based on a series of iterative, incremental improvements. -Agile approaches have become increasingly popular for organizations that need to deal with rapidly changing customer and market requirements. -While the phrase "Agile development" was first coined in 2001 in "The Agile Manifesto," the concept of iterative improvement, one of Agile's fundamental principles, has a rich and varied history that dates back to the 1950s (or earlier, depending on how broad a definition you use). -"Agile development" is often used as a shorthand for "Agile software development," because software developers are by far the most active and passionate proponents of Agile concepts. -Project managers and knowledge workers of all types should be able to apply Agile principles to their workflow to be more productive and efficient. -The fact that many practitioners regard Agile as a broad philosophical approach, rather than a specific methodology, means that there are a number of varied definitions. -Agile author and pioneer Jim Highsmith has characterized agility with two statements: 1. "Agility is the ability to both create and respond to change in order to profit in a turbulent business environment." 2. "Agility is the ability to balance flexibility and stability." -The Agile Sherpa website describes it as "a common umbrella term used for today's highly iterative and incremental approaches to software development" and adds, "The overarching focus of Agile development projects is the frequent delivery of high-quality, working software in the form of business-valued functionality."

Agile criticism: Agile can't produce consistent work because it doesn't document its processes so others can replicate the results.

-Agile is not designed to replicate results; it is a method designed to produce innovative products in whatever way works best for the team. Agile processes are what Alistair Cockburn calls "barely sufficient" and what Jim Highsmith calls a "little bit less than enough"; they provide enough structure to guide practitioners but are flexible enough to allow a team to customize its work to best advantage. Agile practices are not prescriptive processes that constrain the team's work and development; instead they free the team to work as efficiently and effectively as possible to develop the right product.

Value stream mapping

-Agile methodologies are very good at encouraging agility in teams but, to be effective, practitioners need to look at an organization's entire process—from product concept to customer delivery. Lean practices encourage this approach by developing value stream maps. -Value stream maps are graphic representations of all of the work and work processes an organization completes to create and deliver products. It lists all of the process steps as well as the delays and non-value-added work that create waste in a system. By visualizing the system as a whole, teams can minimize cycle time (The total elapsed time to move a unit of work from the beginning to the end of a physical process, as defined by the producer and the customer.) and eliminate waste to improve the total time it takes to deliver value to customers.

Agile criticism: Iterations allow Agile projects to go on forever, always adding more features to products but never finishing them.

-Agile projects are done when the customer decides they are done. When a product contains enough new features to satisfy customer requirements, the product is "finished" and released to the customer for use. Iterations are simply the timeboxes that the development team uses to contain development actions and ensure consistent feedback and adaptation of products. Features may be added to products but only after ensuring that they add value to the customer and only if they can be completed before the release date. In Agile projects, more often than not, the release date is a fixed constraint; whatever is completed by the release date is included in the finished product.

Agile Team Dynamic

-Agile teams need to be staffed with the right people—that is, team members who have the correct technical and interpersonal skills and can work with minimal supervision. They must be comfortable with change and be able to work with processes and practices that allow change to occur. They must understand the project's boundaries and then work autonomously within those boundaries. They will make decisions in conjunction with other team members and collaborate with customers to shape products and adapt to inevitable changes. They'll hold each other accountable for accomplishing the work that the team agreed to do, and they'll hold themselves accountable to get results. They must consistently share information, help the team overcome obstacles, and meet their goals.

Agile Team Environment

-Agile teams work best in an open, collaborative environment. Once the tasks for an iteration have been agreed to, team members need to be able to work together to develop the best solution to the project at hand. -To ensure this will happen, Agile organizations need to develop what is called an empirical process—one that sets the boundaries of the project but lets the work processes develop as needed within those boundaries. Team members must be allowed to explore new approaches to problem-solving and to adapt as needed. They must be trusted to produce results with little interference or interruption from stakeholders. And they should be physically co-located, to allow them to collaborate, solve problems, share ideas, and develop innovative alternatives. -Agile is designed to be a self-correcting process; at the end of each iteration, the lessons learned are used to make adjustments. But Agile teams still need planning and some documentation to succeed. Not planning for potential risks can lead to catastrophic results, and relying too much on adaptation at the end of each iteration can lead to project delays and increased rework as adjustments are made and re-made. Planning is still important for Agile projects, but practitioners must always remember that following the plan is not the goal; making the right product is the goal. -An effective Agile environment is a learning environment; it allows for continuous innovation and adaptation. It supports the team in accomplishing its work, with little management oversight and a quick return on investment. It creates a space where staff feel empowered and free to explore and contribute their skills to the creation of exciting results. It establishes a competitive advantage because it delivers products to the market faster and at a lower cost.

Agile criticism: Agile only works for co-located teams.

-Although Agile generally works better in teams that have frequent face-to-face interaction, Agile can work for distributed and dispersed teams as well; it just requires more effort and a focus on better communication and information distribution techniques. Distributed and dispersed Agile teams should strive to communicate verbally as often as possible, using telephone conversations and videoconferences to ensure consistent collaboration. They should develop virtual story boards and wikis (Websites used collaboratively by many users to share information of mutual interest. The content and structure of wikis can be edited and modified by anyone with access to them.) to keep information flowing on a consistent basis. And they should limit nonverbal communications (email, memos, and other written documentation) to prevent assumptions and misunderstandings from creeping into the team process. It is not impossible for these types of teams to be Agile; it just takes a little more effort.

Agile criticism: Agile software development is just cowboy coding

-Although both Agile and cowboy coding (An undisciplined software development method that gives developers autonomy and control over many project parameters (scheduling, quality, code style, etc.). Cowboy coders write code according to their own rules (often leading to rework when others try to work with the code), and customers are largely left out of the process (which often results in unsatisfactory products).) allow the development team significant flexibility in the ways it accomplishes its work, they are dramatically different. Cowboy coding relies on the product developer to decide which features the product will contain; as a result, cowboy-coded products may not include features that satisfy the customers' real wants or needs. In contrast, Agile relies on continuous input from customers and other stakeholders to shape the product, ensuring that the product remains up to date and satisfies the latest customer requirements. Cowboy coders also focus intently on the current work-in-progress with little regard for subsequent product versions and product adaptability. Agile practitioners devote considerable amounts of energy to ensuring that products have low technical debt and are easily adaptable in future iterations.

Agile team role: project manager

-An Agile project manager doesn't control projects as much as he or she facilitates them. The Agile project manager has little or no authority over the team (for example, assigning work or directing tasks) as the team is meant to be self-directed by design; instead, the project manager focuses on the Agile process and on enabling the team. He or she looks to keep team members focused on their goals, while also striving to ensure that the Agile processes are free from interference and outside distractions. For example, the project manager should prevent stakeholders from delaying or interrupting work-in-progress with requests for additional product features or more-frequent review processes. -A project manager ideally should be technically proficient in the processes used to create the product; this will help not only in translating technical terms into simple language when dealing with the product owner but also in assisting and training team members in communicating with non-technical people.

Reviewing the Product Created in an Iteration (stage 4 of the Agile development cycle)

-At the completion of each iteration, the team meets with the product owner, customers, and other stakeholders to demonstrate the products they created in the iteration. These iteration reviews are short meetings (roughly two-to-four hours in length) that present team results as simply as possible, with little or no fanfare or complex presentations. The team presents complete working products—not prototypes or documentation describing how the product would work—to customers and stakeholders for review and analysis. -Stakeholders and customers ask questions about the product and provide feedback, which the team then translates into new customer stories and adds to the product backlog for inclusion in subsequent iterations. The lessons learned from iteration reviews allow products to evolve as users and customers interact with working products and voice new expectations and needs.

Structure in Scrum projects

-Scrum projects contain a more-rigorous framework than other Agile projects—one that still allows practitioners to adapt to changing conditions but reduces some of the confusion or distractions that could derail progress. This increased structure can be seen in: *Well-defined roles: With Scrum, a product owner or scrum master can be a team member, but product owners can never be scrum masters and vice versa. Combining these roles can cause confusion and a conflict of priorities. *An increased reliance on timeboxes: Tasks in the sprint backlog must take no longer than one work-day to complete. Sprints are limited to two-to-four weeks in length. Sprint planning meetings are capped at eight hours—four hours to review the product backlog and four hours to plan the sprint. Sprint reviews and sprint retrospectives are each limited to one half-day in length. And, of course, daily scrums are limited to 15 minutes. *Restrictions on team size: Scrum teams should involve at least five members, but no more than nine members. Teams with fewer than five members may have difficulty completing all of the tasks in the sprint backlog on time; teams with more than nine members would require additional communication and integration activities that take the team's focus away from completing project tasks. *Additional rules for team meetings: Sprint planning meetings involve only product owners, scrum masters, and team members; no other stakeholders are included. Daily scrums are held at the same time in the same location each day. All team members must attend and contribute to daily scrums but observers are not allowed to provide input. Team meetings end on time, no matter how much additional material could be covered by adding a few minutes. *Stricter enforcement of rules or guidelines: Only team members are allowed to change the sprint backlog, based on their review of their progress and understanding of the tasks in progress; scrum masters and product owners are not allowed to modify the tasks involved. Burndown charts are updated each day, after the daily scrum.

Beginning the Next Iteration or Releasing the Product to the Customer (stage 6 of the Agile development cycle)

-At the end of each development cycle, the project team either releases the product to the customer or begins the next iteration in the project. -The development cycle previously described is part of a larger organizational cycle—the release cycle. The release cycle specifies when an organization will release products to its customers. The release plan documents the product release dates; these dates may be set by either: *deciding what date an organization wants to release a product (based on market research or customer requests), then determining how many features can be completed before that date, or *deciding how many features to include in a new product, then determining how long it will take to complete those features. RELEASE CYCLE: A larger product development cycle that includes multiple iterations and results in the transition of a finished product to production, operations, or the customer. -Release plans become more detailed as Agile teams mature. As teams complete more iterations, their velocity becomes better understood and release dates can be estimated with greater accuracy. Once a product is released, the organization reviews its product roadmap and begins to develop new products in a new round of release planning (Process in which an organization decides when it will release products to customers).

comparing terminologies

-Because Agile is a combination of several methodologies, the lexicon includes many similar terms, or synonyms for terms borrowed from other business areas. -AGILE PROJECT MANAGER: coach (XP), lean six sigma black belt (Lean Six Sigma), process facilitator, scrum master (Scrum), tracker (XP), team lead (DSDM) -COMMON WORK AREA: caves and common room (XP), war room, whole team room (XP) -CONTINUOUS TESTING STRATEGY: defects per million opportunities (Six Sigma), test-driven development (XP) -DAILY TEAM STATUS MEETING: daily reviews, daily scrum (Scrum), daily stand-up (XP), daily wash-up (DSDM), morning roll-call (FDD) -IMPEDIMENT: issue, obstacle, risk (Project management) -LIST OF UNRESOLVED PROBLEMS: operational backlog, parking lot -LEARNING STRATEGY: adaptive planning, double-loop learning, inspect and adapt, kaizen (Lean), reflective practice -ORGANIZATIONAL STRATEGIC VISION: big plan (XP), outline plan (DSDM), product roadmap, project charter (Project management) -POTENTIALLY SHIPPABLE PRODUCT: deliverable (Project management), minimally marketable feature, product increment, sashimi (Scrum), vertical slices of functionality -PRODUCT MANAGER: ambassador user (DSDM), business analyst, customer (XP), customer proxy, product champion, product owner (Scrum) -REQUIREMENT: feature, product backlog item (Scrum), user story (Scrum and XP), work package (Project management) -RETROSPECTIVE: debrief, lesson learned meeting (Project management), post-mortem, reflection meeting, review meeting, weekly review -SCHEDULE INCREMENT: cycle of work, iteration, sprint (Scrum), timebox (DSDM), work cadence -SELF-ORGANIZING TEAM: chickens and pigs (Scrum), cross-functional team, development team, high-performance team, product team, real team, whole team (XP) -STORY BOARD: big visible charts (XP), information radiator, Kanban board (Lean), scrum board (Scrum), task board -TASK: activity, engineering task (XP), sprint backlog item (Scrum) -TASK LIST: activity list (Project management), components, sprint backlog (Scrum) -WORK PRIORITIZATION STRATEGY: backlog grooming, backlog prioritization -WORK QUEUE: business requirements, development plan (DSDM), prioritized list, product backlog (Scrum), stories (XP), to-do list, work-item list

Lean portfolio management

-Because Lean practices encourage practitioners to look at an organization as a whole, they are particularly useful in managing company portfolios. Lean portfolio management ensures that an organization has the right mix of products in production while correctly matching that production to the capabilities of its teams. It helps organizations allocate resources to the right projects or tasks at the right time, preventing the misallocation of resources to noncritical tasks and projects. It helps companies improve processes to ensure that projects work together to provide the most value to the organization. It looks at all of the organization's product lines and ensures that all of its teams work effectively to produce high quality products that will have the greatest return on investment for the company. -Lean portfolio management isn't about maximizing resources to their fullest extent; it's about delivering value to customers and to the business.

Agile Team Leadership: best practices

-By integrating the following ideas into your leadership practices, you can effectively lead Agile teams to successfully accomplish project goals: ACCOUNTABILITY: *Provide accountability and team guidance *Maintain a balance between a long-range, strategic approach and short-term tactical decisions. Work with the team to achieve immediate results, but remember also to keep an eye on long-term problem-solving and decision-making issues. *Help the team arrive at a clear purpose and unmistakable goals. Clearly state the organization's expectations of the team, and continually reinforce the project's stated intention and success criteria. *Don't evade your responsibility. Empower the team and authorize them to make the decisions that are within their control, but don't sidestep your duties by transferring total accountability to the team. Don't leave team members to make decisions where they lack appropriate authority or don't have the proper context. COMMUNICATION: *Maintain a constant flow of information *Use story boards and burn charts to keep stakeholders aware of team progress and to relieve the team from constantly having to answer questions. Regularly update status charts and story boards so that the most-recent information is available to everyone at all times. *Use direct, unambiguous language to present information and to clearly express your thoughts and ideas. *Encourage participation in the decision-making process. Value the input of others by collecting ideas and opinions before making decisions. BOUNDARIES: *Set project boundaries but allow the boundaries to fluctuate *Allow practices to evolve but keep them simple. Remove redundancy and waste, and review practices regularly to ensure that they remain efficient and effective. *Keep the team objectives aligned with project requirements. Continue to prioritize requirements to keep the team focused on satisfying customer needs. Enforce a disciplined project approach. Make sure the team follows Agile guidelines and uses Agile practices to meet project goals. DEVELOPMENT: *Develop the team *Make sure team members continue to learn new skills, apply new tools and techniques, and improve individual and team competencies. Provide training opportunities and encourage exploration and continuous improvement. *Express a belief in your team members' abilities to solve problems and develop solutions. Encourage autonomy so team members exercise their own judgment, and express trust in team decisions. MOTIVATION *Motivate the team *Establish high expectations for yourself and your team. Expect team members to adopt a belief that they will continue to achieve goals and produce successful outcomes each time they take on new challenges. *Keep team members engaged. Exhibit enthusiasm and excitement for team progress and celebrate the team's successes. -By focusing on supporting and enabling the team, Agile leaders eliminate distractions and provide a framework within which the team can do what they do best—create products that satisfy customers.

Agile criticism: Agile is no better than the methods we use now. I'm comfortable with the system we have in place. Why do we need to change it?

-Change is inevitable in today's marketplace and only those organizations that are capable of responding to altered market conditions will survive. Meeting the needs of customers is a key for success today and Agile offers a way to meet that need. This typically means the organization must challenge old processes and old ways of thinking in order to innovate and excel. -"Traditions must be challenged—doing nothing is a mistake."

handling conflict on Agile teams: best practices

-Conflict can be constructive—particularly if the ensuing team interplay leads to a deeper understanding and resolution of the issue—but more often than not, conflict derails teamwork. And because teams play such an important part in Agile practices, any team dysfunction can be extremely disruptive. -One common source of conflict for Agile teams is a lack of trust among team members. Agile teams depend on a feeling of mutual trust; team members must believe that everyone is working for the good of the team, not in their own best interest. For example, team members must be confident that individuals are selecting tasks from the task list because the tasks are the most important ones to complete, not because they are the easiest or most enjoyable to work on. All team members must trust that they can ask for assistance without fear of judgment or repercussions; after all, one of the responsibilities of the team is to develop generalists with diverse skills, not to encourage specialists to jealously hoard their expertise. Teams must also guard against developing "heroes"—people who select all of the difficult or lengthy tasks from the task list because they feel it will help other members of the team or increase their own stature in the organization. By taking these complex tasks away from less-experienced team members, these "heroes"—even if they are well intentioned—may damage team confidence and stifle team development. -tips for dealing with conflict: INTERNAL RESOLUTION: *Let team members try to resolve conflicts themselves *When conflict does occur, it is important to remember that, as an Agile leader, you are leading the team, not managing the team. Just because you think there might be a conflict doesn't mean you should rush in to resolve it. Wait to see if the team members can resolve the conflict themselves. Just as they are empowered to choose the best way to meet the project objectives, team members must also be encouraged to resolve conflicts and improve working relationships without intervention. EXPLANATION: *Explain the new conflict resolution approach *This new way of resolving conflicts may cause problems, especially in organizations that are transitioning from a traditional Waterfall methodology to Agile practices. If management (and other stakeholders) believes that part of your work as a leader is to solve the team's problems, they may think that you are not doing your job if you leave the team to try to resolve the conflict by itself first. You will need to clearly explain that allowing the team to solve its own problems creates long-term benefits for the team, not just a short-term fix to an individual problem. By doing so, you are developing more people with the skills to solve problems, which benefits the entire organization. INTERVENTION: *Help the team resolve conflicts that it can't settle *If the team is unable to resolve the conflict on its own, you will have to step in to help them develop a solution. It might be helpful to familiarize yourself with the different approaches experts use to deal with conflict. By acquainting yourself with each of these approaches, you will be able to select the best one to employ in each situation to bring it to an effective resolution. *In some cases, you may have to encourage reluctant team members to confront the people they are in conflict with. Agile coach Lyssa Adkins has devised a "three-step intervention path" to help unwilling team members face this issue. Her suggested steps, in summary, are: 1. First, ask the team member if he or she has shared this issue with the other party. If not, encourage him or her to do so. 2. Then, offer to accompany the team member as they discuss the conflict with the other party. However, make it clear that you are there to provide moral support, not to present the issue yourself. 3. Finally, if the team member is still reluctant to approach the other team member, suggest that you alert the other party to the conflict so the parties can come together to address the conflict directly. Be sure to explain that you will tell the other party who came to you with the complaint—relaying anonymous complaints is unfair and will not be helpful in resolving the issue. *If team members are unwilling to accept any of these options, Adkins suggests that you let the matter drop. To effectively resolve conflicts, both parties must see the issue as a mutual problem and be willing to explore options together. If they are unwilling to do so, you will be unsuccessful in trying to impose a solution on them. -For teams that learn to resolve problems on their own, conflict can become a useful tool, rather than a painful or destructive one. These teams use conflict to uncover issues that impede progress and to clarify issues that prevent success. The adversity that high-performing teams overcome actually strengthens the team and teaches them new skills. But any resolutions that teams develop must solve conflicts while still respecting the people involved.

Agile criticism: Agile is an undisciplined approach.

-Critics often complain that Agile is undisciplined because they confuse imposed discipline with self-discipline. Because they can't see documented rules and regulations that have been imposed on the team by outside stakeholders, they assume that those rules don't exist. But Agile's discipline comes from within the team, not from outside of it. Instead of relying on strict rules and regulations from senior managers or a project management office to direct team work, team members hold themselves and their teammates accountable—they are responsible for delivering a product in each iteration that is complete, free of defects, and valuable to customers before they can move on to subsequent work.

Agile team role: customers and stakeholders

-Customers and key stakeholders (including senior management and project sponsors) are much more involved in Agile projects than in Waterfall projects. They provide product requirements, just as they do in traditional projects, but then continue to be actively involved in the development process by reviewing iteration results and providing regular feedback. This continuous review helps uncover hidden or unclear requirements that the team can use to modify products. Customers also indirectly set product release dates by defining the minimal amount of functionality they will accept as a new product. -Senior management and project sponsors must accept the boundaries set by the team and understand that not all requested product specifics will be included in the current iteration (if the team finds that they will not fit in the timebox for that iteration or that other requirements of higher priority need to be addressed first). And management may need to adapt their performance assessment systems as well; with Agile, the idea is to measure the results achieved, instead of measuring the time spent on tasks or the costs incurred. A failure to move from an assessment system focused on time and costs can cause a team to cut corners to achieve these measures, which will result in products of poorer quality and negate Agile's advantages.

Extreme Programming (XP)

-Extreme Programming (XP) is a highly collaborative Agile methodology that relies on extensive communication and interaction among team members. -Because it began as a software development process, XP has more of an engineering-bias and less of a management-focus than other Agile practices. It centers on the technical aspects of Agile practices—directing its efforts inward to help product developers create products—and incorporates a considerable amount of automation in its practices. -XP works best on projects in highly technical environments that contain vague or rapidly changing requirements. XP "is designed for small, collocated teams aiming to get quality and productivity as high as possible. It does this through the use of rich, short, informal communication paths with emphasis on skill, discipline, and understanding at the personal level, minimizing all intermediate work products." -The method was dubbed "Extreme Programming" because software programmers were taking software development "to the extreme." Practitioners decided that "if some is good, more must be better," arguing: *If reviewing software code is a good idea, then it should be reviewed constantly as it is developed. *If testing helps create better products, then automated tests should be run multiple times a day. *If integrating code helps uncover problems, code should be integrated every day. -Continuously replicating the parts of development that add value to the product helps XP teams develop products of better quality that satisfy more customer needs. -XP is based on four core values—communication, simplicity, feedback, and courage.

Agile product backlog: best practices

-For Agile projects to be successful, a carefully constructed and correctly prioritized product backlog is critical. If the backlog is incomplete or inaccurate, an Agile team may expend time and energy creating features or products that don't satisfy customers' real needs. The requirements listed in the backlog must accurately describe what customers want and deliver the value that they are requesting. -Requirements in a product backlog may be incorrect or misleading due to several common causes: *If the product owner is working on too many projects or has too many responsibilities to fulfill, he or she may not collect or prioritize items in the backlog appropriately. You may need to reapportion work to ensure that it is completed accurately and is ready for selection by the team during iteration planning. For example, several individuals may need to take responsibility for items in the backlog (rather than having one product owner maintain all of the items in the backlog) to ensure that they are ready for planning. *The product owner must have a working knowledge of the product so he or she can speak constructively with stakeholders and team members. The product owner must also have a deep understanding of the customer and the market, to ensure that the requirements are truly of value. If your product owner lacks the skills or knowledge to manage the product backlog correctly, you may need to provide training or reassign the owner to other tasks. *Product owners must have access to the right customers—ones who are knowledgeable enough about the product to provide useful feedback and to describe requested features in enough detail to be helpful to the project team. Make sure that your organization has a clearly defined view of its customers and that it shares information about customers across teams and departments. Establish strong relationships with customers and develop simple ways to collect and verify their feedback (for example, with customer surveys and interviews, focus groups, iteration reviews, and direct observation of their work). *Customer needs should be descriptive enough to be understood and helpful to team members in planning for iterations, but must not be so overly specific that they constrain the team's options to fulfill the requirements. Writing accurate requirements can be difficult for new product owners and they may need to undergo training to be able to do it accurately. Teams may also need to push back on product owners if the requirements are not described with enough accuracy. Some teams have even included a ready definition (much like the definition of done) for its requirements; requirements must be configured correctly and be "ready" for use in iteration planning. If a requirement is not written in a way that is complete and helpful to the team, it is sent back to the product backlog for additional information and reprioritization in later cycles. *If the product owner is focused on optimizing the production process instead of satisfying the customer, he or she may place more emphasis and higher priority on items that don't provide the greatest amount of customer value. Agile products are designed to give the customer the greatest value possible; to do so, you need to make sure your product owners (and other customer proxies) reflect the needs of actual customers and that they are intently focused on current market conditions and demands.

Nokia Test / Scrum But Test

-In 2005, Nokia created "The Nokia Test." This test included eight questions that determined if Nokia teams were using the Scrum methodology completely and correctly. In 2007, Jeff Sutherland modified the test by including a scoring system, adding a question, and renaming the test "The Scrum But Test." -The test was designed to provide quick, clear answers to make sure that a team's Agile practices were robust enough to be called Scrum, yet simple enough to be understood by the people involved. The test does not cover all of the aspects of Scrum, but it does cover its core principles and has proven to be an effective indicator of the ability of Scrum teams to produce great products. If teams can pass the test, they are truly practicing Scrum, and are likely to produce extraordinary results. If they cannot pass the test, they can't say that they have really been practicing Scrum. -To complete the test, each team member must rate each of the following on a scale of 1-10: *the length of project sprints *the testing done within each sprint *the quality of the requirements and customer stories *the role of the product owner *the quality of the product backlog *the estimates produced for the project *the burndown charts *the number of disruptions encountered by the team *the ability of the team to work together to complete its tasks -The team determines an average score from the nine questions; an average score of seven or below suggests that the team is not employing Scrum techniques to its best advantage. Team scores can be compared to other team scores, computed for the entire organization, or compared to previous tests to gauge progress.

Optimizing the whole

-In Lean Software Development, management and teams work together to "optimize the whole"—they focus on improving the work of the entire organization rather than focusing on improving the work of individual teams. They plan product releases to deliver value to customers and to deliver value to the business itself. They implement Lean practices across the organization, coordinating management, production, and delivery work to one goal—minimizing waste while increasing quality and the speed of delivery.

employing Agile in diverse industries

-In many cases, project managers in non-software fields have applied modified Agile concepts to their work: *Developing processes that allow them to be continuously innovative *Using short execution cycles to constantly refine the work they do and to produce progress in increments *Collaborating with customers in adapting their products *Incorporating lessons learned into the ongoing project *Adapting their management styles for more flexibility and independence for project and product teams

Agile in the corporate environment

-Some large corporations have seen the value of Agile principles, not only in project management, but also as a management philosophy. -Agile's emphasis on self-organizing teams and on decentralized decision-making can be problematic for organizations with hierarchical management processes. Many managers, conditioned to elaborate documentation, struggle with Agile's preference for face-to-face communication and simplicity in documenting plans and progress. -It's not hard to see why the culture of some traditional companies is hostile to many of the elements that make up a successful Agile project. Yet the ability to cope with changing requirements (from customers and markets), which is a key feature of Agile, represents an opportunity for companies who can employ Agile principles and can do so for competitive advantage.

Agile to Lean Principles

-In many ways, Agile is an application of Lean principles: *Lean Principle: Have teams collaborate to optimize work; Agile application: Create self-organizing teams *Lean Principle: Implement practices "just-in-time"; Agile application: Wait until work is needed to analyze, design, and execute *Lean Principle: Determine what customers value; Agile application: Collect feedback in iteration reviews and incorporate adjustments into subsequent iterations *Lean Principle: Deliver value to customers quickly; Agile application: Create products as increments and release them to customers as early as possible *Lean Principle: Build quality into the system; Agile application: Develop generalists who can test for quality and implement test-driven development *Lean Principle: Configure work into groups or cells that can complete all of the tasks needed to finish the work in "one-piece flow"; Agile application: Develop teams that agree on a definition of "done" and can produce increments that satisfy all selected requirements *Lean Principle: Reduce error in the system; Agile application: Incorporate feedback from iteration retrospectives to improve work *Lean Principle: Minimize complexity and non-value-added work (Any activity that, in the eyes of the customer, does not increase the usefulness or worth of a product or service; non-value-added activities may be necessary for business purposes (such as invoicing) but are not something that customers value enough to pay for.) to increase the speed of delivery to customers; Agile Application: Plan individual increments and iterations to address only the work immediately needed

Kanban

-Kanban is a lean practice that focuses on the flow of work in projects. As teams complete increments, work is "pulled" from a work queue to begin new iterations. New work is added to the queue to fill empty spots. -Kanban manages the work-in-progress during a project, and eliminates potential waste by limiting the need to estimate parts of a project that may not be attempted.

Lean software development

-Lean Software Development is an Agile methodology that adapts the Lean practices and principles of the Toyota Production System to Agile work. The methodology is based on several basic beliefs: *Errors occur because of the system that people work in, not because of the people themselves; the system allowed errors to occur because it is flawed or incomplete *The people doing the work are closest to it, so they best understand how it can be improved *Trying to improve each individual step in the process is less important than improving the process as a whole; improving individual steps may actually impede other process steps *The most efficient teams are ones whose work is limited to their capacity *Successful systems limit the amount of time between idea generation and delivery to customers *Limiting inventories and the amount of work-in-process can improve team efficiency

Applying Agile to NPD (new product development)

-Many non-software companies have integrated Agile processes into their NPD process. Examples include: *Flexible Product Development (FPD), which allows for changes in the product being developed or in how it is developed, even relatively late in development. FPD stresses anticipation, responsiveness, and skill in delaying decisions. "In general, the approach is to keep the cost of change low for as long as possible and to recognize areas that have high costs of change so that change can be avoided in them. This implies actively building and maintaining options." *"Loose-tight" planning, where the product development team alternates between periods when the plan is frozen ("tight") and periods where changes in the plan are allowed ("loose"). Boeing used a variation of this technique in developing its 777 airliner. *"Simultaneous execution," where product development stages or activities that are usually executed in sequence are instead done in parallel. Honda has employed simultaneous execution in developing new cars. (Simultaneous execution adds risk to the process, especially if there is the potential for a project being canceled.) *"Spiral development," where product teams quickly prototype a new product and seek customer feedback to allow for design changes. -Agile development provides an NPD option when creating high-quality products and rapidly introducing them to market are an organizational priority. Frequent Agile iterations allow products to evolve, ensuring that they meet current needs. Agile product development allows for multiple products or solutions that can meet customer needs (rather than a traditional project management approach that creates plans with one product or solution in mind). Successful products should meet the current expectations and needs of the users, not the requirements estimated and set forth in an initial plan.

complete products in Agile

-Products produced by Agile teams need to be done* before they can be considered releasable or shippable. (They may not actually be released or shipped but they must be able to be released.) They should be "complete increments of business value." They must have low technical debt (The burden incurred during development due to poor design choices or hasty development. Often made with a disregard for future consequences.) and be adaptable or malleable—a product that is not malleable will have a short life span and any attempts to re-use or modify it in subsequent iterations will result in increased cost, effort, and time-to-market. *done: All portions are complete (as agreed to by all parties) with no perceived changes or corrections necessary. The product can be used by the customer as intended.

Agile team role: coach

-Some organizations employ an Agile coach to help their teams understand and implement Agile principles. The job of an Agile coach is to support Agile practitioners, not to direct them; for example, coaches will expose challenges and help teams employ the Agile framework to solve problems but will not provide the solution themselves. Coaches describe and delineate roles, explain Agile concepts, and answer any questions that arise. They deepen the practitioners' understanding of Agile practices and help team members grow into the roles required.

self-organizing teams

-Team members must understand that once the work boundaries are set, they are accountable for managing their own workload and completing the work on time. They must recognize that all of the tasks in the task list are the collective responsibility of the team; there are no "experts" on the team and any team member may need to work on any of the tasks. Partially completed work is no longer turned over or handed off to another group or department; the team must complete every task in the project. The product owner and project manager are available to guide and advise team members, but no authority figure will direct their activities or tell them how to complete their responsibilities.

the Agile declaration of interdependence

-The Agile Manifesto established the principles for Agile as a discipline. The Agile "Declaration of Interdependence" focused on those management principles conducive to achieving an "Agile mindset" in product and project management. -In 2005, 15 project leaders established the six key management principles of the Declaration: *We are a community of project leaders that are highly successful at delivering results. To achieve these results: 1. We increase return on investment by making continuous flow of value our focus. 2. We deliver reliable results by engaging customers in frequent interactions and shared ownership. 3. We expect uncertainty and manage for it through iterations, anticipation, and adaptation. 4. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference. 5. We boost performance through group accountability for results and shared responsibility for team effectiveness. 6. We improve effectiveness and reliability through situationally specific strategies, processes, and practices.

Creating a Product Vision and Product Backlog (Stage 1 of the Agile development cycle)

-The Agile development cycle begins with the Agile team and customers establishing a clear vision of what the product should be. This vision is expressed in a collection of customer requirements called features or stories. Stories are not technical specifications of the product's size, volume, or performance—instead, they are high-level descriptions of what the user wants the product to do. As such, stories are specifically worded to reflect the customer's intended use and to keep the product focused on meeting customer needs rather than meeting technical specifications. -Stories are often captured on 3"x5" index cards to limit the amount of space available to document requirements. Limiting the available space ensures that the story remains simple and concise and that the requirement description is focused. -Agile product owners compile stories into a product backlog. The product owner, as the "keeper" of the product backlog, continually updates and prioritizes this list, acting on the customer's behalf to ensure that the highest priority items are delivered first. The product owner refines the highest priority requirements (and, therefore, those that are likely to be implemented first) to a greater degree and leaves requirements of lower priority to be refined later. The product backlog may also include requirements that are necessary for the creation and improvement of the product, but that may not be visible to the product's customer. -The product owner then sets the boundaries for the project—what will be delivered, who will be involved, and how the project team will work together. These boundaries are not developed in detail; they include only enough documentation and advanced planning so that the output produces value for the customer. This plan determines how many iterations can be completed before the product will be released to the customer and focuses on increments that meet customer requirements and deliver business value. It also creates a timebox (A preset period of time that constrains how much can be attempted. The imposed time constraints force important prioritization decisions and pressure to complete activities, because the time period cannot be exceeded no matter how much work still remains.) that constrains the time allotted for the project's completion and helps guard against an indiscriminate expansion of scope.

the Agile development cycle

-The Agile development cycle contains six "stages": 1. Creating a product vision and product backlog 2. Planning an iteration 3. Executing the work in an iteration 4. Reviewing the product created in an iteration 5. Reviewing the iteration's processes 6. Beginning the next iteration or releasing the product to the customer -Although the Agile "stages" have been presented here in a linear format, it is important to note that there is significant overlap and several feedback loops among the stages, so the Agile "process" is much more cyclical and iterative than linear.

Agile and product development

-The aim of an effective product development or product management process is to create products that are unique and provide more value to customers than those of the firm's competitors. -There are advantages to employing Agile tools and techniques in NPD (New Product Development); an Agile approach can ensure that the right product features are included. While traditional product development typically tries to plan for every conceivable feature (which is futile because as teams implement plans, the features that customers want often change), Agile practices let the product evolve and allows development processes to adapt quickly, to respond to changing characteristics. -Research shows that customers have a hard time establishing product specifications. They may need to see the flaws in a product before they can figure out what features are needed. They also don't want to wait a long time for the product to reach the market. And they don't want to pay too much for the product—they don't want to be charged for the "overhead" in a project or the parts of the project that don't add value to what they are buying. -Agile development addresses these concerns by: *continuously incorporating new ideas, features, and functions in product increments. *providing a "new" product at the end of each iteration. *streamlining the process to eliminate waste and provide customers with products that meet their current needs. -Agile uses incremental and iterative development cycles to create new products or to modify existing products. Each Agile iteration results in something new with which customers can evaluate and interact. By developing products in increments, Agile organizations create adaptable products (that they can modify into new products at a later date), to consistently ensure that their products meet their customer's current needs and can be modified to meet future needs. And by developing in iterations or cycles, Agile creates complete, innovative, and reliable products that can be released to the market sooner, providing an earlier return on an organization's investment

The 12 principles of Agile software

-The authors of the Manifesto also advocated for 12 supporting principles to help guide practitioners as they employ Agile methodologies: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, then trust them to get the job done.6. The most efficient and effective method of conveying information to and within the development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity—the art of maximizing the amount of work not done—is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more efficient, then tunes and adjusts its behavior accordingly.

Agile team role: product owner

-The product owner sets the project's direction. He or she interacts with stakeholders, continuously working to understand their needs, and to combine all of their requirements into a single voice that shapes the product into a coherent product vision. The product owner achieves the vision by creating and maintaining a product backlog and removing any external impediments to team progress. By focusing on the external elements of the project (the collection of customer requirements, funding for projects, organizational strategic vision, portfolio management), he or she allows the team to concentrate on delivering value to customers.

Planning an Iteration (Stage 2 of the Agile development cycle)

-The product owner then convenes a meeting with the development team to plan the iterations for the project. The product owner discusses the vision for the product, the customer requirements, and the priorities for satisfying those requirements. He or she answers any questions the team may have and provides any necessary clarification or elaboration. Often, the product owner is asked to present the goal of the iteration as a newspaper headline, to quickly convey the vision for the iteration and create a simply shared understanding and focus for team members. -Team members then estimate the amount of work that they believe each story will require. These estimates are often set, not as absolute time amounts (like hours or minutes), but rather as story points* that compare requirements in relation to each other. Because product developers are individuals that work at different rates based on their experience and effort, estimating tasks in hours or minutes will vary depending on which individual is performing the work. Using story points to estimate time is meant to be an independent measure, regardless of who is performing the task. A story estimated at 20 story points should take twice as much work as a story worth 10 story points, which would take twice as much work as a story estimated at five story points. This allows the team to estimate the amount of work it will need to do based on how "big" the task will be, not on how fast it is thought an individual can do the work. -Team members then select those items from the product backlog that they can complete within the time frame for the iteration, and break the items into the tasks needed to satisfy the requirements. They compile the tasks into a task list that they will use as an inventory of the work in the iteration. The tasks are written in the technical language that the team will use to satisfy the requirements. Tasks are often written on the back of the index cards of the customer stories the tasks will address; this allows matching of the tasks to the requirements if needed. -The team selects the items from the product backlog that have the highest priority and that can be completed within the current iteration. Any additional items of lower priority that can also be accomplished in the remaining iteration time are included, but any items that the team would be unable to complete are returned to the product backlog to be reprioritized for subsequent iterations. -Agile teams must be very careful not to include too many tasks in a given iteration. Iterations should be balanced so that the team continues to satisfy requirements but does not take on so much work that members need to put in long hours to accomplish their goals. The amount of work that a team can accomplish in a given iteration is its velocity. Agile teams need to plan their iterations at a velocity that could be maintained indefinitely. Doing so will ensure that the team does not exhaust itself in each iteration.

prioritizing the backlog

-There are many ways for Agile teams to prioritize the items in a product backlog. Six possibilities to consider as you prioritize your list: 1. Prioritize so you complete a set of minimally marketable features (MMFs) first. Narrow the large backlog down to a smaller set of options that the team can choose from to plan iterations. Include "exciting" features that will delight customers and motivate them to purchase the product. 2. Prioritize to deliver the requirements that provide the highest business value first. Consider requirements that provide value to the customer and to the business. For example, include requirements that reduce business costs, eliminate waste, or improve efficiency. 3. Prioritize so you provide the most value for the least amount of effort and cost. Choose requirements that are easy to implement but are still exciting to customers. 4. Prioritize so that you address the highest technical risks first. Consider tackling those items that would be hardest to implement, to get them out of the way. (Be careful; you may expend resources developing solutions that are never implemented or would be better addressed at a later date, when more is known about an issue.) 5. Prioritize so that you defer risks to later in the cycle. Selecting lower-risk items first will allow rapid progress and may provide insight into ways to tackle higher-risk items in a later iteration. 6. Prioritize by letting customers and users vote from a list of possibilities. Selecting the options that customers have voted for ensures that products satisfy customer needs. -The method you choose should be the most appropriate one for your product, organization, and situation. -If you still have trouble and need additional training, consider visiting the Conteneo web site and clicking into the Instant Play Games for creative and fun ways to train your team. For example, you could use the "Bang-for-the-Buck" game to help your product owner and product team place product backlog items on a chart, based on their perceived value and cost. Playing the game clarifies issues and ideas, and encourages discussion about an item's short-term potentiality and long-term value. Other games from the site provide insight and assistance in understanding customer and market needs and help Agilists prioritize their work to ensure the greatest value in their projects.

Agile and Waterfall project management

-There is a clear difference in the philosophy underlying Agile and that of traditional Waterfall project management. -The Waterfall project management model envisions a project as a series of sequential steps, beginning with the statement of customer requirements. The project is planned upfront and then monitored and controlled throughout the process. Once a step is completed, it is not revisited. The project can be pictured as a one-way process, much like water coursing over a waterfall—once the water passes over the waterfall, it does not return. 1. collect requirements 2. plan project 3. design product 4. develop product 5. test product 6. release product -Agile, in contrast, begins with the idea that customers can't identify all requirements at the start of the project. Instead, a series of initial requirements or user stories are surfaced and features are prioritized. The customer continues to participate with the Agile team through a series of iterative cycles of planning and development with a goal of quick releases. 1. collect requirements 2. plan project 3. design, develop and test product 4. release product *The "Plan Project" and "Design, Develop, and Test Product" portions of this cycle may be completed numerous times before a product is ready for release. -Agile can be seen as having "flipped the triangle"—in a typical Waterfall project, the team begins with fixed requirements and adjusts the variables of resources and schedule; but in a "flipped" Agile environment, the team starts with a fixed schedule and resources, and the variables are the features that the customer wants or needs. Waterfall is plan-driven, whereas Agile is value/vision-driven (features/requirements). -Waterfall and Agile project management differ in the methods they employ as well.

Agile teamwork/ team roles

-To become a successful Agile team, individuals must understand their roles, collaborate effectively with teammates, and help create an open and flexible working environment. They will need to view their responsibilities and interactions differently than if they were involved in a traditional project. And they will be expected to assume a greater degree of individual accountability, to share information, and to adjust to a team dynamic that emphasizes creativity and openness to change.

Agile team role: team members

-When Agile team members work together effectively, Agile projects succeed by delivering products that customers truly want. Team members collaborate with the product owner to understand the project vision and product requirements, but they ultimately decide how it will be built. They select the amount of work that they believe they can accomplish in an iteration from the prioritized product backlog, and then break the requirements into specific tasks to complete. While they work within the boundaries set by the product and project manager, they decide how they'll work together to satisfy requirements and meet the vision.

the Agile Manifesto

-a key foundational Agile document -created in February 2001 by a group of software engineers experienced in multiple programming methodologies. -17 practitioners arrived at a consensus on four main themes: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan -That is, while there is value in the items on the right, we value the items on the left more.

user story

-an initial requirement stated as one or more sentences in the routine or business language of the user. Often placed on an index card.

Reviewing the Iteration's Processes (stage 5 of the Agile development cycle)

-When iteration review meetings are complete, teams then turn their attention to an analysis of project dynamics: how well team members worked together and how well their processes worked. These iteration retrospectives allow teams to revise their development processes before continuing into subsequent iterations, by analyzing: *How well the product worked, from both the customer's perspective and the technical point of view *How well the processes used to create the product worked *How well the team interacted within the iteration *How well the project met the organization's intended goal -These retrospective meetings are usually one-to-three hours in length and provide the feedback that the team needs to adapt its work structure and its relationships before new iterations or projects begin. -The Agile methodology is designed to accommodate change, but that doesn't mean that changes are introduced without regard to structure. Iterations are planned to deliver solutions to specific customer needs; adding additional requests to an ongoing iteration would only complicate the iteration planning* and delay the work already in progress. To prevent such a problem, Agile practitioners incorporate change and make adjustments between iterations, not within an iteration. Any requests for change should be presented to the product owner, who will then add them to the product backlog for possible incorporation into future iterations of work. *iteration planning: Process in which the Agile team and product owner meet at the beginning of an iteration to determine which stories they will complete in the iteration.

XP core practices

-XP practitioners use 12 core practices to express the core values of XP (core values: communication, simplicity, feedback, courage). Because the application of each of the 12 practices helps to reinforce the strength of the others and contributes to the success of the project, all 12 practices should be used in concert in every XP project. *The planning game: XP teams determine what subsequent product releases will entail by balancing business/customer priorities (from the product owner) and technical estimates to complete the project tasks (from the development team). *Small releases: XP projects create products in quick, frequent increments to mitigate project risk. *Metaphor: XP practitioners use a common language that everyone on the project is familiar with and understands. *Simple design: Product developers use the simplest design possible and remove complexity as they develop products; they eliminate anything that doesn't satisfy current requirements. *Continuous testing: XP teams ensure high quality in products by implementing test-driven development (TDD) and constantly testing products. *Design improvement/refactoring: Developers simplify product characteristics, add flexibility, and improve product performance without changing the product's functionality or behavior; they use comprehensive automated tests to speed up the development process by ensuring that refactoring doesn't introduce new problems. *Pair programming: XP teams create products by having two people develop and review the product simultaneously; alternating the developing and reviewing roles provides different viewpoints and ensures quality and consistency. *Collective Ownership: All team members "own" the product so developers can improve the product in any way at any time, as long as they follow the rules and standards ascribed to the project. *Continuous integration: XP teams integrate completed tasks into a completed product multiple times each day. *Sustainable pace/40-hour work week: XP practices limit developers' time at work to prevent overwork and ensure an adequate work-life balance. *Whole Team/on-site customer: Customers (or a customer proxy) must be included and accessible to XP teams at all times to answer questions. *Coding standards: XP processes specify the rules, practices, and standards to be used on the project to ensure that all code (or product characteristics) can be understood and modified by all team members.

XP core value: feedback

-XP puts a strong emphasis on feedback throughout a project. Developers gather timely feedback by developing products in teams, running extensive daily tests to ensure products function as envisioned, and holding frequent conversations with customers and team members; this immediate feedback allows developers to quickly adjust processes and product characteristics to meet expectations. Tracking the team's velocity against the release plan also provides regular feedback on team progress. And putting the completed product quickly into production provides a quick check of customer acceptance and suitability.

XP core value: communication

-XP relies on extensive communication among team members to share information and to promote collaboration. Developers pair together to create products, and work with users on estimates and testing. Information radiators populate a shared work area that encourages osmotic communication and allows information to be quickly and easily conveyed throughout the team. *information radiator: Large display of critical team information that is continuously updated and located in a spot where the team can see it constantly *osmotic communication: Communication in the context of an Agile project that is picked up or absorbed by another team member, often through background hearing.

XP Roles

-XP teams have many "roles" that team members must fill. These roles are not specific "jobs" staffed by specialists but instead are responsibilities that must be performed to create effective XP teams. (XP practitioners still avoid filling teams with specialists, preferring instead to develop generalists who can handle multiple types of tasks.) -on-site customers/proxies: *Identify features and/or stories they would like to see in products *Help decide which features have the most value and should be included in each release *Provide answers to team questions -product owner/manager: *Document the product vision and share it with stakeholders *Create and prioritize features and stories *Incorporate feedback and make trade-offs of features/stories *Provide direction for on-site customers and lead customer demonstrations *Protect the team from outside distractions and "office politics" *Participate in the planning game with the development team -subject matter experts/domain experts: *Fill in knowledge gaps *Provide details and answer questions for the team *Create customer tests (occasionally) -interaction designers: *Understand user needs as they relate to interacting with the product and advise the team of user priorities *Create personas and perform interviews with customers (Personas: Fictional characters that represent the users of a product. Personas generally include information and assumptions about these users so teams can plan their work to satisfy these types of users.) *Review prototypes with customers and observe customer use of the product *Create mock-ups and prototypes (occasionally) -business analysts: *Analyze customer needs and translate them into functional specifications *Support on-site customers *Help the team translate technical terminology into language that customers will understand -product developers/programmers: *Execute the project work and develop products *Produce complete products in each iteration *Provide suggestions for alternative ways to accomplish tasks *Develop estimates as required and minimize costs by working as efficiently as possible *Correct any quality or technical debt issues encountered *Participate in the planning game with product owners/managers -designers/architects: *Guide the team's efforts as design/infrastructure experts *Help solve problems and simplify complex issues -Testers: *Help customers think of possibilities/potential features *Ensure product quality *Identify holes in product development *Provide nonfunctional data (product performance, scalability, stability) to the team -coaches: *Act as project leaders who lead by example, not by assigning tasks *Staff the team and secure an appropriate workspace *Keep the team focused on the tasks at hand and help the team interact with the organization *Help the team succeed -project managers: *Coach the team on nontechnical issues (project managers often do not have technical experience, so they avoid interfering on technical issues) *Help the team work within the organization

XP Teams

-XP works best with small-to-medium-sized teams of experienced developers. Team members must be knowledgeable enough to create TDD tests and experienced enough to contribute to pair programming. -Because of the reliance on extensive verbal communication and a need to work together on development, it is very important for XP teams to be co-located. One suggested layout for co-located teams involves a large central area surrounded by several smaller areas—a configuration called "caves and common rooms." In this configuration, the center of a room is designated as a group work area, which acts as a large meeting area and assists osmotic communication and the sharing of information. The outer edges of the room are divided into smaller areas that allow developers to complete their work or hold smaller discussions. Participants in caves and common rooms must be working on the same project; otherwise, discussions of alternate projects in the common area can distract developers from their work.

Agile methodologies

-xtreme Programming (XP), Scrum, Feature-Driven Development, and other approaches -In general, however, Agile methods can be characterized as: *adaptive rather than predictive *people-oriented rather than process-oriented *focused on the skill of the development team *open to change (unlike some engineering methods) *centered around small iterations

Waterfall v Agile RISK MANAGEMENT

WATERFALL: -Embraces a formal risk management process (risk identification, qualitative and quantitative analysis, risk response planning) -Monitors and controls work in precise steps AGILE: -Addresses risk through daily team status meetings* and a retrospective* meeting -Employs constant feedback cycles to identify, monitor, and respond to risk *Daily team status meeting: Daily 15-minute project meetings held to provide status updates to team members; also known as daily stand-ups or daily scrums. *Retrospective: A meeting at the end of each iteration in which the team discusses how well it worked together to create the product and what changes they could make to improve in subsequent iterations.

Waterfall v Agile CHANGE MANAGEMENT

WATERFALL: -Uses a formal integrated control process to rework requirements -Adds the cost of changes to the overall budget AGILE: -Incorporates changes through iterative and incremental development -Uses prioritized product backlogs for managing change -Builds the cost of changes into the iterative process *product backlog: Scrum-specific term for the list of prioritized customer requirements that the team and product manager choose from to determine which customer needs will be met in an iteration. Also called the work queue.