Great agile, scrum, lean and kanban online resources

• Mike Cottmeyer on what to focus on during agile adoption.
• Johanna Rothman on agile managers as generalists.
• Mike Cohn on agile design.
• Elisabeth Hendrickson talks about a definition of agile.
• Israel Gat on the business value of agile methods.
• Syed Rayhan on the SaaS Product Owner.
• Mike Cohn on not blaming only the Product Owner.
• Ash Maurya on Flow.
• Five Why’s on influence of XP vs. Scrum.
• Social, Agile and Transformation on failing fast, often and cheap.
• Johanna Rothman on ideal team size and ratios.
• Gojko Adzic on agile adoption.
• William Wake on embracing commitment.
• Diana Larson on values, principles and practices.
• Rob Bowley on agile needing fixing.
• Boris Gloger on not having a ScrumMaster be Product Owner.
• Laszlo Szalvay on personal heroics vs. team success.
• Ron Jeffries on the difficult inherent in inspect and adapt.
• Ralph Jocham on agile being about deliverables.
• Jason Yip on a small change to the agile manifesto.

There were some excellent online articles as well:

•  Agile Journal review of 5 new agile books.
• Scrum Alliance Fun Driven Development.
• Kanban Distilled for Managers
• InfoQ when the ScrumMaster becomes the impediment.
• Harvard Business Review The Builder’s Manifesto.
• Agile Journal Implementing Agile.
• Dr. Dobbs Journal 2009 Agile Update.
• Cutter Consortium 2010 Predictions.

The 5 biggest hits on this blog were:

• New to agile? Keep it very simple
• Agile antipattern: taking on large stories
• Agile antipattern: burndown charts that hide the truth
• Agile antipattern: burndown wall
• New to agile? Learn how to split stories

Read More!

Extreme project management

Extreme project management (XPM) refers to a method of managing very complex and very uncertain projects.
Extreme project management differs from traditional project management mainly in its open, elastic and undeterministic approach. The main focus of XPM is on the human side of project management (e.g. managing project stakeholders), rather than on intricate scheduling techniques and heavy formalism.
Extreme project management corresponds to extreme programming.
Advanced approaches to extreme project management utilize the principles of human interaction management to deal with the complexities of human collaboration.

Contents [hide] 1 Introduction 2 Extreme Programming and Agile 3 XPM Practices 4 XPM Planning 5 Release Plan 6 Weekly Planning Meeting 7 Stakeholder Management 8 Velocity 9 Weekly Tasks 10 Stand-Up Meetings 11 Stories 12 Testing 13 A “coach” for extreme team is a really good idea 14 Managing extreme environment 14.1 Give the Team a Dedicated Open Work Space 14.2 Set a Sustainable, Measurable, Predictable Pace 14.3 Daily Stand Up Meeting 14.4 Project Velocity 14.5 Move People Around 15 Extreme Project and Risk 16 Risk Management 17 Books 18 Literature 19 See also 20 External links

Introduction

Software project management is a sub-discipline of project management in which software projects are planned, monitored and controlled. Extreme Project Management (XPM) is an agile approach for managing project where the focus is on incremental planning instead of traditional one-time planning. It consists of a series of practices which help managers to control project schedules, assign work tasks, and assure that work is done efficiently and correctly.
XPM is based on agile software development model called Extreme Programming (XP). XP was developed fairly recently in response to problems that plagued other software development processes.

Extreme Programming and Agile

Agile software development is a set of methodologies based on iterative development approach where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. XP is one of the methodologies from the agile methods. Although developed fairly recently, XP has already attracted a large following of software developers, managers and customers. Its appeal for them: it works better than traditional software delivery methods.
XP is team-oriented and customer-focused, where teams range in size from small to medium with the customer as an integral part of the team. It insures that the customer’s need are addressed through out the development process and XP practices help the team determine and deliver exactly what the customer wants, even if the requirements change over time. Main features of XP are simplicity, communication, feedback, gradual development and commitment.

XPM Practices

Since project management deals with planning as well as with monitoring and control, XPM follows suit. XPM practices can be divided into two types: planning practices and control practices. Planning practices consist of the Release Plan, Weekly Plan, and Stories. The rest of the practices focus on quality control and are used daily.

XPM Planning

Simplicity is one major feature of XP, and in XPM it is the biggest concern. XPM planning practices are simple. There is no need for critical path methods or project management software. Everything can be done by using very common software for example text editors and spread sheets.
Main activities of XPM planning are as follow:

• Create a Release Plan
• Create Weekly Plan based on the Release Plan (weekly plans)
• Allocate Daily Tasks based on the Weekly Plan

Release Plan

Release Plan is the first artefact for XPM. It describes all the work to be done for the current project phase. It is usually created by the project manager, aided by team members, before work begins. Each work phase have a separate Release Plan for example release plan for schematics, design development, contract documents, etc.
XPM Release Plan contains the following activities:

• Identify all the tasks required to complete the work.
• For each task, write a brief description on an index card.
• Estimate the time required to complete a task and add it to the card.

Release plan is a stack of all the index cards. When all the tasks are written on the index cards and time estimation is done, the release plan is ready for use. The major concern is identifying tasks and estimating time for each task. Since this model is based on simplicity and follows the agile approach. Therefore the tasks should be defined in a way that no task should be more than 3 days long and time estimation should be done in ideal hours, number of hours to complete the task without interruption. Longer tasks should be divided into smaller tasks and insuring that all tasks are correct and complete. Description for the task should also be brief and it should focus on what to do instead of how to do it.
The Release Plan can and probably will change during the course of the project. Time estimates are not fixed either. They probably will be modified by the team members during weekly planning meetings.

Weekly Planning Meeting

The Weekly Planning Meeting is an integral part of the XPM planning process. The purpose of the meeting is to assign the week's tasks. All team members attend. It is important that the time interval between meetings be consistent. Meetings should be held weekly, at the same day, time, and place each week.
Prior to the meeting, the project manager selects tasks for the week. Task cards for work remaining are usually arranged on a table in stacks, by priority or by weeks. The PM goes through the stacks, chooses the highest priority tasks, and brings them into the meeting. The number of tasks selected should be based on the prior week's work efforts that are known as velocity in XPM.

Stakeholder Management

Stakeholders have an important role in XPM. Each stakeholder see different side of the project, so it is necessary to brought them together in order to understand the complete view of the project. Similar to Rapid Application Development (RAD), XPM applies a concept called Rapid Planning (RAP) for producing project plans.
The aim of RAP sessions is to identify the requirements and other important issues needed for the project. Stakeholders will be invited by the project manager for the RAP sessions to progress through a sequence of steps that includes planning the project in an intensive and participative process. RAP provides the mechanism where the conflict between stakeholders can be recognized and resolved before the project continues. The RAP session helps the stakeholders to put forth the disagreements on the table for further discussion. Project Manager supposed to finalize the goals and it is important to agree upon the scope and goals of the project among the stakeholders.
XPM applies five tools during RAP process. This helps to bring transparency and ownership for the stakeholders. Normally RAP process must have full participation by stakeholders. The tools are

