Scrum - The Rugby Strategy in Product Development

Scrum is not primarily about software development. It is a method for managing product development that can be wrapped around any specific technology, including software. Scrum as it exists today grew from its beginnings in Japan in the mid-1980s. The name “Scrum” is from the game of rugby and refers to a strategy used to get a ball back into play. The Scrum process is incremental, just as with other Agile methods.

Scrum practices

The Scrum Master
“The Scrum Master is responsible for the success of Scrum” . Although Scrum defines this as a new role, in traditional projects its responsibilities are often taken on by an existing position such as project manager or team leader. The primary responsibilities of the Scrum Master are to:

◗ Ensure that the Scrum practices are followed and that the values behind Scrum drive enactment of the process.
◗ Work with management and the customer to identify the individual who will take on the role of “Product Owner.”
◗ Facilitate each of the other practices
◗ Be the interface point among management, the customer, and the Scrum team. Of primary importance are:
◗ Communicating project status;
◗ Removing impediments to progress


Product Backlog
“Product Backlog is an evolving, prioritized queue of business and technical functionality that needs to be developed into a system”. The Product Backlog is the sum total of the work that remains to be done on the project and includes everything from major features to bug fixes. Any stakeholder in the project can contribute to the Product Backlog at any time, but it is the Product Owner who has the primary responsibility for determining the priority of backlog items.

The primary measure of progress in a Scrum project is the change in the number of items in the Product Backlog over time. It may grow in early Sprints as stakeholders gain an understanding of the system being built, but ultimately, a pattern of steady decrease in the size of the Product Backlog is expected. If this does not materialize, or if it is not fast enough, then hard decisions must be made about the project’s scope.


Scrum Teams
“A team commits to achieving a Sprint goal. The team is accorded full authority to do whatever it decides is necessary to achieve the goal” . Almost all software development involves teams. The key difference with Scrum is that the team freely commits to what they believe they can produce during each Sprint, and they are empowered to make whatever decisions they must to fulfill those commitments. This level of autonomy is foreign to most organizations.

Daily Scrum Meetings
“Software development is a complex process that requires lots of communications.
The Daily Scrum meeting is where the team comes to communicate”. The Daily Scrum (the defining feature of Scrum) is a short 15-minute meeting that takes place every working day. It is the forum where team members exchange information and others may come to listen but not speak. To keep the meeting short, all deliberation and discussion is relegated to meetings of interested people after the Daily Scrum. During the Daily Scrum, each team member answers three questions:

◗ What have you done since the last Scrum?
◗ What will you do between now and the next Scrum?
◗ What got in your way of doing work?

The third question provides the Scrum Master with the information he or she needs to be effective in removing impediments to progress and ensuring the team continues to be productive.

Sprint Planning Meeting
“Customers, users, management, the Product Owner, and the Scrum Team determine the next Sprint goal and functionality at the Sprint Planning meeting. The team then devises the individual tasks that must be performed to build the product increment”.

Each 30-day Sprint begins with this planning meeting. The critical outputs of this meeting are:

◗ Sprint Goal—The objective that is to be achieved during this Sprint.
◗ Sprint Backlog—The subset of the Product Backlog that will be completed
during the Sprint.

The Product Owner is the sole arbiter of the priority of the Product Backlog items. But only the Scrum Team can commit themselves to completing specific work. The Sprint Planning meeting is the forum where lobbying and negotiation take place. At its conclusion, all stakeholders will have agreed to a Sprint Goal and Sprint Backlog to which the Team is willing to commit.


Sprint
“The team works for a fixed period of time called a Sprint”. After the negotiations of the Sprint Planning meeting, the Scrum Team has full authority to complete the 30-day Sprint by doing whatever they feel is necessary. During the Sprint, the team self-organizes and self-directs, and their authority even extends to being able to:

◗ Change the functionality to be delivered by the Sprint as long as the Sprint Goal is still achieved.
◗ Abort the Sprint if new information leads them to believe its Goal or Backlog is no longer achievable or relevant.

Assuming the team does not abort the Sprint, it ends with the delivery of the promised executable product increment.


Sprint Review
“The Sprint Review meeting is a four-hour informational meeting. During this meeting, the team presents to management, customers, users, and the Product Owner the product increment that it has built during the Sprint”. This meeting provides a concrete picture of the progress achieved during the Sprint and lays the foundation for the next Sprint Planning meeting.


References
- Takeuchi, H., and I. Nonaka, “The New New Product Development Game,” Harvard Business Review, January 1986.
- Schwaber, K., and M. Beedle, Agile Software Development with Scrum, Upper Saddle River, NJ: Prentice-Hall, 2002.

22 Lean Software Development tools

LD is characterized by seven lean principles that are elaborated into 22 Lean Software Development tools.

Eliminate Waste
Tool 1: Seeing Waste—You should looking for waste in these parts of your development process:
◗ Partially done work (e.g., unimplemented designs);
◗ Extra processes (steps in your process that do not add value);
◗ Extra features (things for which the customer did not ask);
◗ Task switching (people assigned to multiple projects);
◗ Waiting (for hand-offs);
◗ Motion (hand-offs);
◗ Defects.


