How is Agile Unified Process (AUP) different from Rational Unified Process (RUP) ?

Agile Unified Process uses Agile Modelling, which is used for describing the modelling and documentation process based on agile disciplines. The Rational Unified Process (RUP) is also an agile methodology. Here we highlight the differences between the two. Both of these processes are divided into disciplines or workflows, which are carried out in iterations. Agile Unified Process (AUP) is derived from RUP, and we can say it is a simpler version of it. There are 3 disciplines followed by RUP i.e., Modelling, Requirements and Analysis and Design. The AUP being the simple version combines all of them into one discipline. It is because of this that it is easy for the RUP teams to migrate to AUP if they want to. Thus RUP is very flexible and can be merged with agile modeling practices.

> Active stakeholder participation: In RUP projects, stakeholders including customers, users, managers and operators, are often involved as a part of the project disciplines. It is necessary for the team to assign modelling roles like requirements specifier, business process designer etc., to the participating stakeholders. The activeness of the stakeholders is related to less requirement of feedback in the Agile Unified Process.

> Agile Modelling Standards: A significant part in AUP is played by the UML (Unified Modelling Language) diagrams. For maintaining its agility, the agile teams often blend the standards and the guidelines together. On the other side, in an RUP project, the guidelines to be adopted by the teams for creating modelling artifacts are included.

> Gentle application of the patterns: The AUP teams get the full freedom for choosing which modelling patterns to use. However, in RUP, these patterns are defined by the product depending on the modelling disciplines being followed. This practice has led to an enhancement in the performance of Agile Unified Process by easing the way to apply patterns. But, this concept is not as explicit as it should be.

> Application of the right artifacts: The advice for creation of various types of models is provided by the AUP and it is one of its strengths. The recent version of the RUP also provides plenty of advice on creating non – UML artifacts (UI flow diagrams, data models etc.).

> Collective ownership: This concept of Agile Modelling is used for making enhancements in the projects developed using AUP. But, it has to be assumed that the open communication is supported by the team culture. Along with supporting this concept, AUP lays strong stress on issues concerning configuration management. Therefore, the change management processes sometimes can be a hurdle in path of development.

> Parallel creation of several models: This is an important concept of UP. The team is required to check the activitiy diagrams corresponding to each discipline and see if they are being worked up on in parallel. But there is an issue with UP which is that the flow diagrams do not explain this well.

> Creation of the simple content: The simplicity is assumed by the developers. The team needs to adopt the guidelines stating the use of simple models and also the customers must be happy with this. However, many organizations often find it difficult to adopt this culture.

> Temporary models should be discarded: The AUP team is free to decide which models to discard and which models to keep. Travelling light also helps in maintaining simplicity.

> Public display of models: Models should be displayed publicly for facilitating open communication. This way all the artifacts will be available to all the stakeholders

How is Adaptive Software Development (ASD) different from Scrum? Part 2

Read the First Part (Adaptive Software Development being different from Scrum - Part 1)

For understanding the further differences between the two, it is important that we know what Agile Development is. The Agile manifest defines the agile methodology. There are 7 agile methodologies; namely XP, Crystal orange, Scrum, Adaptive Software Development, DSDM, Pragmatic programming and Feature – driven development. All these methods differ in their mechanisms and the parameters they take. All these methods have a different agile life cycle. For ASD, it depends on what techniques we are going to use. Generally speaking it doesn’t have a life cycle of its own. In contrast to this, scrum has an abstract lifecycle which packs certain activities in to its schedule.