• Success sliders: This technique identifies the expectations of the stakeholders. Meeting stakeholder expectations will be satisfying different criteria which includes making the stakeholders satisfied, Achieving functional requirements, meeting budget and deadlines, ensuring value and quality and making the team members satisfied.

• The O3 model: This techniques helps to model and realize benefits for projects. The model is based on three elements: objectives, outputs and outcomes, which create the project value chain.

• Quality agreements: The process of software quality planning is about finding out what the required quality is and what processes are to be present during the development process to ensure this quality.

• Project or partnership agreements: The risks which will delay the project need to be identified at early stages. To be able to foresee these events to happen, the project manager should prepare a document stating the services required by stakeholders and related project managers.

• Event/real-time planning: This includes identifying major events and scenarios that could be involved in delivering the project. The important issue to remember when doing this kind of planning is that only the tasks involved in achieving the specific event are detailed and scheduled.

Velocity

Velocity is the number of points (ideal hours) completed by the team per week. The idea behind velocity is simple: If a team did “X” hours last week, it will do “X” hours this week as well. The idea of velocity is important to control and monitor the performance of the team. However there are some challenges involved in it. Estimating the time for a task should be consistent and should consider the difficulty of tasks for a real estimation. If the velocity remains constant through out the project, it reflects that the team is performing in ideal situation. If this is not the case then there might be a problem with time estimations, task allocation of team efforts. Therefore velocity helps finding the problem area and to resolve it.

Weekly Tasks

Weekly tasks will be allocated in weekly meetings. Manager will select the tasks from the Release plan based on their priority and/or their dependency on other relevant task. Manager should have enough tasks for the whole team for a week. Each card is discussed within the team, time estimates are revised and tasks are reorganized. Tasks are further divided into sub task so that no task should be more than 8 hours work efforts. Requirements are clarified. After that each person from the team selects the task and signs the index card against ones name. When the task is complete, time estimate will be updated and the card is put to the “Done” pile of release plan.

Stand-Up Meetings

Stand up meetings are held frequently to facilitate communication and keep team members informed.

• Daily Stand-Ups: Start each day with a short stand-up meeting. Each team member describes work on current task, identifies potential problems.
• Ad-Hoc Stand Ups: Anyone can call for a stand-up to discuss a pressing issue.

Stories

A user story is a sub set of functionality (also known as feature) that is of value to the customer. It provides a simple way for developers and customers to chop up what the system needs to do so the system can be delivered in pieces.
The emphasis on the word simple is essential. Since it is an agile approach so there is no need for a detailed requirement engineering process, however some of the RE practices can be adopted. XP looks for the simplest approach that could possibly work. A story actually describes the functionality required by the customer. It might refer to a change in the existing functionality, additional requirement or extended requirements.

Testing

Testing in XPM is different from traditional test plans and practices. In XPM testing is an essential part of process and one have to test everything that probably could break. Each task is tested and verified and tests should be automated so that it can be performed later if there is a change. Testing is usually performed with two aspects, correctness and completeness of the task. Both aspects assure that all the tasks work properly and the system has all the functionality required by the customer. Project tests are created by the manager and assisted by the team to assure that the goals of the project are met. In XP, tests are written first and then the code is written to pass the test. Peer reviews are common to verify the correctness and completeness of the tasks.

A “coach” for extreme team is a really good idea

The manager’s role is one of great importance and responsibility in software projects. With the advent of Agile methodologies, this role has undergone drastic changes. XP has the Coach; other mixed methods and home-rolled versions of Agile have different definitions of the manager’s role
First and foremost, in principle, project management is usually divided up in project planning for projects which are not started yet and project controlling and management, respectively, for running projects.
Naturally, project management can just be as good as the person who is responsible for it, i.e. the project manager. However, a project manager of an XP project is not simply a project coordinator and supervisor in the well-known context. On the one hand he or she must be less than that, as responsibility is largely shifted to the team members: on the other hand he or she must be more than that, namely an excellent moderator.
Project Manager has to support the programmers in a way that problems can be solved by themselves, i.e. by team work. Though the Project Manager has a strategic position within the project he or she also gives know-how to the project members. However, know-how in this context equally means strategic, technical and application know-how. The larger the project the less likely it is that the moderator will program himself and therefore has not to be a good programmer. The Project Manager in XPM must be like an obstetrician so that complex ideas can be born, formulated, cut into components for the subprojects and realized. Finally, he or she takes care that the potential of each project member can be exhausted in an optimal way. Altogether, the Project Manager supports the team in questions of method, motivation, communication, and cooperation. The project manager would typically sign up for tracking, the status and report.

Managing extreme environment

Give the Team a Dedicated Open Work Space

Communication is very important to an Extreme Programming (XP) team. Putting computers in a central area that no one owns makes pair programming easier and encourages people to work together with feelings of equal value and contributions. Putting a few desks around the perimeter gives people a place to work alone without becoming disconnected from the rest of the team.
Including a large area for daily stand up meetings keeps people from missing the meeting. Adding a conference table gives the group a home for group discussions that occur spontaneously throughout the day. Being able to see the discussions encourages people to listen in or join the discussion when they have a stake in the out come.
Adding white boards for design sketches and important notes or blank walls where user story cards can be taped adds even more channels for communication. Posting a couple large charts targeting process improvement or project progress informs the team without management hounding them about progress.

Set a Sustainable, Measurable, Predictable Pace

To set pace extreme project manager needs to take iteration ends seriously. Manager wants the most completed, tested, integrated, production ready software. If it looks like manager will not be able to get everything finished by iteration end have an iteration planning meeting and re-scope the iteration to maximize project velocity.
Working overtime delimits the spirit and motivation out of team. When team becomes tired and demoralized they will get less work done, not more, no matter how many hours are worked. Becoming over worked today steals development progress from the future. Realistic plans can't make when team does more.
Becoming over worked today steals development progress from the future. Manager can not make realistic plans when team does more work this month and less next month. Instead of pushing people to do more than humanly possible use a release planning meeting to change the project scope or timing.
Adding more people is also a bad idea when a project is already late. The contribution made by many new people is usually negative. Instead ramp up development team slowly well in advance, as soon as you predict a release will be too late.
A sustainable pace helps manager to plan releases and iterations and keeps from getting into a death march. Manager needs to find his or her team's perfect velocity that will remain consistent for the entire project. Every team is different. Demanding this team increase velocity to match that team will actually lower their velocity long term. So what ever team's velocity is manager just accepts it, guards it, and uses it to make realistic plans

Daily Stand Up Meeting