Tool 2: Value Stream Mapping—Identify all the steps in your process that add value to the product, and for each of those steps, identify how much time is required to add the value and how much time is wasted in waiting. Note that some steps that do not directly add value are necessary (e.g., Configuration Management mitigates risks).


Amplify Learning
Tool 3: Feedback—Design your process so that participants receive feedback as often as possible. For example:
◗ Test early and often;
◗ Show users the evolving system;
◗ Prototype instead of analyzing.


Tool 4: Iterations—Iterative time-boxed development is the best way to converge on the ultimate solution. Often this results in negotiation of project scope or duration. But such negotiation is good if done early in the project, when adjustments are less painful.


Tool 5: Synchronization—Every development method results in synchronization problems (e.g., collective code ownership can result in multiple people changing the same program at the same time.) The authors recommend several synchronization mechanisms for software projects.


Tool 6: Set-Based Development—When faced with a difficult problem, it is often good to think about the solution space instead of specific solutions. The authors recommend these steps:
◗ Develop multiple options (e.g., brainstorming ideas);
◗ Communicate constraints;
◗ Let the solution emerge.




Decide as Late as Possible
Tool 7: Options Thinking—In financial markets, you can purchase options that, for a price, allow you to delay making a decision until a later date. The same model can be used in Agile software development. By incurring some added cost, options can be held open, allowing decisions to be delayed until more information is available.


Tool 8: The Last Responsible Moment—Options Thinking (Tool 7) delays commitment to a decision until the last responsible moment. The authors define that as “the moment at which failing to make a decision eliminates an important alternative” .


Tool 9: Making Decisions—Good decisions are more likely to be made when the options can be narrowed by the application of a set of rules. The authors recommend that decisions in software development always be made in light of the seven lean principles




Deliver as Fast as Possible
Tool 10: Pull Systems—The best way to ensure that each team member knows exactly what he or she should do each day is to ensure that the environment provides automatic prompting. For example:


◗ Short iterations with well-defined deliverables provide near-term targets for people to work toward.
◗ Daily stand-up meetings keep everyone aware of progress toward that target.
◗ Information radiators (publicly posted charts) keep everyone aware of the big picture.


Tool 11: Queuing Theory—Much waste can be attributed to people waiting for constrained resources. The authors suggest using queuing theory to analyze all bottlenecks in your software process and determine ways to minimize the cycle time.


Tool 12: Cost of Delay—In many software projects, the cost of delaying delivery (even when it is significant) is often invisible to the project team and sometimes to managers. The authors recommend developing a financial model for the project that will allow all stakeholders to make appropriate trade-off decisions, especially when cost and delivery date are in conflict.


Empower the Team
Tool 13: Self-Determination—The people who do the work are in the best position to improve their processes and eliminate waste. Although Quality Circles have fallen out of favor, this philosophy still has value in guiding process improvement efforts.


Tool 14: Motivation—Motivating a project team to perform well has many dimensions. The authors stress that the team must have:


◗ Purpose—A shared goal that they all believe in.
◗ Belonging—They feel that each person is a part of the team.
◗ Safety—Mistakes are corrected without punishing people.
◗ Competence—The team feels they able to complete their tasks.
◗ Progress—Each person can see regular progress on the project.


Tool 15: Leadership—Project management and technical leadership are two distinct skill sets. A successful team needs both, and it is rare for those two attributes to exist in the same person.


Tool 16: Expertise—Every software project requires a variety of expertise (e.g., domain, user interface, database, project management, writing). This tool is about identifying communities of expertise and ensuring that they are available to the project.




Build Integrity In
Tool 17: Perceived Integrity—Perceived Integrity is the system’s integrity from customers’ viewpoint. Do they perceive it to be useful and well designed? With appropriate interaction between the team and customer, the team can be sure they build the right system.


Tool 18: Conceptual Integrity—Conceptual Integrity is an important component of Perceived Integrity (Tool 17). Building the system right (as differentiated from building the right system) involves such concepts as architecture, consistency, and elegance.

Tool 19: Refactoring—Programmers should improve the software any time they see the opportunity to do so. Refactoring refers to redesign of the system to improve the program’s Perceived and Conceptual Integrity (Tools 17 and 18).
Also, after many changes have been made to software, it tends to become brittle. (That is, over time, it becomes more and more difficult to make any changes to the software without breaking it in unforeseen ways.) Brittle code is a Conceptual Integrity problem that Refactoring remedies.


Tool 20: Testing—Testing provides an important feedback mechanism. (See Tool 3.) Both validation (ensuring the right system is built) and verification (ensuring the system is built right) must be done throughout the development process, not just at the end. That way, the team gets the feedback they need to ensure their system’s integrity, both Perceived (Tool 17) and Conceptual (Tool 18).




See the Whole
Tool 21: Measurements—The authors focus on the various problems associated with measurement (e.g., suboptimization) and their sources. In essence, this tool is about focusing measurement where it is effective: at higher-level aggregations of data. This focus has the dual benefit of protecting individual engineers from management’s abuse of their personal data and focusing attention on data that is useful to the organization as a whole.


Tool 22: Contracts—Contracts are a fact any time the supplier and customer are different companies. Because these relationships can be so complex and varied, the authors discuss a variety of contractual arrangements and the positive and negative effects of each.