However here we discuss differences based up on a lifecycle having some general phases.
- Project initiation: This step includes justification of the project and determining the requirements.
- Planning: Laying out an elaborate plan for development and leaving some gap for contingency actions. Scrum doesn’t have choice for including optional phases. It must work within predefined options, whereas the adaptive software development can have many options because it does not limits itself to few techniques.
- Elaboration of requirements: This stage is optional. The requirements are explained in great detail. Scrum does not implement this stage separately, but, it may be done in Adaptive Software development. Since the requirements are still in high level, they need to be broken down in to simpler specifications. The requirements are collated in to requirements document after classification. This document also contains use cases apart from the requirements.
- Architecture: Both scrum and ASD are based on agile principle of, design today and refactor tomorrow. Software developed using ASD can be modified to suit the changing environment just by adjusting their software capabilities and leaving the hardware unchanged. Software developed through scrum has to be modified through manual intervention and may even require to change hardware. A system architecture document is prepared in this phase.
- Release: The software is released to the customer. It has one timebox at least. Scrum can have many releases depending upon the development span of the project. Adaptive software usually delivers product in one go.

One of the important questions to be asked during project initiation phase is that whether to invest more or not? Not all methods answer this question. However addressing this question is an important part of the adaptive software development. Scrum doesn’t address this question explicitly. Next step is choosing the appropriate method. Scrum claims that it can be used for any project. Adaptive software development creates a list of all alternatives that can be used and chooses the best one.
The level of formality to be maintained in scrum is given by documents such as running code and backlog. In adaptive software development there are many too many choices to choose from. It makes use of vision statements for clearing out the confusion. Scrum defines a sprint goal which is a kind of timebox vision i.e., it follows one choice for some time and then can change if required.
Scrum avoids elaboration phase for speeding up the delivery. It uses product backlog maintained by the product owner.
Since adaptive software development may have an elaboration phase, it may also have a draft plan initially which may turn into a complete plan after determination of requirements. Scrum plans based on timeboxes.
Both methodologies help you work faster creating products with better quality. The agile customer too is an important role in the agile process. The customers are responsible for providing input during prototyping sessions. The organizing and controlling of user testing is the responsibility of the user. 

How is Adaptive Software Development (ASD) different from Scrum? Part 1

Adaptive software development and scrum both come under the overall heading of agile software development, but are two different beasts with differences between them. These are two different approaches with the same aim i.e., agile development. Below, we will write more on what differentiates the two.
It is necessary to know the differences between these two approaches since Scrum, as a part of agile software development is already a very famous methodology, whereas the adaptive software development is relatively new, but also a strong upcoming methodology ready to take the software development market by storm. Agile methods are always preferred over traditional development approaches to incorporate major factors such as increased levels of customer participation and satisfaction, project delivery flexibility, and acceptance of ongoing requirements or design changes at any level in the development process. This is the usual development scenario and that is why agile development methods are used mostly.  Most commonly used agile methods include:
-  Adaptive software development
- Scrum
- Feature driven development
- Extreme programming

Even though all these strategies aim at the same set of objectives (well almost), they do take somewhat different paths (having some items common, and yet others are different). It is important to know the differences between them. Otherwise how you are going to maintain agility in your development structure? Comparison between different agile methodologies, their common points and differences lets the managers choose the most appropriate agile method for their software characteristics.
There are many traditional techniques for drawing comparisons between 2 software development techniques. In this post, Scrum and ADS have been compared on basis of 2 areas, namely software construction and software requirements.
First difference between adaptive software development and the scrum approach is that in the former, there is no predefined technique to be followed. In scrum there are certain predefined techniques to be followed. On the other hand the focus of adaptive software development is on the end result rather on the steps. Adaptive software development methodology implements a particular technique only if it is required.
Since the last two years agile principles have encompassed methods such as extreme programming, feature driven development, adaptive software development and so on.  So far companies using scrum or adaptive software development have been able to deliver successful products. Scrum is described as a process for management and control used for cutting down the complexity. This is used by the organizations who want to deliver products faster. This approach to software development has been used on advanced development methods including software; it usually works well in the object – oriented development environment.
On the other hand adaptive software development is described as methodology for developing reliable and re – adaptive software. It is used by the organizations who want their products to function in a wide range of changing conditions. Software built with this approach are capable of reconfiguring themselves to better suit to the environment. It can be used under any kind of environment. Any technique can be applied here to make software as much flexible as possible. The owners are responsible for estimating backlog items in scrum. In adaptive software development it is mainly the task of the developers.
Scrum follows time-boxing method for speedy delivery. At the start of each timebox, a sprint planning meeting is held. A backlog that can be achieved is picked up by the team members and they decide how it can be achieved.
Scrum may have 1 to 4 teams with 5 – 9 members and adaptive software development may have even more number of teams dedicated to each phase of development process. Agile developers play a number of roles – analysing, estimating, designing, coding and testing. Even though the typing burden is less, there is a lot of stress because of the short frames. But you get to see your progress through user reviews and daily meetings.