At a typical project meeting most attendees do not contribute, but attend just to hear the outcome. A large amount of developer time is wasted to gain a trivial amount of communication. Having many people attend every meeting drains resources from the project and also creates a scheduling nightmare.
Communication among the entire team is the purpose of the stand up meeting. A stand up meeting every morning is used to communicate problems, solutions, and promote team focus. Everyone stands up in a circle to avoid long discussions. It is more efficient to have one short meeting that every one is required to attend than many meetings with a few developers each.
When you have daily stand up meetings any other meeting's attendance can be based on who will actually be needed and will contribute. Now it is possible to avoid even scheduling most meetings. With limited attendance most meetings can take place spontaneously in front of a computer, where code can be browsed and ideas actually tried out.
During a stand up meeting developers report at least three things; what was accomplished yesterday, what will be attempted today, and what problems are causing delays. The daily stand up meeting is not another meeting to waste people's time. It will replace many other meetings giving a net savings several times its own length.

Project Velocity

The project velocity (or just velocity) is a measure of how much work is getting done on project. To measure the project velocity manager simply add up the estimates of the user stories that were finished during the iteration. Manager also total up the estimates for the tasks finished during the iteration. Both of these measurements are used for iteration planning.
During the iteration planning meeting customers are allowed to choose the same number of user stories equal to the project velocity measured in the previous iteration. Those stories are broken down into technical tasks and the team is allowed to sign up for the same number of tasks equal to the previous iteration's project velocity.
This simple mechanism allows developers to recover and clean up after a difficult iteration and averages out estimates. Project velocity goes up by allowing developers to ask the customers for another story when their work is completed early and no clean up tasks remain.
A few ups and downs in project velocity are expected. Manager should use a release planning meeting to re-estimate and re-negotiate the release plan if project velocity changes dramatically for more than one iteration. Expect the project velocity to change again when the system is put into production due to maintenance tasks.
Project velocity is about as detailed a measure as project manager can make that will be accurate. Managers don't need dividing the project velocity by the length of the iteration or the number of people. This number isn't any good to compare two project's productivity. Each project team will have a different bias to estimating stories and tasks, some estimate high, some estimate low. It doesn't matter in the long run. Tracking the total amount of work done during each iteration is the key to keeping the project moving at a steady predictable pace.
The problem with any project is the initial estimate. Collecting lots of details does not make your initial estimate anything other than a guess. Worry about estimating the overall scope of the project and get that right instead of creating large documents. Consider spending the time you would have invested into creating a detailed specification on actually doing a couple iterations of development. Measure the project velocity during these initial explorations and make a much better guess at the project's total size.

Move People Around

Move people around to avoid serious knowledge loss and coding bottle necks. If only one person on a team can work in a given area and that person leaves or just has too much to do, manager will find the project's progress reduced to a crawl.
Cross training is often an important consideration in companies trying to avoid islands of knowledge, which are so susceptible to loss. Moving people around the code base in combination with pair programming does cross training for team. Instead of one person who knows everything about a given section of code, everyone on the team knows much of the code in each section.
A team is much more flexible if everyone knows enough about every part of the system to work on it. Instead of having a few people overloaded with work while other team members have little to do, the whole team can be productive. Any number of developers can be assigned to the hottest part of the system. Flexible load balancing of this type is a manager's dream come true.
Mangers need to compose the team to have everyone they need to be successful. Cross functional teams can be left alone to become self organizing and self disciplined. If some specialized expertise is needed add a specialist to the team for a week and let many of your team members interact with the specialist.
Simply encourage everyone to try working on a new section of the system at least part of each iteration. Pair programming makes it possible without losing productivity and ensures continuity of thought. One person from a pair can be swapped out while the other continues with a new partner if desired.

Extreme Project and Risk

The development of software systems is a risky endeavor that usually encompasses constraints of schedule and budget. Several methodologies are proposed to remedy the problems encountered in traditional development methodologies used in software engineering. Currently, extreme programming is considered as the most famous and prominent agile methodology which is based on twelve best practices of which the following are core practices: Customer On Site, Planning Game, collective Code Ownership, Simple Design. The risk factors that might occur if the Customer is not On Site include changing requirements, cost of communication, decisions not forthcoming, difficulty in communication and incomplete requirements. Similarly, the risk factors that might occur if the Planning Game is not applied include changing priority and bad fit to schedule. The risk elements that might occur if the Code Ownership practice is not applied include architectural degeneration. Also, the risk factors that might occur if the Simple Design practice is not applied include changing requirements.

Risk Management

The success of project is based on stakeholder satisfaction, schedule, scope, quality, budget, return on investment and team satisfaction. And Risk management does follow two rules on these areas: (1) Recognize the real need and (2) Respond appropriately. In sum, recognizing the real need would have been to:

• Place Stakeholder Satisfaction as a "Must Meet" condition. Everything would have been in vain if Stakeholder Satisfaction were not met at some predefined measure of success. Put another way, if all other conditions were met and Stakeholder Satisfaction was not, the project would be considered as having woefully missed the mark.
• Optimize Schedule to respond to risk appropriately
• Keep Resources, Scope, Quality, ROI, and Team Satisfaction within acceptable tolerances. (In absence of Schedule, they appeared to be optimizing Scope and/or Quality.)

Books

• Ajani, Shaun H. Extreme Project Management: Unique Methodologies - Resolute Principles - Astounding Results.

• Doug DeCarlo eXtreme Project Management: Using Leadership and Tools to Deliver Value in the Face of Volatility

• Craig Larman Agile and Iterative Development: A Manager's Guide

• Ken Schwaber Agile Project Management with Scrum (Microsoft Professional)

• Ken Schwaber, Mike Beedle Agile Software Development with SCRUM

• Mary Poppendieck, Tom Poppendieck Lean Software Development: An Agile Toolkit for Software Development Managers