References
- Poppendieck, M., and T. Poppendieck, Lean Software Development: An Agile Toolkit, Reading, MA: Addison-Wesley, Inc., 2003.
- Cockburn, A., Agile Software Development, Reading, MA: Addison- Wesley, Inc., 2002.

Agile Simplified with Feature Driven Development

FDD differs from other Agile methods in its focus on upfront design and planning. As can be seen from the FDD process diagram in this picture, the Object Model, feature list, and planning are done once at the beginning of the project, and iterations are essentially an incremental building of identified features. This is not to say that the model, feature list, and plans never change; rather, it indicates that evolution of those items is not an inherent part of this method.

FDD practices

Domain Object Modeling

FDD begins with the construction of a relatively detailed object model for the system to be built. This model is not intended to provide all the design details for the features. Rather, its intention is to force all stakeholders’ assumptions out into the open and provide a road map for the project. Although the initial Object Model is built at the beginning of the project, each increment of development results in updates to it as details are filled in and corrections are made. Thus, the Object Model is a continually evolving picture of the product, as it is currently understood.

Developing by feature

The Object Model identifies all the expected classes in the system, but development is not done class by class. Rather FDD requires that development be done a feature at a time.

FDD defines a feature this way. “A feature is a small, client-valued function expressed in the form: Action - Result - Object

The 12 Practices of Extreme Programming

The Planning Game
In XP, planning (characterized as “The Planning Game”) is both iterative and collaborative. It is iterative in that the “game is played” at the beginning of each increment of development. It is collaborative in that it is played among the technical team members and the customer and management (referred to as
the business people). During the Planning Game for each increment, the business people and the technical people negotiate to establish an achievable plan that best meets the business needs. During this negotiation, the customer identifies what system features would be most valuable to develop next, the technical team determines the feasibility and effort for developing that functionality, and management ensures that the project stays within any relevant parameters (e.g., cost).

Small releases
An XP project team develops the system in the smallest reasonable chunks that provide demonstrable value for the customer. Because each increment should take only a few weeks to develop, the functionality that can be developed in that time is very constrained. But even when it is not feasible to actually release an increment for use, that increment is still demonstrated for customers so they can verify that it is progressing toward meeting their needs and appears to be usable.

Metaphor
An XP project’s Metaphor is the overall concept of the system that the team will build. The Metaphor uses similes to describe what the system will be like, in terms that are readily recognizable to both the development team and customer. This very high-level vision is the XP project’s overall requirement, and there is an expectation that it will remain relatively stable throughout the project.

The actual descriptions of the system features are documented separately in “Stories.” Each feature is documented in a separate Story that describes the feature’s essential attributes and actions. These descriptions are also quite brief, comprising only the text that can be written on a 3x5-inch card. The stories on an XP project tend to change dynamically as the development team and customer learn about the product they are building and gain a better understanding of the customer’s needs. The Stories, taken together with the project’s Metaphor, form the requirements from which the system is planned and developed.


Simple design
This practice is the heart of XP’s value of “Simplicity.” It advises that programmers avoid designing for the features that they “know” are coming (even if they will be implemented within the current increment). Instead, they must use the simplest possible design that will allow the current Story to be implemented.

XP is based on the philosophy that this “simple design” practice will result in less rework than designing for the future. This is because we are often wrong when we design for the future, and when we are, the rework can be significant. Beck sums up this practice: “If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy”.

Test First
One of XP’s defining philosophies is “Test First.” This philosophy states that before a pair of programmers writes a single line of code, they must implement the automated tests that will be required to verify the Story they are about to write.

In addition, customers also develop a set of functional tests One of XP’s defining philosophies is “Test First.” This philosophy states that before a pair of programmers writes a single line of code, they must implement the automated tests that will be required to verify the Story they are to verify the Story according to their own needs. Coding the XP way consists of code a little, test a little, code a little, test a little—with the test results being the programmers’ measure of progress on the Story at hand. Work on the Story is not complete until all the tests run 100% clean. Successful integration is also defined in terms of these automated tests.


Refactoring
XP’s Refactoring practice prompts each pair of programmers to ask themselves before they begin work on a Story if there is a way to redesign the system so that the final result “is the simplest thing that could possibly work”. Then, after they have completed work on the Story, Refactoring prompts them to ask the same question again. In either case, if the answer is, “Yes,” then the redesign is implemented as part of the work on that Story. Refactoring is used to ensure that the “simple” designs that programmers start with do not grow into needless complexity as more Stories are added.


Pair Programming
The most visible practice of XP is Pair Programming. This practice calls for all technical work (from design to coding to test) to be done by a pair of programmers working together at a single workstation. Pairs form and change dynamically throughout the project according to the needs of each story. The member of each pair who is not typing has a very special job. That person is to be thinking about the wider impacts of what is being implemented— to be continuously asking questions like, “Is there a simpler way to do this?” “Do we need tests that we did not yet create?” “Are there defects in this code?” “Will this strategy work?” Pair Programming has been called the ultimate in peer reviews, because it entails a continuous, real-time review of everything that is done. This is one more example of XP’s strong emphasis on technical excellence.