Read next part  (Adaptive Software Development being different from Scrum - Part 2)

What are benefits of agile process improvement?

Agile methodologies that we have today are a resultant of the experiences gained from the real life projects that were undertaken by the leading software professionals. These professionals were thorough with the challenges and limitations imposed by the traditional development methodologies on various projects. 

- The agile process improvement directly addresses the issues of the traditional development methods both in terms of processes and philosophy behind it. 

- Agile process improvement provides a simple framework to the development teams suiting varying scenarios while focusing up on the fast delivery of the business values. 

- With all these benefits of the agile process improvements, the organizations have been able to reduce the associated overall risk with the development of the project. 

- The delivery of the initial business values is accelerated well by the agile process improvement. 

- This is achieved through a process of constant planning and feedback. 

- Agile process improvement ensures that the business values are maximized throughout the development process. 

- With the API’s iterative planning plus feedback loop, it becomes possible for teams to align the software process with the business needs as required. 

- Another major benefit of the agile process is that the software development process can adapt to the ever–changing requirements of the process and business. 

- By taking a measure and evaluation of the status based up on the amount of work and testing done, visibility can be obtained to a more accurate value. 

- The final result of the agile process improvement is a software system that is capable of addressing the customer requirements and the business in a much better way. 

- By following an agile process improvement program, not only just deployable, tested and working software can be delivered on an incremental basis but also increased visibility, adaptability and values are delivered earlier in the software development life cycle. 

- This proves to be a great thing in reducing the risk associated with the project. 

- There are a number of problems with the traditional development methods. 

- In a research it was found that the waterfall style development methodology was the major factor in the contribution of failure of the software. 

- Some other software could not meet the real needs. 

- They had the inability in dealing with the changing requirements and late integration. 

- All this has proven that the traditional development methods prove to be risky as well as a costly way for building software. 

- Thus the majority of the industry has turned towards agile development.

- There is a continuous feedback input from the customers and a face to face communication among all the stake holders. 

- The business needs associated with the agile process improvement are ever changing. 

- Organizations want quick results from what they invest. 

- They want their improvement programs to keep pace with these changing business needs. 

- The agile process improvement is composed of several mechanisms using which all this can be achieved. 

- Working iteratively lets you deliver the product before the deadline to the customer. 

- It lets you deliver only the things are actually required i.e., it does not let you waste your time on the un-required things. 

- Also, early and regular feedback from the customer lets you deliver the product with quality as desired by the customer.

- Agile projects are distributive in nature i.e., the work is divided among people. 

- Agile software development is still an immature process and there is a need for improving it for the betterment of the software industry. 

- Agile process improvement is one way to do this.

What is the need of Agile Process Improvement?

It is commonly seen that a number of change projects are designed and published but none of actually goes into implementation. Most of the time is wasted in writing and publishing them. This approach usually fails. We should stop working with this methodology and develop a new one. Below mentioned are some common scenarios in the modern business:

1. Developing a stronger project
2. Changing the people working on it.
3. Threatening that project with termination
4. Appointment of a committee that would analyze the project
5. Taking examples from other organizations to see how they manage to do it.
6. Getting down to a dead project
7. Tagging a dead project as still worth of achieving something.
8. Putting many different projects together so as increase the benefit.
9. Additional training

-Drops in the delivery of the normal work always follow a change. 

-Big change projects are either dropped or rejected.

-It all happens because the changes introduced by such projects are mandatory to be followed.

-This threatens the normal functioning of the organization. 