• Mike Cohn Agile Estimating and Planning (Robert C. Martin Series

• Highsmith, Jim. Agile Project Management: Creating Innovative Products.

• Thomsett, Rob. Radical Project Management.

• Wysocki, Robert K., Rudd McGary. Effective Project Management: Traditional, Adaptive, Extreme

• Harrison-Broninski, Keith. Human Interactions: The Heart and Soul of Business Process Management.

Literature

• Whitty, S.J. and Maylor, H. (2007). And then came Complex Project Management. 21st IPMA World Congress on Project Management. http://espace.library.uq.edu.au/view.php?pid=UQ:13419. 

• Bernhard Rumpe and Peter Scholz (2003). Scaling The Management Of Extreme Programming Projects. Projects & Profits. Special Issue on Management of Extreme Programming Projects, Vol. III (8), pp. 11-18. ICFAI Press, Hyderabat. 

• Rashina Hoda, James Noble, Stuart Marshall. Exploring the Role of the Manager in Agile Projects. 

• Houda Zouari Ounaies1, Yassine Jamoussi2, Mohamed Ben Ahmed3 (2006). Project Management Improvement in Extreme Programming. RPM-AEMES, VOL. 3, No 1. 

• Orit Hazzan and Yael Dubinsky. Clashes between Culture and Software Development Methods: The Case of the Israeli Hi-Tech Industry and Extreme Programming. 

Orit Hazzan and Jim Tomayko. Human Aspects of Software Engineering: The Case of Extreme Programming. Read More!

Extreme Programming Practices

Jump to: navigation, search

Extreme Programming (XP) is a popular agile software development methodology used to implement software projects. This article details the practices used in this methodology. Extreme Programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.^[1]

Contents [hide] 1 Fine scale feedback 1.1 Pair programming 1.2 Planning game 1.2.1 Release planning 1.2.1.1 Exploration phase 1.2.1.2 Commitment phase 1.2.1.2.1 Sort by value 1.2.1.2.2 Sort by risk 1.2.1.3 Steering phase 1.2.2 Iteration planning 1.2.2.1 Exploration phase 1.2.2.2 Commitment phase 1.2.2.3 Steering phase 1.3 Test driven development 1.4 Whole team 2 Continuous process 2.1 Continuous integration 2.2 Design improvement 2.3 Small releases 3 Shared understanding 3.1 Coding standard 3.2 Collective code ownership 3.3 Simple design 3.4 System metaphor 4 Programmer welfare 4.1 Sustainable pace 5 See also 6 References 7 External links

Fine scale feedback

Pair programming

Pair programming means that all code is produced by two people programming on one task on one workstation. One programmer has control over the workstation and is thinking mostly about the coding in detail. The other programmer is more focused on the big picture, and is continually reviewing the code that is being produced by the first programmer. Programmers trade roles regularly.
The pairs are not fixed: it's recommended that programmers try to mix as much as possible, so that everyone knows what everyone is doing, and everybody can become familiar with the whole system. This way, pair programming also can enhance team-wide communication. (This also goes hand-in-hand with the concept of Collective Ownership).

Planning game

The main planning process within Extreme Programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts:

• Release Planning: This is focused on determining what requirements are included in which near-term releases, and when they should be delivered. The customers and developers are both part of this. Release Planning consists of three phases:
  • Exploration Phase: In this phase the customer will provide a short list of high-value requirements for the system. These will be written down on user story cards.
  • Commitment Phase: Within the commitment phase business and developers will commit themselves to the functionality that will be included and the date of the next release.
  • Steering Phase: In the steering phase the plan can be adjusted, new requirements can be added and/or existing requirements can be changed or removed.

• Iteration Planning: This plans the activities and tasks of the developers. In this process the customer is not involved. Iteration Planning also consists of three phases:
  • Exploration Phase: Within this phase the requirement will be translated to different tasks. The tasks are recorded on task cards.
  • Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated.
  • Steering Phase: The tasks are performed and the end result is matched with the original user story.

The purpose of the Planning Game is to guide the product into delivery. Instead of predicting the exact dates of when deliverables will be needed and produced, which is difficult to do, it aims to "steer the project" into delivery using a straightforward approach. ^[2]

Release planning

Exploration phase

This is an iterative process of gathering requirements and estimating the work impact of each of those requirements.

• Write a Story: Business has come with a problem; during a meeting, development will try to define this problem and get requirements. Based on the business problem, a story has to be written. This is done by business, where they point out what they want a part of the system to do. It is important that development has no influence on this story. The story is written on a user story card.
• Estimate a Story: Development estimates how long it will take to implement the work implied by the story card. Development can also create spike solutions to analyze or solve the problem. These solutions are used for estimation and discarded once everyone gets clear visualization of the problem. Again, this may not influence the business requirements.
• Split a Story: Every design critical complexity has to be addressed before starting the iteration planning. If development isn't able to estimate the story, it needs to be split up and written again.

When business cannot come up with any more requirements, one proceeds to the commitment phase.

Commitment phase

This phase involves the determination of costs, benefits, and schedule impact. It has four components:

• Sort by Value: Business sorts the user stories by Business Value.
• Sort by Risk: Development sorts the stories by risk.
• Set Velocity: Development determines at what speed they can perform the project.
• Choose scope: The user stories that will be finished in the next release will be picked. Based on the user stories the release date is determined.

Sort by value

The business side sorts the user stories by business value. They will arrange them into three piles:

• Critical: stories without which the system cannot function or has no meaning.
• Significant Business Value: Non-critical user stories that have significant business value.
• Nice to have: User stories that do not have significant business value.

Sort by risk

The developers sort the user stories by risk. They also categorize into three piles: low, medium and high risk user stories. The following is an example of an approach to this:

• Determine Risk Index: Give each user story an index from 0 to 2 on each of the following factors:
  • Completeness (do we know all of the story details?)
    • Complete (0)
    • Incomplete (1)
    • Unknown (2)
  • Volatility (is it likely to change?)
    • low (0)
    • medium (1)
    • high (2)
  • Complexity (how hard is it to build?)
    • simple (0)
    • standard (1)
    • complex (2)

All indexes for a user story are added, assigning the user stories a risk index of low (0–1), medium (2–4), or high (5–6).

Steering phase

Within the steering phase the programmers and business people can "steer" the process. That is to say, they can make changes. Individual user stories, or relative priorities of different user stories, might change; estimates might prove wrong. This is the chance to adjust the plan accordingly.

Iteration planning

Exploration phase

The exploration phase of the iteration planning is about creating tasks and estimating their implementation time.

• Translate the requirement to tasks: Place on task cards.
• Combine/Split task: If the programmer cannot estimate the task because it is too big or too small, the programmer will need to combine or split the task.
• Estimate task: Estimate the time it will take to implement the task.

Commitment phase

Within the commitment phase of the iteration planning programmers are assigned tasks that reference the different user stories.

• A programmer accepts a task: Each programmer picks a task for which he or she takes responsibility.
• Programmer estimates the task: Because the programmer is now responsible for the task, he or she should give the eventual estimation of the task.
• Set load factor: The load factor represents the ideal amount of hands-on development time per programmer within one iteration. For example, in a 40-hour week, with 5 hours dedicated to meetings, this would be no more than 35 hours.
• Balancing: When all programmers within the team have been assigned tasks, a comparison is made between the estimated time of the tasks and the load factor. Then the tasks are balanced out among the programmers. If a programmer is overcommitted, other programmers must take over some of his or her tasks and vice versa.

Steering phase

The implementation of the tasks is done during the steering phase of the iteration planning.

• Get a task card: The programmer gets the task card for one of the tasks to which he or she has committed.
• Find a Partner: The programmer will implement this task along with another programmer. This is further discussed in the practice Pair Programming.
• Design the task: If needed, the programmers will design the functionality of the task.
• Write unit test: Before the programmers start coding the functionality they first write automated tests. This is further discussed in the practice Unit Testing.
• Write code: The programmers start to code.
• Run test: The unit tests are run to test the code.
• Refactor: Remove any code smells from the code.
• Run Functional test: Functional tests (based on the requirements in the associated user story and task card) are run.

Test driven development

Unit tests are automated tests that test the functionality of pieces of the code (e.g. classes, methods). Within XP, unit tests are written before the eventual code is coded. This approach is intended to stimulate the programmer to think about conditions in which his or her code could fail. XP says that the programmer is finished with a certain piece of code when he or she cannot come up with any further condition on which the code may fail.

Whole team

Within XP, the "customer" is not the one who pays the bill, but the one who really uses the system. XP says that the customer should be on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator.

Continuous process

Continuous integration

The development team should always be working on the latest version of the software. Since different team members may have versions saved locally with various changes and improvements, they should try to upload their current version to the code repository every few hours, or when a significant break presents itself. Continuous integration will avoid delays later on in the project cycle, caused by integration problems.

Design improvement

Because XP doctrine advocates programming only what is needed today, and implementing it as simply as possible, at times this may result in a system that is stuck. One of the symptoms of this is the need for dual (or multiple) maintenance: functional changes start requiring changes to multiple copies of the same (or similar) code. Another symptom is that changes in one part of the code affect lots of other parts. XP doctrine says that when this occurs, the system is telling you to refactor your code by changing the architecture, making it simpler and more generic.

Small releases

The delivery of the software is done via frequent releases of live functionality creating concrete value. The small releases help the customer to gain confidence in the progress of the project. This helps maintain the concept of the whole team as the customer can now come up with his suggestions on the project based on real experience.

Shared understanding

Coding standard

Coding standard is an agreed upon set of rules that the entire development team agree to adhere to throughout the project. The standard specifies a consistent style and format for source code, within the chosen programming language, as well as various programming constructs and patterns that should be avoided in order to reduce the probability of defects^[3]. The coding standard may be a standard conventions specified by the language vendor (e.g The Code Conventions for the Java Programming Language, recommended by Sun), or custom defined by the development team.

Collective code ownership

Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code. Pair programming contributes to this practice: by working in different pairs, all the programmers get to see all the parts of the code. A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.
By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies. Sufficiently well defined unit tests address this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.

Simple design

Programmers should take a "simple is best" approach to software design. Whenever a new piece of code is written, the author should ask themselves 'is there a simpler way to introduce the same functionality?'. If the answer is yes, the simpler course should be chosen. Refactoring should also be used, to make complex code simpler.

System metaphor

The system metaphor is a story that everyone - customers, programmers, and managers - can tell about how the system works. It's a naming concept for classes and methods that should make it easy for a team member to guess the functionality of a particular class/method, from its name only. For example a library system may create loan_records(class) for borrowers(class), and if the item were to become overdue it may perform a make_overdue operation on a catalogue (class). For each class or operation the functionality is obvious to the entire team.

Programmer welfare

Sustainable pace

The concept is that programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime. Since the development cycles are short cycles of continuous integration, and full development (release) cycles are more frequent, the projects in XP do not follow the typical crunch time that other projects require (requiring overtime).
Also, included in this concept is that people perform best and most creatively if they are rested.
A key enabler to achieve sustainable pace is frequent code-merge and always executable & test covered high quality code. The constant refactoring way of working enforces team members with fresh and alert minds. The intense collaborative way of working within the team drives a need to recharge over weekends.
Well-tested, continuously integrated, frequently deployed code and environments also minimize the frequency of unexpected production problems and outages, and the associated after-hours nights and weekends work that is required. Read More!

Total Productive Maintenance (TPM)

Total productive maintenance (TPM) is a new way of looking at maintenance, or conversely, a reversion to old ways but on a mass scale. In TPM the machine operator performs much, and sometimes all, of the routine maintenance tasks themselves. This auto-maintenance ensures appropriate and effective efforts are expended since the machine is wholly the domain of one person or team. TPM is a critical adjunct to lean manufacturing. If machine uptime is not predictable and if process capability is not sustained, the process must keep extra stocks to buffer against this uncertainty and flow through the process will be interrupted.. One way to think of TPM is "deterioration prevention" and "maintenance reduction", not fixing machines. For this reason many people refer to TPM as "total productive manufacturing" or "total process management". TPM is a proactive approach that essentially aims to prevent any kind of slack before occurrence. Its motto is "zero error, zero work-related accident, and zero loss".

Contents [hide] 1 Introduction 2 History 3 Implementation 4 Further reading 5 References

Introduction

TPM is a maintenance process developed for productivity.
Original goal of total productive management:

“Continuously improve all operational conditions, within a production system; by stimulating the daily awareness of all employees” (by Seiichi Nakajima, Japan, JIPM)

TPM focuses primarily on manufacturing and is the first methodology Toyota used to improve its global position (1950’s). After TPM, the focus was stretched, and also supplier and customer were involved, this next methodology was called lean manufacturing. This sheet gives an overview of TPM in its original form.
An accurate and practical implementation of TPM, will increase productivity within the total organization, where:
(1) .. a clear business culture is designed to continuously improve the efficiency of the total production system
(2) .. a standardized and systematic approach is used, where all losses are prevented and/or known.
(3) .. all departments, influencing productivity, will be involved to move from a reactive- to a predictive mindset.
(4) .. a transparent multidisciplinary organization is reaching zero losses.
(5) .. steps are taken as a journey, not as a quick menu.
Finally TPM will provide practical and transparent ingredients to reach operational excellence.

History

TPM is a Japanese idea that can be traced back to 1951 when preventive maintenance was introduced into Japan from the USA. Nippondenso, part of Toyota, was the first company in Japan to introduce plant wide preventive maintenance in 1960. In preventive maintenance operators produced goods using machines and the maintenance group was dedicated to the work of maintaining those machines. However with the high level of automation of Nippondenso maintenance became a problem as so many more maintenance personnel were now required. So the management decided that the routine maintenance of equipment would now be carried out by the operators themselves (this is autonomous maintenance, one of the features of TPM). The maintenance group then focussed only on 'maintenance' works for upgrades.
The maintenance group performed equipment modification that would improve its reliability. These modifications were then made or incorporated into new equipment. The work of the maintenance group is then to make changes that lead to maintenance prevention. Thus preventive maintenance along with maintenance prevention and maintainability improvement were grouped as productive maintenance. The aim of productive maintenance was to maximize plant and equipment effectiveness to achieve the optimum life cycle cost of production equipment.
Nippondenso already had quality circles which involved the employees in changes. Therefore, now, all employees took part in implementing Productive maintenance. Based on these developments Nippondenso was awarded the distinguished plant prize for developing and implementing TPM, by the Japanese Institute of Plant Engineers (JIPE). Thus Nippondenso of the Toyota group became the first company to obtain the TPM certifications.

Implementation

TPM has five goals ^[1]
TPM identifies the 16 losses (types of waste) (muda) and then works systematically to eliminate them by making improvements (kaizen). TPM has 8 pillars of activity^{[citation needed]}, each being set to achieve a “zero” target. These 8 pillars are the following: focussed improvement; autonomous maintenance; planned maintenance; training and education; early-phase management; quality maintenance; office TPM; and safety, health, and environment.
TPM success measurement - A set of performance metrics which is considered to fit well in a lean manufacturing/TPM environment is overall equipment effectiveness, or OEE. Read More!

Kaizen

The term kaizen (改善, Japanese for "improvement") is a Japanese word adopted into English referring to a philosophy or practices focusing on continuous improvement in manufacturing activities, business activities in general, and even life in general, depending on interpretation and usage. When used in the business sense and applied to the workplace, kaizen typically refers to activities that continually improve all functions of a business, from manufacturing to management and from the CEO to the assembly line workers.^[1] By improving standardized activities and processes, kaizen aims to eliminate waste (see lean manufacturing). Kaizen was first implemented in several Japanese businesses during the country's recovery after World War II and has since spread to businesses throughout the world.^[2]

Contents [hide] 1 Introduction 2 Translation 3 History 4 Implementation 4.1 The five main elements of kaizen 4.2 Major results 5 Criticism 6 See also 7 References 8 Further reading 9 External links

Introduction

The Japanese word "kaizen" means simply "improvement," with no inherent meaning of either "continuous" or "Japanese philosophy"; the word refers to any improvement, one-time or continuous, large or small, in the same sense as the mundane English word "improvement".^[3] However, given the common practice in Japan of labeling industrial or business improvement techniques with the word "kaizen" (for lack of a specific Japanese word meaning "continuous improvement" or "philosophy of improvement"), especially in the case of oft-emulated practices spearheaded by Toyota, the word kaizen in English is typically applied to measures for implementing continuous improvement, or even taken to mean a "Japanese philosophy" thereof. The discussion below focuses on such interpretations of the word, as frequently used in the context of modern management discussions.^{[citation needed]}
Kaizen is a daily activity, the purpose of which goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work ("muri"), and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes. The philosophy can be defined as bringing back the thought process into the automated production environment dominated by repetitive tasks that traditionally required little mental participation from the employees.^{[citation needed]}
People at all levels of an organization can participate in kaizen, from the CEO down, as well as external stakeholders when applicable. The format for kaizen can be individual, suggestion system, small group, or large group. At Toyota, it is usually a local improvement within a workstation or local area and involves a small group in improving their own work environment and productivity. This group is often guided through the kaizen process by a line supervisor; sometimes this is the line supervisor's key role. Kaizen on a broad, cross-departmental scale in companies, generates total quality management, and frees human efforts through improving productivity using machines and computing power.^{[citation needed]}
While kaizen (at Toyota) usually delivers small improvements, the culture of continual aligned small improvements and standardization yields large results in the form of compound productivity improvement. This philosophy differs from the "command and control" improvement programs of the mid-twentieth century. Kaizen methodology includes making changes and monitoring results, then adjusting. Large-scale pre-planning and extensive project scheduling are replaced by smaller experiments, which can be rapidly adapted as new improvements are suggested.^{[citation needed]}
In modern usage, a focused kaizen that is designed to address a particular issue over the course of a week is referred to as a "kaizen blitz" or "kaizen event". These are limited in scope, and issues that arise from them are typically used in later blitzes.^{[citation needed]}

Translation

The original kanji characters for this word are: "改 善" (see 改 and 善)
In Japanese this is pronounced "kaizen".^[4]

• 改 ("kai") means "change" or "the action to correct".
• 善 ("zen") means "good".

In Korean this is pronounced "ge sun"

• 改善 ("gae seon") means "improvement" or "change for the better"

In Mandarin this is pronounced "gǎi shàn":

• 改善 ("gǎi shàn") means "change for the better" or "improve".
• 改 ("gǎi") means "change" or "the action to correct".
• 善 ("shàn") means "good" or "benefit". "Benefit" is more related to the Taoist or Buddhist philosophy, which gives the definition as the action that 'benefits' the society but not one particular individual (i.e., multilateral improvement). In other words, one cannot benefit at another's expense. The quality of benefit that is involved here should be sustained forever, in other words the "shan" is an act that truly benefits others.

History

In Japan, after World War II, American occupation forces brought in American experts in statistical control methods and who were familiar with the War Department's Training Within Industry (TWI) training programs to restore the nation. TWI programs included Job Instruction (standard work) and Job Methods (process improvement). In conjunction with the Shewhart cycle taught by W. Edwards Deming, and other statistics-based methods taught by Joseph M. Juran, these became the basis of the kaizen revolution in Japan that took place in the 1950s.^[5]

Implementation

The Toyota Production System is known for kaizen, where all line personnel are expected to stop their moving production line in case of any abnormality and, along with their supervisor, suggest an improvement to resolve the abnormality which may initiate a kaizen.

The PDCA cycles

The cycle of kaizen activity can be defined as:

• Standardize an operation
• Measure the standardized operation (find cycle time and amount of in-process inventory)
• Gauge measurements against requirements
• Innovate to meet requirements and increase productivity
• Standardize the new, improved operations
• Continue cycle ad infinitum

This is also known as the Shewhart cycle, Deming cycle, or PDCA.
Masaaki Imai made the term famous in his book Kaizen: The Key to Japan's Competitive Success.
Apart from business applications of the method, both Anthony Robbins and Robert Maurer have popularized the kaizen principles into personal development principles. The basis of Robbins' CANI (Constant and Never-Ending Improvement) method in kaizen is discussed in his Lessons in Mastery series.
In their book The Toyota Way Fieldbook, Brijesh Rawat, Jeffrey Liker, and David Meier discuss the kaizen blitz and kaizen burst (or kaizen event) approaches to continuous improvement. A kaizen blitz, or rapid improvement, is a focused activity on a particular process or activity. The basic concept is to identify and quickly remove waste. Another approach is that of kaizen burst, a specific kaizen activity on a particular process in the value stream.^[6]
Key elements of kaizen are quality, effort, involvement of all employees, willingness to change, and communication.

The five main elements of kaizen

• Teamwork
• Personal discipline
• Improved morale
• Quality circles
• Suggestions for improvement

Major results

• Elimination of waste (muda) and incorporation of efficiency
• The kaizen five - S framework for a well organized shop floor
  • Seiri - tidiness
  • Seiton - orderliness
  • Seiso - cleanliness
  • Seiketsu - standardization
  • Shitsuke - sustaining the discipline

Criticism

Kaizen is primarily a reactive process where you "check" to see if anything is wrong, then go about fixing it (in contrast, Risk Management is proactive). While this works for lower level processes, it must be advanced to include a creative element where one actively looks for ways of improving - the key being that the worker needs to know what is important to the company to improve. There should also be room for cases where a worker makes a recommendation that doesn't fit the mold of the company's target improvements. Many new companies have started due to workers who saw a means of quantum improvement which their original employer failed to recognize despite being highlighted by the worker. Read More!

Extreme Programming

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,^[1][2][3] it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.
Other elements of Extreme Programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.^[2][3][4] The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if some is good, more is better. It is unrelated to "cowboy coding", which is more free-form and unplanned. It does not advocate "death march" work schedules, but instead working at a sustainable pace.^[5]
Critics have noted several potential drawbacks,^[6] including problems with unstable requirements, no documented compromises of user conflicts, and lack of an overall design spec or document.

Contents [hide] 1 History 1.1 Origins 1.2 Current state 2 Concept 2.1 Goals 2.2 Activities 2.2.1 Coding 2.2.2 Testing 2.2.3 Listening 2.2.4 Designing 2.3 Values 2.3.1 Communication 2.3.2 Simplicity 2.3.3 Feedback 2.3.4 Courage 2.3.5 Respect 2.4 Rules 2.4.1 Rules of engagement 2.5 Principles 2.5.1 Feedback 2.5.2 Assuming simplicity 2.5.3 Embracing change 3 Practices 3.1 Fine scale feedback 3.2 Continuous process 3.3 Shared understanding 3.4 Programmer welfare 3.5 Coding 3.6 Testing 4 Controversial aspects 4.1 Scalability 4.2 Severability and responses 5 Criticism 6 See also 7 References 8 Further reading 9 External links

History

Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project.^[6] Beck became the C3 project leader in March 1996 and began to refine the development method used in the project and wrote a book on the method (in October 1999, Extreme Programming Explained was published).^[6] Chrysler cancelled the C3 project in February 2000, after the company was acquired by Daimler-Benz.^[7]
Although Extreme Programming itself is relatively new, many of its practices have been around for some time; the methodology, after all, takes "best practices" to extreme levels. For example, the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's Project Mercury, in the early 1960s (Larman 2003). Refactoring, modularity, bottom-up and incremental design were described by Leo Brodie in his book published in 1984^[8].

Origins

Most software development in the 1990s was shaped by two major influences: internally, object-oriented programming replaced procedural programming as the programming paradigm favored by some in the industry; externally, the rise of the Internet and the dot-com boom emphasized speed-to-market and company-growth as competitive business factors. Rapidly-changing requirements demanded shorter product life-cycles, and were often incompatible with traditional methods of software development.
The Chrysler Comprehensive Compensation System was started in order to determine the best way to use object technologies, using the payroll systems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the data access layer. They brought in Kent Beck,^[6] a prominent Smalltalk practitioner, to do performance tuning on the system, but his role expanded as he noted several issues they were having with their development process. He took this opportunity to propose and implement some changes in their practices based on his work with his frequent collaborator, Ward Cunningham. Beck describes the early conception of the methods:^[9]

The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.

Beck invited Ron Jeffries to the project to help develop and refine these methods. Jeffries thereafter acted as a coach to instill the practices as habits in the C3 team.
Information about the principles and practices behind XP was disseminated to the wider world through discussions on the original Wiki, Cunningham's WikiWikiWeb. Various contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted (see agile software development). Also, XP concepts have been explained, for several years, using a hyper-text system map on the XP website at "www.extremeprogramming.org" circa 1999 (website XPorg).
Beck edited a series of books on XP, beginning with his own "Extreme Programming Explained (1999, ISBN 0-201-61641-6)", spreading his ideas to a much larger, yet very receptive, audience. Authors in the series went through various aspects attending XP and its practices, even a book critical of the practices.

Current state

XP created quite a buzz in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins.
The high discipline required by the original practices often went by the wayside, causing some of these practices that were thought too rigid to be deprecated or left undone on individual sites. Agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field. In the second edition of Extreme Programming Explained, Beck added more values and practices and differentiated between primary and corollary practices.

Concept

Goals

Extreme Programming Explained describes Extreme Programming as a software development discipline that organizes people to produce higher quality software more productively.
In traditional system development methods (such as SSADM or the waterfall model) the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage (a common feature of software engineering projects) will be high. Like other agile software development methods, XP attempts to reduce the cost of change by having multiple short development cycles, rather than one long one. In this doctrine changes are a natural, inescapable and desirable aspect of software development projects, and should be planned for instead of attempting to define a stable set of requirements.
Extreme Programming also introduces a number of basic values, principles and practices on top of the agile programming framework.

Activities

XP describes four basic activities that are performed within the software development process.

Coding

The advocates of XP argue that the only truly important product of the system development process is code - software instructions a computer can interpret. Without code, there is no work product.
Coding can also be used to figure out the most suitable solution. For instance, XP would advocate that faced with several alternatives for a programming problem, one should simply code all solutions and determine with automated tests which solution is most suitable.^{[citation needed]} Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem and finding it hard to explain the solution to fellow programmers might code it and use the code to demonstrate what he or she means. Code, say the proponents of this position, is always clear and concise and cannot be interpreted in more than one way. Other programmers can give feedback on this code by also coding their thoughts.

Testing

One can not be certain that a function works unless one tests it. Bugs and design errors are pervasive problems in software development. Extreme Programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws.

• Unit tests determine whether a given feature works as intended. A programmer writes as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete. Every piece of code that is written is tested before moving on to the next feature.
• Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements. These occur in the exploration phase of release planning.

A "testathon" is an event when programmers meet to do collaborative test writing, a kind of brainstorming relative to software testing.

Listening

Programmers must listen to what the customers need the system to do, what "business logic" is needed. They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solved. Understanding of his or her problem. Communication between the customer and programmer is further addressed in The Planning Game.

Designing

From the point of view of simplicity, of course one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, this will not work. One can come a long way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear. One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system.^{[citation needed]}

Values

Extreme Programming initially recognized four values in 1999. A new value was added in the second edition of Extreme Programming Explained. The five values are:

Communication

Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.

Simplicity

Extreme Programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. This is sometimes summed up as the "you ain't gonna need it" (YAGNI) approach.^[5] Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the "communication" value, simplicity in design and coding should improve the quality of communication. A simple design with very simple code could be easily understood by most programmers in the team.

Feedback

Within Extreme Programming, feedback relates to different dimensions of the system development:

• Feedback from the system: by writing unit tests,^[6] or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes.
• Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
• Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.

Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements, known as user stories.^[6] To quote Kent Beck, "Optimism is an occupational hazard of programming, feedback is the treatment."^{[citation needed]}

Courage

Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary.^[6] This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only they are persistent.

Respect

The respect value manifests in several ways. In Extreme Programming, team members respect each other because programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through refactoring.
Adopting the four earlier values leads to respect gained from others in the team. Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team.

Rules

The first version of XP rules was proposed by Ken Hauer^[10] in XP/Agile Universe 2003. He felt XP was defined by its rules, not its practices (which are subject to more variation and ambiguity). He defined two categories: "Rules of Engagement" which dictate the environment in which software development can take place effectively, and "Rules of Play" which define the minute-by-minute activities and rules within the framework of the Rules of Engagement.
In the APSO workshop at ICSE 2008 Conference, Mehdi Mirakhorli proposed a new and more precise and comprehensive version of the Extreme Programming Rules, more independent of the practices, and intended to be more "agile".

Rules of engagement

According to Mehdi Mirakhorli, these are:^{[citation needed]}

• Business people and developers do joint work: Business people and developers must work together daily throughout the project.
• Our highest priority is customer satisfaction: The customer must set and continuously adjust the objectives and priorities based on estimates and other information provided by the developers or other members of the team. Objectives are defined in terms of what not how.
• Deliver working software frequently: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale (timeboxing).
• Working software: Working software is the primary measure of progress.
• Global awareness: At any point, any member of the team must be able to measure the team’s progress towards the customer’s objectives and the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
• The team must act as an effective social network, which means:
  • Honest communication leading to continuous learning and an emphasis on person-to-person interaction, rather than documentation.
  • Minimal degrees of separation from what is needed by the team to make progress and the people/resources that can meet those needs.
  • Alignment of authority and responsibility.

Principles

The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation.

Feedback

Extreme Programming sees feedback as most useful if it is done rapidly and expresses that the time between an action and its feedback is critical to learning and making changes. Unlike traditional system development methods, contact with the customer occurs in more frequent iterations. The customer has clear insight into the system that is being developed. He or she can give feedback and steer the development as needed.
Unit tests also contribute to the rapid feedback principle. When writing code, the unit test provides direct feedback as to how the system reacts to the changes one has made. If, for instance, the changes affect a part of the system that is not in the scope of the programmer who made them, that programmer will not notice the flaw. There is a large chance that this bug will appear when the system is in production.

Assuming simplicity

This is about treating every problem as if its solution were "extremely simple". Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas.
The advocates of Extreme Programming say that making big changes all at once does not work. Extreme Programming applies incremental changes: for example, a system might have small releases every three weeks. When many little steps are made, the customer has more control over the development process and the system that is being developed.

Embracing change

The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.

Practices

For more details on this topic, see Extreme Programming Practices.

Extreme Programming has been described as having 12 practices, grouped into four areas:

Fine scale feedback

• Pair programming^[6]
• Planning game
• Test-driven development
• Whole team

Continuous process

• Continuous integration
• Refactoring or design improvement^[6]
• Small releases

Shared understanding

• Coding standards
• Collective code ownership^[6]
• Simple design^[6]
• System metaphor

Programmer welfare

• Sustainable pace

Coding

• The customer is always available
• Code the Unit test first
• Only one pair integrates code at a time
• Leave Optimization till last
• No Overtime

Testing

• All code must have Unit tests
• All code must pass all Unit tests before it can be released.
• When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)
• Acceptance tests are run often and the results are published