Collective ownership
XP takes a position on code ownership that is quite different from the standard model of assigning responsibility for each code module to a specific person. XP goes to the opposite extreme—stating that code should never be “owned” by any individual. When anyone identifies a need to change any code, it is that pair’s responsibility to implement that change. Every member of the team owns all code collectively.


Continuous integration
XP goes beyond the concept of daily builds to require that integration of the product being built goes on continuously. As a pair completes each Story, their last step is to integrate their new and changed code (along with their automated tests) into the baseline system. They then run the entire test suite all of their own automated tests, as well as those for all the Stories that are already part of the system. If any test fails, the new Story and tests are backed out, and the pair must resolve the problems before they can try again. When all the tests run 100% clean, the Story has been successfully integrated and becomes part of the project baseline. Because there are several pairs of programmers working on different Stories at all times, this practice results in someone integrating something almost all the time.

40-hour week
XP calls for overtime to be rare. It explicitly suggests that overtime should not be worked 2 weeks in a row. The intention with this practice is to keep everyone fresh so they can continue indefinitely on an aggressive but sustainable pace.

On-site customer
One of the key members of an XP project team is the on-site customer. This is a person who will be a real user of the system being built, or some other person who can authoritatively stand in for the customer/user. This practice ensures that an appropriately knowledgeable person is continuously available to the team to review work, try things out, answer questions, and make implementation decisions when they are needed.

Coding standards
Several other XP practices (most notably Pair Programming and collective ownership) give rise to the importance of good coding standards. In a team that is collaborating this closely, appropriate standards are the only way to maintain order.Additionally this practice is support knowledge flow and knowledge management in your team.



References
Beck, K., Extreme Programming Explained, Reading, MA: Addison-Wesley Longman, Inc., 2000.

Nine Principles of Dynamic Systems Development Method

Principle 1: Active user involvement is imperative.
DSDM’s strong focus on the business purpose of the system being developed requires that the ultimate users of the system be involved throughout the development project. This is because the system attributes that will make it fit for its purpose cannot be understood well enough in the project’s early stages to commit them to a detailed specification. Therefore, the only way to make appropriate detailed decisions and know that the evolving system is converging on the ideal of “fitness” is to fully involve the users throughout the project.

Principle 2: DSDM teams must be empowered to make decisions.
This principle does not give the team free reign to do whatever they wish. Rather, it advocates that the team be delegated the authority to make most of the day-to-day decisions as the project progresses. With active user involvement, such delegation can result in the team being able to move quickly and steadily toward system delivery. However, when a decision that must be made falls outside the team’s authority (e.g., cost overruns), DSDM recognizes the importance of raising such decisions to the appropriate authority.

Principle 3: The focus is on frequent delivery of products.
This principle means that the project’s progress should be measured by the production of tangible products, rather than by mere activity. The phrase “delivery of products” does not refer only to the incremental delivery of a working system to an end user. Products in this sense include any sort of work product that may be produced as the project moves forward (e.g., a specification, a throwaway prototype, a design document); and delivery could be simply within the project team. DSDM requires that as the project moves forward, it must produce artifacts that prove that progress is being made.

Principle 4: Fitness for business purpose is the essential criterion for acceptance of deliverables.
This principle is the practical manifestation of DSDM’s belief that specifying detailed requirements upfront is not helpful. By placing fitness for purpose above satisfaction of requirements, and by involving users consistently, DSDM zeroes in on the end user as the only one who can say whether or not the system as it is evolving is acceptable.


Principle 5: Iterative and incremental development is necessary to converge on an accurate business solution.
In an environment where it is assumed that the project’s end result cannot be foreseen in great detail, incremental development is the best insurance against the project going terribly awry. Incremental development is essentially an exercise in trial and error, where each new increment is presented to the user who validates (or invalidates) the direction the team has taken. “Converge” is the key word in the principle. It is assumed that the most direct path to the end product is not likely to be known, so DSDM engages in constant checking and correcting of the path to bring the project to a satisfactory end as quickly as is reasonably possible.

Principle 6: All changes during development are reversible.
If we agree that the project is practicing trial and error, then we must expect that there will indeed be errors from time to time. This principle gives us permission to discard erroneous work when necessary. Surely, we will try to salvage the good from a mistake, but we must recognize that there will be times when the most efficient path is to discard some work and try again.


Principle 7: Requirements are baselined at a high level.
The first three words of this principle, “Requirements are baselined,” represent a departure of DSDM from some other Agile methods. DSDM recognizes the importance to the project of stability in scope and direction. By baselining (freezing) the requirements at some level, stakeholders are establishing a stable basis for the team’s work. This does not mean that this baseline will not change; rather, it requires that serious deliberation precede any such change so that all stakeholders understand and agree to what would become the new requirements baseline. The last four words, “at a high level,” is the part of this principle that makes it agile. It leaves the details of what the requirements mean to be worked out between the team and user.


Principle 8: Testing is integrated throughout the life cycle.
Testing does not show up as a step in the DSDM life cycle because, like other Agile methods, DSDM promotes a strong quality-consciousness by all team members. Every task should include an appropriate verification or validation step like a review or test by a team member or user. This principle works together with principles 1, 4, and 5 to continually check the project’s progress toward its goal of a system fit for its business purpose.