-So, the organization is eventually compelled to kill the whole process and start with the old way of work again. 

-Instead of following this approach, a step by step process improvement can be followed that is nothing but the agile process improvement. 

Now you must be convinced why agile process improvement is actually needed. 

- The changes needs to be adaptive then only the process will be balanced. 

- An example is the CMMI maturity level. It takes 2 years approx. for completion and brings in the following:

1. Restructuring
2. New competitors
3. New products

-Only agile methods make these changes adaptive in nature.

-The change cycles when followed systematically produce results in every 2 – 6 weeks.

-Thus, your organization’s workload and improvement stay perfectly balanced. -The early identification of the issues becomes possible for the organizations thus giving you it a chance to be resolved early. 

-By and by the organization learns to tackle the problems and how to improve work.

-At the end it is able to adapt to the every changing needs of the business.

-The responsibility of the deployment and evaluation of the improvement is taken by the PPQA. 

-Whole process is implemented in 4 sprints:

1. Prototyping
2. Piloting
3. Deploying
4. Evaluating

-A large participation and leadership is required for these changes to take place.

-Some other agile techniques along with scrum can also be used in SPI.

-We can have the improvements continuously integrated in to the way the organization works. 

-The way of working can also be re-factored including assets and definitions by having an step by step integration of the improvements.

-Pair work can be carried out on improvements. 

-A collective ownership can be created for the organization. 

-Evaluations and pilots can be used for testing purpose. 

-In order to succeed with the sprints is important that only simple solutions should be developed. 

-An organization can write the coaching material with the help of the work description standards.

-This sprint technique helps the organization to strike a balance between the improvement and the normal workload. 

-In agile process improvement simple solutions are preferred over the complex ones.

-Here, the status quo and the vision are developed using the CMMI and SCAMPI. 

-Status quo and vision are necessary for the beginning of the software process improvement.

-SPI when conducted properly produces useful work otherwise unnecessary documentation has to be produced.

-An improvement in the process is an improvement in the work. 

-Improving work is what that is preferred by people. 

Explain Telerik TeamPulse?

About Telerik TeamPulse

- Telerik TeamPulse has been developed by Telerik as an agile project management tool in the year of 2010. 

- One of the characteristic features of the TeamPulse is that it can be integrated as well as hosted as local Microsoft team foundation server 2008, 10 and 12 services. 

- However, it cannot be integrated with the Microsoft visual studio.

- This Telerik product is available under commercial license. 

- The features of TeamPulse have been mentioned below:

1. Bug tracking
2. Integration with the telerik’s web UI test studio
3. Time tracking
4. Backlog management
5. E – mail notifications
6. Cross – project dashboard known as xView and developed with html5.
7. Task board
8. Storyboard with WP limits
9. TeamPulse can be integrated with Microsoft TFS (team foundation server) 2008, 2010 and 2012.
10. Requirements manager
11. Best practices analyzer

- The extension provided with the Telerik TeamPulse is the TeamPulse ideas and feedback portal which is based on html and is compatible with html5.

- Since TeamPulse is commercial software, it is not available for a hosted solution but it is to be used only on premise. 

- When you add TeamPulse to TFS the planning, tracking and collaboration improves automatically.

- With the real time project intelligence of Telerik TeamPulse you can improve decision making power. 

- It provides you with up-to-date views of the status of the project. 

- By using TeamPulse, you bridge the boundaries between the team members and their geographical location i.e., the communication is improved. 

- This tool has been exclusively designed for scrum and kanban teams i.e., any of these either kanban or scrum or scrumban can be used.

- It has been designed to reduce the delivery time, eliminate the waste and improve the work flow. 

- It also provides you a convenient way for collecting and managing the customer feedback. 

- It lets you create products that your customer actually needs. 

- TeamPulse lets you manage project well with the following:

1. Work burn down
2. Velocity
3. Cycle time
4. Iteration delta
5. Agile best practices and a number of other reports. 

- Telerik TeamPulse favors most of the agile projects.

- It lets one plan, manage and monitor the results thus improving the overall process. 

