Tuesday, January 25, 2011

Extreme Programming (XP) What's that !

XP, originally described by Kent Beck, has emerged as one of the most popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.

The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices:
  1. Planning Game
  2. Small Releases
  3. Customer Acceptance Tests
  4. Simple Design
  5. Pair Programming
  6. Test-Driven Development
  7. Refactoring
  8. Continuous Integration
  9. Collective Code Ownership
  10. Coding Standards
  11. Metaphor
  12. Sustainable Pace

In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as "User Stories". The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration by iteration basis.                                                                                                                           
In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.

The main aim of XP is to reduce the cost of change. In traditional system development methods 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 will be high. XP sets out to reduce the cost of change by introducing basic values, principles and practices. However, for applying XP, a system development project should be more flexible with respect to changes. Because of its nature as Experts suggests as maximum of 10 programmers can ideally work in an XP project this framework unlikely to work in slightly bigger projects. 

Guys: XP is one of those famous agile driven method which works those teams where the team is self organize. So use it or not is up to the team to decide but using it will definitely has all goods involve. 
Hope the Introduction helps you am open to your views so feel free to comment as much as you can!

Tuesday, January 18, 2011

Looking deeper on Manifesto of Agile Software Development

Common Problem in Agile World! The confusion over Agile Manifesto so though it would be good to write something for bigger audience and here you go I share my view and will  be waiting for your comments.

"We are uncovering better ways of developing software by doing it and helping others do it."

Through this work we have come to value:
» Individuals and interactions over processes and tools
» Working software over comprehensive documentation
» Customer collaboration over contract negotiation
» Responding to change over following a plan

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

» Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
» Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.
» Business people and developers must work together daily throughout the project.

"Build projects around motivated individuals."

» Give them the environment and support they need, and trust them to get the job done.
» The most efficient and effective method of conveying information to and within a development team is faceto- face conversation.
» Working software is the primary measure of progress.
» Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
» Continuous attention to technical excellence and good design enhances agility.
» Simplicity--the art of maximizing the amount of work not done--is essential.
» The best architectures, requirements, and designs emerge from self-organizing teams.
» At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Let me know guys what you think! Love to hear from you... about your opinions on the same.

Saturday, January 1, 2011

ScrumMaster Who: Answer is The Leader

I thought New Year is a good time to Wish you very best to figure out the best way to look for potential ScrumMaster. Whether the selection is being made by the team itself or by someone outside the team. 
I present six attributes that your potential ScrumMaster should demonstrate.
In most organizations, when someone is given responsibility they are concurrently given the authority necessary for success. ScrumMasters are in a different situation. While a ScrumMaster does not assume responsibility for the success of the project—that remains with the team—a ScrumMaster does assume responsibility for the team’s adoption of Scrum and practice of it. A ScrumMaster takes on this responsibility without assuming any of the power that might be useful in achieving in it.
A ScrumMaster’s role is similar to that of an orchestra conductor. Both must provide real-time guidance and leadership to a talented collection of individuals who come together to create something that no one of them could create alone. Glasgow City Bus conductor Dave has said of his role, “People assume that when you become a conductor you’re into some sort of a Napoleonic thing—that you want to stand on that big box and wield your power. I’m not a power junkie, I’m a responsibility junkie.” In an identical manner, a good ScrumMaster thrives on responsibility—that special type of responsibility that comes without power.
A good ScrumMaster is not in it for ego. A good ScrumMaster will take pride (often immense pride) in her achievements but the feeling will be “Look what I helped accomplish” rather than the more self-centered “Look what I accomplished.” A humble ScrumMaster is one who realizes the job does not come with a company car or parking spot near the building entrance. Rather than putting his own needs first, a humble ScrumMaster is willing to do whatever is necessary to help the team achieve its goal. Humble ScrumMasters recognize the value in all team members and by example lead others to the same opinion.
A good ScrumMaster will work to ensure a collaborative culture exists within the team. The ScrumMaster needs to make sure team members feel able to raise issues for open discussion and that they feel supported in doing so. The ScrumMaster should help create a collaborative atmosphere for the team through his words and actions. However, beyond modeling a collaborative attitude, a good ScrumMaster will establish collaboration as the team norm and will call out inappropriate behavior (if not already done by other team members).
While the ScrumMaster role does not always require a full-time, eight-hour-a-day commitment, it does require someone in the role who is fully committed to it. The ScrumMaster must feel the same high level of commitment to the project and the goals of the current sprint as do team members.
A ScrumMaster should not end very many days with impediments raised by the team that are left unaddressed. A team’s impediment list cannot be swept clean by the end of every day because some impediments take time to remove. For example, convincing a manager to dedicate a full-time resource to the team may take a series of discussions with some time between them.
While the ScrumMaster may not be a full-time job, the ScrumMaster should plan on being the ScrumMaster for the full duration of the project. It is very disruptive for a team to change ScrumMasters in midstream.
To be successful a ScrumMaster will need to influence others both on the team and outside it. Initially, team members may need to be influenced to give Scrum a fair trial or to behave more collaboratively; later a ScrumMaster may influence a team to try new technical practices such as Test-Driven Development or pair programming. A ScrumMaster should know how to exert influence without resorting to a command-and-control “because I say so” style.
Most ScrumMasters will also be called upon to influence those outside the team. A traditional team may need to be convinced to provide a partial implementation to the Scrum team, a QA director may need to be influenced to dedicate full-time testers to the project, or a vice president may need to be convinced to try Scrum at all.
While all ScrumMasters should know how to use their personal influence, the ideal ScrumMaster will come with a degree of corporate political skill. Corporate politics is often used pejoratively; however, a ScrumMaster who knows how decisions are made in the organization, who makes them, which coalitions exist, and so on can be an asset to a team
The best ScrumMasters have the technical, market, or specific knowledge to help the team in pursuit of its goal.
 So Wish you all the best for the search of next Scrum Master!