Principle 9: A collaborative and cooperative approach between all stakeholders is essential.
This last principle is little more than the sum of the first eight. The only way that principles 1–8 can be applied successfully on a project is if all stakeholders accept DSDM and their roles as DSDM defines them. If any stakeholder does not agree (especially an influential stakeholder), then DSDM cannot work in that environment.

Reference
Stapleton, J., DSDM: Business Focused Development, London, England: Pearson Education, 2003.

Introduction to Adaptive Software Development

Jim Highsmith’s ASD arose out of his understanding of Complex Adaptive Systems theory. He views a software project team as a complex adaptive system that consists of agents (team members and other stakeholders), environments (organizational, technological, process), and emergent outcomes (the product being developed).

The Adaptive Life Cycle

ASD’s Adaptive Life Cycle is composed of five steps. The initial step of “project initiation” is done once at the beginning of the project, and the final step of “final Q/A and release” is done once at the end.

The other three steps (adaptive cycle planning, concurrent component engineering and Quality Review) form the “Learning Loop” or “Adaptive Cycles” that are the heart of ASD. These Adaptive Cycles are described as:

◗ Mission-driven—each cycle must make progress toward the project mission;
◗ Component-based—more centrally focused on building things than on performing tasks;
◗ Iterative—going through the learning loop repeatedly is the key to progress;

◗ Time-boxed—the entire project as well as each cycle of the project is completed within a prescribed time period (with the developed functionality expanding or contracting to fit);
◗ Risk-driven—focusing on the highest-risk items first;
◗ Change-tolerant—designed to accommodate changes in each cycle.

Speculate: Project initiation
The project’s first step in speculation is an initiation workshop, from a few days to a few weeks in length, depending on the project’s size and scope. During initiation, the entire project team and the project sponsor or customer determine the project’s guiding parameters, including the project mission, objectives and constraints, the organization for the project, the system requirements, initial estimates of product size and scope, and key risks to the project.

Learning Loop
The initiation practice lays the groundwork for the project’s “Learning Loop.” This loop sees the project continually cycling from speculation to collaboration, to learning as the product emerges incrementally from the adaptive cycles (an iterative approach).

Speculate: Adaptive Cycle Planning
The first cycle of the project begins with the speculative practice we normally call “planning.” This includes these steps:

◗ Determine the project time-box.
◗ Determine the optimal number of cycles and the time-box for each. (Each cycle is usually established to be from a couple of weeks to a couple of months in length.)
◗ Write an objective statement for each cycle.
◗ Assign primary components to cycles.
◗ Assign technology and support components to cycles.
◗ Develop a project task list.

In each successive project cycle, Adaptive Cycle Planning consists of revisiting and revising these things as necessary, based on progress to date and what has been learned in earlier cycles.

Collaborate: Concurrent component engineering
This is where the real work gets done. The content of this phase of each cycle is planned in the Adaptive Cycle Planning phase and done to the extent possible within the planned time-box. Trade-offs may have to be made as the end of the time-box constrains what can be accomplished. This phase is shown as multiple boxes because team members or subteams are generally working concurrently and integrating their work products.

Learn: Quality Review
The end of each cycle is marked by learning activities, where the project team gains insight into progress to date and collects the information they need to perform any replanning at the start of the next cycle. Highsmith specifically recommends three learning activities:

Customer Focus Group Reviews—Because the objective of an ASD project is to converge on a system that meets its business purpose, evaluating the results of each cycle by the ultimate users is a critical learning activity. Highsmith recommends using a joint application development (JAD)-style facilitated workshop to collect input from the user community at the end of each cycle. During this workshop, developers would demonstrate and explain what has been built so far. Then users would try using the software and give developers their reactions to it.

Software Inspections—The primary objective of these inspections is to detect defects in the work products of the cycle, but they have a secondary benefit of ensuring that each team member is familiar with all the code that has been written.

Postmortems—The final step in each cycle is the postmortem, where team members evaluate the effectiveness of the processes they have been using as well as the project’s performance against its plan. If they identify problems, they also brainstorm ideas for solving those problems. The results of the postmortem are fed back (via the Learning Loop) to the planning phase for the next cycle.

Learn: Final Q/A and release
This phase is the final hand-off to the customer. Its focus is to put both the product and all pertinent information about it into the customer’s hands before disbanding the project team.

References
Highsmith, J. A., III, Adaptive Software Development, A Collaborative Approach to Managing Complex Systems, New York: Dorset House Publishing, 2000.

Motivation and Self Organization teams from Agile Perspective

Motivated individuals

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

This principle highlights the Agile methods’ reliance on the motivation of each team member to achieve project success. Most of the practices of these methods make the assumption that team members are going far beyond simply following orders and doing what was assigned.

They expect that each person is exercising his or her professional judgment to take the path that he or she believes is best at each juncture of the project, or at least to raise questions and concerns to be discussed with the team, management, and the customer.
But the Agile methods do not just expect motivated individuals to appear. The second sentence of this principle highlights a few conditions that the Agile Manifesto authors believe are important to building a motivated team: an appropriate environment, support for them as professionals, and trust that they will indeed exercise good professional judgment.