- TeamPulse has got a rich interface with in–context guidance making the integration with TFS faster. 

- Its other features include:

1. Automatic notifications
2. Bug tracking
3. Gantt charts
4. Interactive gantt charts
5. Privacy settings
6. Project templates
7. Reporting
8. Scheduling
9. Task feedback
10. Workload
11. Dashboard
12. Email integration
13. Issue tracking
14. Messaging or IM
15. RSS feed
16. Collaborative
17. Issue tracking system
18. Risk management capabilities
19. Web application

- The tool has not got any remote capability features. It comes with the following resource management features:

1. Time sheets
2. Compare project
3. Management software

- Teampulse has been developed with the view that all the clients, scenario and environment differ from each other.

- Large enterprises require a tool that is capable of scaling their workload. 

- Teampulse fits every scenario even though if you require some time to master it. 

- Firstly, you need to set up the project info, template, iterations. 

- Then you need to create your team and lastly take a view of the summary of your project. - It is recommended by the system to start with the stories.

- Being an enterprise tool, it has got many features which might make you feel like it might be quite complex to use. 

- But it is quite user friendly. 

What is meant by Behavior Driven Development (BDD)?

BDD or Behavior Driven Development is one of the most important development approaches in the field of software engineering and is just a modified implementation of the TDD or test driven development. It actually combines the guiding principles and general techniques of the test driven development with the combined ideas from two sources namely:

1. Domain – driven design
2. Object – oriented analysis and design

- The behavior driven development thus provides a shared process and tools to business analysts and software developers for their collaboration on the software development process.

- Ideally, behavior driven development represents an idea regarding the management of the software development process by both technical sight and business interests.

- It is assumed in this approach that the specialized software tools are being used to provide support to the development process. 

- The specialized tools thus involved have been developed especially to be used in projects following the BDD approach. 

- They can be considered as special tools that supports test driven development. 

- The primary purpose of these tools is to automate the ubiquitous language statements around which the BDD process is centralized. 

- Agile software development gets successful only when it is considered from the beginning. 

- On the contrast, in some projects this is the last thing to be considered which means that there is no sustainable operation in the websites that serve purposes other than blogging.

-  A blogging web site is just a software that is just modified by the users as it is ready for use. 

- However, BDD and TDD provides the only ways for achieving this goal. 

- The word ‘driven’ in TDD signifies that the test cases are written first and then the code for passing the test. 

- TDD is actually a low level methodology of accomplishing tasks and is sort of developer oriented. 

- On the other hand in BDD, the description of the tests is written in a natural language, thus making the tests more accessible to people outside the development team. 

- Such descriptions can describe the functionality in the same way as done by the specifications. 

Dan North was the person who actually brought the concept of behavior driven development in response to the issues experienced in implementing the test driven development such as:

1. From where to start testing?
2. What is to be tested?
3. How much should be tested in one turn?
4. How the reason for the failure of the test is to be understood?

- At the heart of the behavior driven development approach lies the approach to acceptance testing and unit testing which were again identified by North. 

- He emphasized that the acceptance tests should be written using the user story frame work. 

- Thus starting from the scratch, the development of the BDD approach continued over a couple of years and finally we have it as a communication and collaboration framework. 

- It has been designed especially for the QA people and business participants involved in a project.

- The agile specifications, BDD and testing eXchange meet highlighted the following characteristics of BDD:

1. Second generation methodology
2. Outside – in approach
3. Pull based
4. Multiple stake holder support
5. Multiple scale generation
6. High automation process
7. Agile methodology

- Further, it was said that it involves a cycle of interactions with outputs that are well defined and results in delivery of working software that makes sense. - First, BDD frame work that came in to existence was Jbehave which was followed by Rbehave–a story level BDD ruby frame work.

- All these frameworks were later replaced by cucumber testing tool. It was developed by Aslak Hellesoy. 

What are different techniques for estimating used by agile teams?