Controversial aspects

The practices in XP have been heavily debated^[6] with strong opinions for or against using XP.
Proponents of Extreme Programming claim that by having the on-site customer^[6] request changes informally, the process becomes flexible, and saves the cost of formal overhead. Critics of XP claim this can lead to costly rework and project scope creep beyond what was previously agreed or funded.
Change control boards are a sign that there are potential conflicts in project objectives and constraints between multiple users. XP's expedited methodology is somewhat dependent on programmers being able to assume a unified client viewpoint so the programmer can concentrate on coding rather than documentation of compromise objectives and constraints. This also applies when multiple programming organizations are involved, particularly organizations which compete for shares of projects.^{[citation needed]}
Other potentially controversial aspects of Extreme Programming include:

• Requirements are expressed as automated acceptance tests rather than specification documents.
• Requirements are defined incrementally, rather than trying to get them all in advance.
• Software developers are usually required to work in pairs.
• There is no Big Design Up Front. Most of the design activity takes place on the fly and incrementally, starting with "the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. Critics compare this to "debugging a system into appearance" and fear this will result in more re-design effort than only re-designing when requirements change.
• A customer representative is attached to the project. This role can become a single-point-of-failure for the project, and some people have found it to be a source of stress. Also, there is the danger of micro-management by a non-technical representative trying to dictate the use of technical software features and architecture.
• Dependence upon all other aspects of XP: "XP is like a ring of poisonous snakes, daisy-chained together. All it takes is for one of them to wriggle loose, and you've got a very angry, poisonous snake heading your way." ^[11]