These things highlight the Agile methods’ differences from the more conventional command-and-control mode for managing projects. The traditional methods assume that intrinsic motivation is rare, and so they enforce specific behaviors. The Agile methods build an environment where each individual is challenged to build his or her capabilities and where motivation is an expected outcome of the environment.

Perhaps a better way to state this principle would be, “Build project environments that generate motivated individuals.” This statement aligns more readily with the way the Agile methods are engineered.

Self-organizing teams

"The best architectures, requirements, and designs emerge from self-organizing teams."

The Agile methods embrace the recent movement toward self-managed, self-directed, or (as this principle says) self-organizing teams. This philosophy is a movement away from traditional command-and-control management and toward one that counts the team as an entity that has its own knowledge, perspective, motivation, and expertise. In this environment, the team is treated as a partner with management and the customer, capable of providing insight, affecting decisions, and negotiating commitments.

The Agile Manifesto sees this structure not only as a way to achieve a more motivated team but also (as this Principle states) as a way to achieve technical excellence. The Agile methods each count on the team itself to keep the technical issues under control and “on the radar scope” when project decisions are being made.

Different agile methodologies suggest different practices to start and provide required environment in order to make motivated individuals and self directed teams.

Adaptive Software Development suggest Development team as an independent agent that should be involved with other agent such as management and customer. and Speculate for Project initiation and adaptive planning and The Adaptive (Leadership-Collaboration) Management Model

Dynamic System Development Method says that DSDM teams must be empowered to make
decisions

XP suggest The Planning Game and Collective ownership

Feature-Driven Development (FDD) suggest Class (code) ownership and Feature teams

Lean Software Development suggest Self-determination and Motivation

And finally Scrum says that The members of the Scrum development team are key participants in Sprint (development cycle) planning in a Scrum project. They participate fully along with other stakeholders in planning each Sprint, and their commitment
to achieving the Sprint goals is a key criterion for an acceptable Sprint plan.

During each sprint, the Scrum team has full authority to do whatever they believe is necessary to achieve the Sprint goals. They even have the authority to abort the Sprint if they discover that the agreed-upon goals cannot be met. Thus, the Scrum team self-manages and (it is expected) also self-motivates.

But the basic philosophies of these methods are remarkably similar, here is brief description:

Trusting the technical team
Abandonment of command-andcontrol style management; replacing it with clear respect for the team:

◗ Include the team in all deliberations about the project.
◗ Give them unfettered access to the customer.
◗ Seek their input on all technical issues.
◗ Believe their concerns about schedule goals.
◗ Expect them to learn (along with everyone else) as the project progresses.
◗ Gain their willing commitment to all plans.
◗ Negotiate with them to reach acceptable plans.
◗ Empower them with broad authority.
◗ Provide the tools and support they need.
◗ Trust them to exercise their best professional judgment in all circumstances.

This essentially means entrusting the development team with the authority to self-organize and self-manage.

Staffing with “motivated individuals”

You may be asking yourself, “Where am I going to find all of these motivated people?” “And what will I do with the unmotivated lumps I am stuck with now?”

It is true; most of your staff members are not superstars. In fact, most of them are pretty average. The point behind the Agile methods is not that you must find a whole bevy of highly motivated and technically expert people. Rather, it is that by adopting an Agile Method and what ASD calls the “leadership-collaboration” management style, you can motivate most of your current staff to behave more like superstars.

Behavioral psychology has long told us that people tend to live up to (or down to) the expectations placed on them. This is as true with your technical staff as with any other population. The average person, in an environment where his or her expertise and knowledge is valued, will not only bring those attributes to bear on the topic at hand but will also seek to improve them, to make himself or herself more capable of rising to such
challenges in the future.

Pair Programming
XP’s practice of “Pair Programming” is unique and foreign to almost all organizations. It states that pairs of individuals working together perform all technical work. These pairs are expected to form and trade partners from time to time. All designing, test case development, coding, and testing is done in pairs. While one member of a pair is “driving” the computer, the other is watching, assessing the partner’s work, and asking questions.

The pair switches roles on a regular basis. Although this practice sounds wasteful of your most precious resource (your engineers’ time), XP’s proponents claim just the opposite. They claim that a pair working together can be as much as 50% more productive than the two individuals would be if they worked separately. This is expected for a variety of reasons:

◗ The real-time review being done by the observing partner results in many defects being discovered and corrected within minutes of being created, instead of showing up later in tests when the diagnosis and correction could be more time-consuming.

◗ The person in the observer role tends to think about the big picture, making him or her more likely to identify architecture, design, or testing issues early, so they can be corrected before much rework would be required.

◗ The constant interaction between the individuals allows them to learn from each other, sharpening both of their skills and making each of them more capable.

◗ Because two individuals become intimately familiar with every part of the system, the loss of any one person cannot cripple the project.

◗ It provides a way for any new project member (even a recruit fresh out of school) to become a contributing member of the project very quickly.

Chief Programmer
FDD includes a Chief Programmer role. This role is generally reserved for highly respected team members who have superior technical knowledge. By placing such individuals into this role, FDD seeks to capitalize on their expertise and reputation to strengthen the skills of the rest of the team. In addition to their normal technical tasks, Chief Programmers act as coaches and mentors on technical matters, being a resource to team members who have questions about the work they are contemplating.