Expending more time and effort to arrive at an estimate does not necessarily increase the accuracy of the estimate. The amount of effort put into an estimate should be determined by the purpose of that estimate. Although it is well known that the best estimates are given by those who will do the work, on an agile team we do not know in advance who will do the work. Therefore, estimating should be a collaborative activity for the team.

Concepts on Estimating

- Agile teams acknowledge that we cannot eliminate uncertainty from estimates, but they embrace the idea that small efforts are rewarded with big gains.
- Agile teams can produce more reliable plans because they frequently deliver small increments of fully working, tested, integrated code.
- Agile teams do not rely on single expert to estimate. Estimates are best derived collectively by the team.
- Estimates should be on a predefined scale.
- Features that will be worked on in the near future and that need fairly reliable estimates should be made small enough that they can be estimated on a non-linear scale from 1 to 10 such as 1,2,3,5, and 8 or 1,2,4, and 8.
- Larger features that will most likely not be implemented in the next few iterations can be left larger and estimated in units such as 13,20,40, and 100.
- Some teams choose to include 0 in their estimation scales.

Four common techniques for estimating are:

1. Expert Opinion
- In this approach, an expert is asked how long something will take or how big it will be.
- The expert relies on his/her intuition or gut feel and provides an estimate.
- This approach is less useful on agile projects as compared to traditional projects.
- In an agile project, estimations are made on user stories or other user-valued functionality. It requires lot of skills by more than one person which makes it difficult to find suitable experts.
- Benefit of expert opinion is that it does not take very long.

2. Analogy
- In this approach, the estimator compares the story being estimated with one or more other stories.
- If story is twice the size, it is given estimate twice as large.
- You do not compare all stories against a single baseline, instead, each story is estimated against an assortment of those that have already been estimated.

3. Dis aggregation
- It refers to breaking a story or feature into smaller, easier to estimate pieces.
- Be careful not to go very far with this approach.

4. A fun and effective way of combining these is planning poker.
- In planning poker, each estimator is given a deck of cards with a valid estimate shown on each card.
- A feature is discussed, and each estimator selects the card that represents his or her estimate.
- All cards are shown at the same time.
- The estimates are discussed and the process repeated until agreement on the estimate is agreed.

How does agile teams estimate the size of the project?

Agile teams separate estimates of size from estimates of duration. There are two measures of size:
1. Story points
2. Ideal time

Estimating Size with Story Points

- Story points are a relative measure of the size of a user story.
- A point value is assigned to each item when we estimate story points.
- Relative values are more important than raw values.
- A user story estimated as ten story points is twice as big, complex, or risky as a story estimated as five story points.
- A ten-point story is similarly half as big, complex or risky as a twenty-point story.
- The most important thing that matters are the relative values assigned to different stories.
- Velocity is a measure of a team's rate of progress per iteration.

- At the end of each iteration, a team can look at the stories they have completed and calculate their velocity by summing the story point estimates for each completed story.

- Story points are purely an estimate of the size of the work to be performed.
- The duration of a project is not estimated as much as it is derived by taking the total number of story points and dividing it by the velocity of the team.

There are two approaches to start with:
1. First Approach: Select a story that you think is one of the smallest story and say that story is estimated at one story point.
2. Second Approach: Select a story that seems somewhat medium and give it a number somewhere in the middle of the range you expect to use.

Estimating Size in Ideal Time

Ideal time and elapsed time are different. The reason for the difference, of course, is all the interruptions that may occur during any project.
- The amount of time a user story will take to develop can be more easily estimated in ideal days than in elapsed days.
- Estimating in elapsed days require us to consider all the interruptions that might occur while working on the story.
- If we instead estimate in ideal days, we consider only the amount of time the story will take.
- In this way, ideal days are an estimate of size, although less strictly so than story points.
- When estimating in ideal days, it is best to associate a single estimate with each user story.
- Rather than estimating that a user story will take 4 programmer days, 2 tester days, and 3 product owner days, it is better to sum those and say the story as a whole will take nine ideal days.

How does agile teams work?