Scalability

Historically, XP only works on teams of twelve or fewer people. One way to circumvent this limitation is to break up the project into smaller pieces and the team into smaller groups. It has been claimed that XP has been used successfully on teams of over a hundred developers^{[citation needed]}. ThoughtWorks has claimed reasonable success on distributed XP projects with up to sixty people^{[citation needed]}.
In 2004 Industrial Extreme Programming (IXP) ^[12] was introduced as an evolution of XP. It is intended to bring the ability to work in large and distributed teams. It now has 23 practices and flexible values. As it is a new member of Agile family, there is not enough data to prove its usability, however it claims to be an answer to XP's imperfections.

Severability and responses

In 2003, Matt Stephens and Doug Rosenberg published Extreme Programming Refactored: The Case Against XP which questioned the value of the XP process and suggested ways in which it could be improved. This triggered a lengthy debate in articles, internet newsgroups, and web-site chat areas. The core argument of the book is that XP's practices are interdependent but that few practical organizations are willing/able to adopt all the practices; therefore the entire process fails. The book also makes other criticisms and it draws a likeness of XP's "collective ownership" model to socialism in a negative manner.
Certain aspects of XP have changed since the book Extreme Programming Refactored (2003) was published; in particular, XP now accommodates modifications to the practices as long as the required objectives are still met. XP also uses increasingly generic terms for processes. Some argue that these changes invalidate previous criticisms; others claim that this is simply watering the process down.
RDP Practice is a technique for tailoring Extreme Programming. This practice was initially proposed as a long research paper in a workshop organized by Philippe Kruchten and Steve Adolph( See APSO workshop at ICSE 2008) and yet it is the only proposed and applicable method for customizing XP. The valuable concepts behind RDP practice, in a short time provided the rationale for applicability of it in industries. RDP Practice tries to customize XP by relying on technique XP Rules.
Other authors have tried to reconcile XP with the older methods in order to form a unified methodology. Some of these XP sought to replace, such as the waterfall method; example: Project Lifecycles: Waterfall, Rapid Application Development, and All That. JPMorgan Chase & Co. tried combining XP with the computer programming methodologies of Capability Maturity Model Integration (CMMI), and Six Sigma. They found that the three systems reinforced each other well, leading to better development, and did not mutually contradict.^[13]

Criticism

Extreme Programming's initial buzz and controversial tenets, such as pair programming and continuous design, have attracted particular criticism, such as McBreen^[14] and Boehm and Turner.^[15] Many of the criticisms, however, are believed by Agile practitioners to be misunderstandings of agile development.^[16]
In particular, Extreme Programming is reviewed and critiqued by Matt Stephens's and Doug Rosenberg's Extreme Programming Refactored.^[17]
Criticisms include:

• A methodology is only as effective as the people involved, Agile does not solve this
• Often used as a means to bleed money from customers through lack of defining a deliverable
• Lack of structure and necessary documentation
• Only works with senior-level developers
• Incorporates insufficient software design
• Requires meetings at frequent intervals at enormous expense to customers
• Requires too much cultural change to adopt
• Can lead to more difficult contractual negotiations
• Can be very inefficient—if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once.
• Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements
• Can increase the risk of scope creep due to the lack of detailed requirements documentation
• Agile is feature driven; non-functional quality attributes are hard to be placed as user stories

Read More!