What is XP(Extreme Programming) in Agile methodologies?

Extreme Programming (also termed as XP) is an agile software development methodology. XP focuses on coding of software. XP has four core values and fourteen principles.
XP has these four core values:

  • Communication: The team should communicate on a regular basis, share information, discuss solutions, and so on. Teams that communicate very often are able to solve problems more efficiently. For instance, when an issue gets resolved in a cryptic fashion, send an email to the whole team. This ensures that the knowledge is shared with everyone and in your absence some other developer can solve a similar problem.
  • Simplicity: Keep things simple. From a process angle, technical angle, or from a documentation point of view. An over complicated process or technical architecture is only calling for problems.
  • Feedback: Regular feedback from the end user helps us to keep the project on track. So regular feedback should be enabled from the end user and testing team.
  • Courage: To bring change or to try something new needs courage. When you try to bring changes in an organization, you are faced with huge resistance. Especially when your company is following traditional methodologies, applying XP will always be resisted.

From the above four core values, 14 principles can be derived. The values give a broader level view while the 14 principles go deep into how to implement XP.

  • Rapid feedback: Developers should receive rapid feedback from the end user. This avoids confusion during the last minute of delivery. In the waterfall model, feedback is received very late. This is minimized in XP.
  • Keep it simple: Encourage simplicity in the project design and process. For instance, rather than using complex tools, simple handwritten flowcharts on a board can solve a problem.
  • Give incremental changes: Whenever you update patches and updates, release it in small pieces. If you are updating numerous patches in one go and if there is a defect, it will be difficult to track them.
  • Embrace change: Do not be rigid with the customer saying that we have already signed the requirement so we can not change the architecture. The customers or users are finally human beings so they can change as the project moves ahead….accept changes if they are logical.
  • Lightweight: Keep the documentation and process as simple as possible. Do not overdose the developer with unnecessary documentation. A developer’s main work is coding and ensuring that the code is defect free, so he should be concentrating on the code rather than the documentation.
  • Deliver quality: Any code you deliver should be defect free. Be committed to your work and deliver defect free code.
  • Start small and grow big: Many times the end customer wants to start with a big bang theory. He starts with a big team, wants all the functionalities at the first roll out, and so on. Start with a small team and the “must have” features to be delivered. As we add features and the workload increases, gradually increase your team strength.
  • Play to win: Take all steps needed to make a project success. Any type of deadline and commitment should be met with true spirit.
  • Encourage honest communication: Promote honest communication. If communication happens face to face, then there is less leakage of requirements. Encourage the end user to sit with developers and give feedback; this makes your project stronger.
  • Conduct testing honestly: Test plans should not be created for the sake of creation. Test plans should prove that you are on track record.
  • Adapt according to a situation: No two projects are the same, no two organizations are same, and different people behave differently. So it’s very essential that our approach also adapts according to situations.
  • Metric honesty: Do not gather metrics for the sake of gathering or showing off to external people how many metrics your project derives. Pick metrics which makes sense to your project and helps you measure your project health.
  • Accept responsibility: Do not impose or assign people on task which they do not like. Rather question the resource once which tasks he like and assign accordingly. This will increase productivity to a huge level and maintain your project enthusiasm high.
  • Work with people’s instincts: Normally in a project team there are highly motivated people, moderately motivated ones, and people with less motivation. So give power to your motivated team members and encourage them.
Tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.