Agile teams work together as a team but include roles filled by specific individuals.
- First is the product owner, who is responsible for the product vision and for prioritizing features the team will work on.
- Next is the customer, who is the person paying for the project or purchasing the software once it is available.
- Users, developers, and managers are other roles on an agile project.

How does agile team work?

- Agile teams work in short, time-boxed iterations that deliver a working product by the end of each iteration.
- The features developed in these iterations are selected based on the priority to the business.
- This ensures that the most important features are developed first.
- User stories are a common way for agile teams to express user needs.
- Agile teams understand that a plan can rapidly become out of date. Because of this, they adapt their plans as appropriate.

What kind of planning are used for agile teams?

Agile teams use three levels of planning:
- Release planning : The release plan looks ahead for the duration of the release - typically, three to six months.
- Iteration planning : The iteration plan looks ahead only the duration of one iteration - typically, two to four weeks.
- Daily planning : A daily plan is the result of team member commitments made to each other in a daily stand-up meeting.

During release planning, the whole team identifies a way of meeting the conditions of satisfaction for the release, which includes scope, schedule, and resources. To achieve this, the product owner may need to relax one or more of her conditions of satisfaction.
A similar process occurs during iteration planning, when the conditions of satisfaction are the new features that will be implemented and the high level test cases that demonstrate the features were implemented correctly.

What are different characteristics of agile planning?

Two critical areas in software engineering are:
1. Estimating
2. Planning.
They are difficult and error-prone. These activities cannot be avoided.

The purpose of planning is to find an optimal answer to the overall product development question of what to build. The answer incorporates features, resources and schedule. It is supported by a planning process that reduces risk, uncertainty, supports reliable decision making, establishes trust and conveys information.

Planning is an ongoing iterative approach. It is an effort to find an optimal solution to the overall product development question of "what should we build?"

A good planning process supports:
1. Reducing Risk
2. Reducing Uncertainty
3. Supporting better decision making
4. Establishing trust
5. Conveying Information

A good plan is one that is sufficiently reliable that it can be used as the basis for making decisions about the product and project.

What is Agile Planning?

- It is more focused on planning than the creation of plan.
- It encourages change, results in plans that are easily changed.
- It shifts the focus from plan to planning.
- It balances the effort and investment in planning with the knowledge that we will revise the plan throughout the project.
- As the user needs are discovered, our plans are affected and hence changes become necessary.
- Plan are needed that are easily changed. Therefore, planning becomes more important that the plan.
- Changing plan does not mean a change in date.
- Plan can be changed without changing the date by:
            1. dropping a feature.
            2. reducing scope of feature.
            3. adding more people in the project.
- Agile planning is spread more or less evenly across the duration of a project.

What is an Agile Process?

Agile process is a process that is taking up the field of software engineering for the good. In this article the topic of the agile process has been taken up in depth. 

Agile processes or agile software development processes constitute a group of processes that are based up on the principles of the agile values and principles and follow up the idea of the iterative and incremental development for developing the software products. 

Here the solutions to the software problems are meant to be evolved via the collaboration between the development teams having characteristics like:

     1. Self organization and

     2. Cross functioning

The agile process are known world wide for the promotion of the following features:

     1. Adaptive planning

     2. Evolutionary development

     3. A time boxed iterative approach

     4. Flexible and rapid response to the change in requirements.

     

What is an Agile Process?

- Agile processes can be thought of as a conceptual frame work promoting the above mentioned aspects plus the foreseen interactions that take place throughout the development cycle. 

- The term “agile processes” came in to existence by the virtue of the agile manifesto in the year of 2001. 

- The concept of the agile processes is not so new to the software industry. 

- The incremental software development aspect of the agile development can be dated back to the year of 1957.  

- The category of the light weight software development methodologies houses all the agile software development methodologies. 

- The agile processes were first mentioned in the “manifesto for agile software development”. 

Principles that govern Agile Process

There are 12 principles that govern the agile processes as mentioned below:

1. Rapid delivery of the software that is useful to the customer.

2. To accept the changes in the requirements in all the phases of the development process.