Method Coach
Some Agile methods (e.g., XP and Scrum) recommend that the project have a person whose job is to coach the team in using the method. This is a good recommendation in any environment where the team is being asked to change how they do their work. Changing old habits can be difficult, and a coach may be indispensable in helping people recognize old habits and exchange them for new ones.

A coach can keep things running efficiently by being the person who is always concerned about the method and how well it is serving the project’s needs. And, of course, when team members do become aware of the method (because it is impeding their work), the coach will be prepared to help them work through the problem and come up with ways of working that serve the team better. The Coach ensures that the Method you have adopted is indeed creating a project environment in which the team can self-motivate and self-manage.

People over processes and tools Or Balancing people, process, and tools

The very first value in the Agile Manifesto draws a line in the sand. In it, the Agilists clearly state their belief that people are of greater importance in determining software project success than are processes or tools.

The software process community generally acknowledges the importance of people, but the processes they build do not always reflect such a belief. Like the toolmakers, the writers of processes often focus so closely on the completeness and robustness of the processes themselves that the ability of people to follow them is compromised. For example, a person may find that the role he or she is assigned by the process may require activities beyond his or her skills, abilities, or time constraints.

Compounding this problem, when people cannot see the value of the work products or activities that a process prescribes, they will consciously or unconsciously undermine or circumvent that process.

Process writers also tend to pay little attention to tools. While they acknowledge that the right tools can make any process more efficient, they do not routinely consider the available tools when designing processes. In light of this discussion about the effects of tools on process, such a lack of attention can have serious negative effects as the organization attempts to integrate a new process with an incompatible tool set.

So we see that of people, process, and tools, all are important to our projects’ success. they are the three legs on which projects stand. To make one leg longer or shorter than the other two would make the project unstable, and eliminating any of the three would cause the project to fail. The success of our projects depends on all three.

The role of people

Our people are our most precious resource. In the business of creating intellectual property, people have a preeminent role.

Processes cannot create. Tools cannot exercise intellect. Turning ideas into working software requires people. People imagine, people interpret, people envision what they expect to build, and then people turn that vision into reality. Without people, software cannot be written.

but people have shortcomings. People make mistakes that result in defective software. People forget things so that their solutions are incomplete. People envision the future imprecisely so that their plans and estimates may be poor. People can keep only a limited amount of information in their minds at one time, so they may miss the consequences of their decisions. People misinterpret what others say so that information is lost in communication. People remember imprecisely so that facts are subject to dispute. People are expensive and may work slowly so that projects run over budget and schedule. People are bored by repetition so that some tasks are ignored or performed poorly.

Because of all these things and more, people by themselves are insufficient to ensure a successful software project. A team of even the best people in the software industry will have an uncertain likelihood of success. All people need the support that is provided by processes and tools to mitigate for their shortcomings so they can do their best work.

The role of processes

Processes identify the roles of the people on the project, the actions those people will take, and the work products those people will produce. In fact, the Agile Manifesto’s contention that interaction among individuals is more important than “process” belies a misunderstanding of the nature of process.

After all, it is the process that is being followed that determines who will interact with whom, under what conditions the interaction will take place, what will be the subject of that interaction, and what will be its result.

Indeed, “interaction” cannot be more important than “process,” because interaction is, itself, part of the process!

The importance of process lies precisely in the shortcomings of people, as we already discussed people make mistakes, so their processes include checks and balances. People forget things, so their processes remind them of what needs to be done. People are imprecise, so their processes identify where precision is needed. And people are limited, so they rely on their processes to keep the important facts before them. Processes that do these things provide the support people need to mitigate for their shortcomings.

Processes are essentially nothing more than tools that mitigate for people’s shortcomings. Good processes make people able to harness their intellectual abilities and effectively apply them to solving problems.

When consistently applied, good processes produce predictable results. And documenting those processes allows multiple people to share them and work together toward common goals.

The role of tools

All software projects use tools. At the very least, they use an interpreter or compiler and linker. Most also use a code control system and something to track bugs.

The main purpose of tools is to make processes more efficient and people more productive. Many labor-intensive tasks can be done more efficiently by either replacing human effort with a tool (such as when we run automated tests) or by supplementing human effort (as is the case when the compiler converts source code we have written into object code).

Repetitive tasks that produce boredom in people (and the resultant errors) can often be relegated to tools. The key to ensuring that a tool is effective lies in making sure that it supports the people who do the work as well as the processes those people use. A tool supports the process when it makes that process less laborintensive and easier to follow.

Balancing people, process, and tools

People, processes, and tools: No one of these is more important than the others. Each has an important role to play in ensuring the success of our projects. None can be eliminated or de-emphasized without having an adverse effect on the project.

Our people are the source of the creativity, intellect, and vision that is required to build software. These key strengths make people indispensable to the task of creating software. But people’s shortcomings can jeopardize our projects’ success. Errors, oversights, miscommunication, and the like are common human frailties. People have come to depend on processes to mitigate for these shortcomings and make success more achievable.

Individuals rarely document their processes and often do not recognize that they follow them. But in organizations, attention to and documentation of process is the key to ensuring that the processes are followed consistently and modified when necessary so they remain beneficial to the organization. Finally, tools make both the people and their processes more efficient by leveraging people’s effort and taking over some of the more mundane (though critical) activities in our processes.