3. Frequent delivery of the working software.

4. A principal measure of the progress is the working software.

5. The development takes place at a constant pace known as the sustainable development.

6. Daily co- operation takes place between the developers and the clients.

7. Face to face conversation is maintained.

8. The project is centered around the motivated individuals who are trust worthy.

9. Regular attention is paid to the design and the technical excellence.

10. Simplicity is maintained.

11. Self organizing teams.

12. Ability to adapt to the changing circumstances.

Till date so many agile software development methods have come up and they are known to promote the following elements:

1. Team work

2. Collaboration

3. Process adaptability

- These elements are promoted all along the development process and throughout the development cycle of the software project.

- The main methodology of the agile processes is that the problem is broken down in to small increments or iterations and is developed according to the short term planning rather than using the long term planning. 

- These iterations are nothing but kind of short frame works having duration of development ranging from one to four weeks. 

Activities in Agile Process

Full agile software development iteration includes the following activities:

1. Planning

2. Requirements analysis

3. Design

4. Coding

5. Unit testing and

6. Acceptance testing

More about Agile Process

- The agile processes are known for their typical strategy that works on minimizing the risk to a great extent. 

- The documentation is produced by the stake holder as and when required.

- The goal here is develop a release that is available as a sample but not for market release. 

- A market release is facilitated by multiple iterations.

- The work burden is divided by the individual team members among themselves. 

- For the agile development the team needs to be in the same region and size of the team is typically small at the most ten members. 

When should Extreme Programming be used?

Extreme programming or XP as it is commonly called as has been known to be a very effective and reliable agile software development methodology having its foundation laid up on the principles of agile development. 

The first ever project that made use of extreme programming was done in the year of 1996 in the month of March. The project was quite successful and since then many companies of different sizes began using the extreme programming software development methodology for developing their software products all over the world. 

The extreme programming works out successfully every time since it stresses the satisfaction of the customers. The extreme programming does not makes promises that it will deliver the software with all the possible ways you expect it rather it delivers the software product with all the features that you require the most. 

The developers are empowered in a way to confidently respond to the ever changing needs of the customers in whichever stage of the development cycle required. 

How Extreme Programming improves the quality of software?

5 ways have been defined in which the extreme programming helps in improving the quality of the software and its productivity:

1.     Communication

2.     Simplicity

3.     Feedback

4.     Courage and

5.     Respect

When the Extreme Programming should be used?

- A software development process does not suit for all the types of the software projects.

- Extreme programming must be employed for the complex projects which require a clean and simple design void of any bombastic jargon. 

- The simple rules of the extreme programming make it easy to be implemented in most of the software projects.

- Extreme programming elements individually do not make any sense but do make sense when put together. 

- These elements and rule may seem to be very awkward at first but they are based up on sound principles and are guided by sound rules. 

- The extreme programming makes the whole development process very collaborative and works well with the projects in which the active participation of the customer is required. 

- In extreme programming once the product team work is achieved, its rules can be modified to fit the requirements of the company. 

- The activities which show less productivity are trimmed to reduce the budget of the development process. 

- The need for extreme programming grew out of the demands for short productive cycles which could satisfy the rapidly changing requirements of the industry. 

- The extreme programming has always attracted controversy whenever an environment different from its original one has been used. 

- The extreme programming demands for high discipline and hence some of the practices involved in the extreme programming are thought to be very rigid to be reduced or left unfinished. 

- But the extreme programming works according to a very relaxed schedule which can be designed by the developers. 

- This prevents frustration and creation of stubs to pass the end of day testing. 

- Thought the schedule is very lenient, a periodic integration is always required. 

- It is needed to detect the work being done in non compatible efforts before too much of the efforts are wasted in the wrong directions.

However, apart from all these positive there are a few negative aspects of the extreme programming which should always be kept in mind before you implement it for the development of your software project. 

- It lacks structure and documentation and requires senior level developers. 

- It calls for frequent meetings with a great exposure to the customers. 

- You can even land in much difficult contractual negotiations.