To be sure, there is a clear hierarchy: People require the support of processes, and tools must support both people and processes. But to claim that any one of them is more important than the others is to add unnecessary risk to our projects.

The 12 Principles of Agile Methods

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Few of us would argue that satisfying the customer is unimportant. The distinctive feature of this principle is the means by which the Agile methods pursue that goal.
“… through early…delivery of…software.” Agile methods tend to shun  long upfront requirements development and design activities. Rather, after laying an appropriate foundation (“appropriate” being defined differently for each method), they seek to develop working software as quickly as possible.

In essence, these methods replace the traditional requirements and design phases of development with early proof-of-concept activities. The Agile methods look very much like prototyping projects but with the distinction that the resulting product is delivered for use, instead of being thrown away.

“… through … continuous delivery of … software.” Agile methods all assume an incremental development strategy. They seek to mitigate risk by delivering increments quickly and often (every couple of weeks to every couple of months) so that the customer can validate the project’s decisions and assumptions and verify the utility of the resulting software.
“… through … delivery of valuable software.” Most Agile methods allow the customer to define what is most valuable and give the customer a significant role in establishing the order in which features are delivered.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This is the core principle on which the Agile methods are built and the reason why the name “Agile” was adopted. This principle acknowledges the fact that change is inevitable and establishes the philosophy that encouraging regular change is an advantage of the Agile methods for their customers. Rather than trying to suppress or control change, the Agile Methods are designed to allow—even encourage—change throughout the project’s life.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
This principle expands on the “continuous delivery” phrase from the first principle. It is explicit that the increments on Agile projects should be as short as possible and goes so far as to say that a week or two is not too short for an increment. It also sets an upper limit that might be surprising to many, since development phases of fewer than three months are generally not seen.

Business people and developers must work together daily throughout the project.
The Agile methods all require collaboration between the development team and the other stakeholders in the project. A most crucial role in Agile projects is given to the customer (or the ultimate user of the system being developed). But all other stakeholders (identified by these technophiles as “business people”) have important roles and are expected to interact with the team on a regular basis.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The Agile methods are all built on the assumption that development team members are all competent, motivated, supported by the organization, and empowered to do their jobs. At the same time, each method builds an environment that is intrinsically motivating to the technical staff and has the natural effect of building each staff member’s capability to self-motivate and self-manage.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is the principle that explains why the Agile methods tend to have few written documents. They all favor face-to-face communication as the primary means of sharing information, often supplementing it with tools such as whiteboards. The results of communication are often documented in the form of “information radiators,” which are visually available postings of information to which people can refer whenever it is needed.

Working software is the primary measure of progress.
This principle is another way in which the Agile methods strike against documentation. Most software projects will identify the acceptance of a requirements or design specification as a milestone showing significant progress. Many Agile methods (though not all) reject that idea. They tend to place little value on the project’s interim products and focus almost entirely on the resulting software. Of course, since working software is delivered so often on an Agile project (see the third principle), it becomes a reasonable
measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
In many organizations, overtime is the norm, and in some it is routinely required. The Agile methods rebel against those norms and argue instead for “sustainable” schedules (generally meaning something in the vicinity of 40 hours per week). And by this they do not mean to plan for 40 hours per week, then work 80; rather, they mean to change the expectation of what can be accomplished so that overtime is rare. But as this principle states, the nature of the Agile methods tends to level out the demands on the project team so that a more sustainable pace is naturally maintained.

Continuous attention to technical excellence and good design enhances agility.
This is perhaps the most valuable principle of the Agile methods. Each Agile method has a strong focus on ensuring that the quality of the technical work is maintained at a high level. The different methods do this in different ways, but each has a strong quality component.

This principle provides a refreshing counterpoint to the all-too-common perception that the developers’ job is to write the software and someone else is responsible for making sure it works. In the Agile methods, development teams take on the primary responsibility to be sure that what is delivered is correct and that the software satisfies the customer’s needs. This focus does not mean that independent verification and validation is unnecessary; rather, it means that the software that is delivered for IV&V will be of higher quality and generally more ready for final testing.

Simplicity—the art of maximizing the amount of work not done is essential.
Before the Agile Manifesto was written, the methods that fall under the “Agile” umbrella were generally referred to as “light” methods. The term “light” was dropped out of recognition that certain application domains require heavier processes (e.g., developing software for safety-critical systems). Even so, the Agile methods always stress using the lightest possible processes.

The best architectures, requirements, and designs emerge from self-organizing teams.
Self-management is a hallmark of Agile methods and a backlash against the command-and-control methods used to manage many software projects. There is growing evidence that self-managed teams are in fact quite effective.

But moving toward self-managed teams requires significant changes throughout the organization. The most significant change occurs in the ranks of management, where managers’ roles must evolve toward coaching and leading, as engineers’ roles grow to include self-management. These changes are difficult to effect and require that many people learn new skills and behaviors, but they can have significant positive results.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The concept of retrospective or postmortem analysis is well known in the industry (if not widely practiced). The Agile methods adopt this important activity as their primary means of improving their processes. Some Agile methods take this to an extreme by doing these analyses at the end of each increment of development, resulting in lessons learned and process improvements many times each year.