Look*Gade

credit : http://www.versionone.net/Resources/AgileBenefits.asp 

Benefits of Agile Development

Agile methods grew out of the real-life project experiences of leading software professionals who had experienced the challenges and limitations of traditional waterfall development on project after project.  The approach promoted by agile development is in direct response to the issue associated with traditional software development – both in terms of overall philosophy as well as specific processes. 

Agile development, in its simplest form, offers a lightweight framework for helping teams, given a constantly evolving functional and technical landscape, maintain a focus on the rapid delivery of business value (i.e., “bang for the buck”).  As a result of this focus and its associated benefits, organizations are capable of significantly reducing the overall risk associated with software development.

In particular, agile development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, is able to ensure that value is continuing to be maximized throughout the development process.  As a result of this iterative planning and feedback loop, teams are able to continuously align the delivered software with desired business needs, easily adapting to changing requirements throughout the process.  By measuring and evaluating status based on the undeniable truth of working, testing software, much more accurate visibility into the actual progress of projects is available.  And finally, as a result of following an agile process, at the conclusion of a project is a software system that much better addresses the business and customer needs.

The diagram below displays the differences between agile and waterfall development processes. By delivering working, tested, deployable software on an incremental basis, agile development delivers increased value, visibility, and adaptability much earlier in the lifecycle, significantly reducing project risk.

Agile Development Value Proposition

Four Methods of Perfecting Agile

Most organizations start doing agile imperfectly. Someone introduces a few practices or a manager gets a team some training, or a person starts using agile terminology. And things might improve, particularly with the use of iterations. One of the core ideas of agile methods is to have frequent delivery of valuable results. In fact, this core idea can be used to drive the improvement of an agile process. How? Here are four methods of perfecting agile by expanding the definition of done.

Perfecting Agile

Let’s suppose you already understand the benefits of agile. With these benefits in mind, you would like to improve the organization’s ability to deliver working, valuable results at the end of every iteration so that you can get better at realizing those benefits. The primary way to do this is by expanding the definition of done. You can imagine this like so:

On a regular basis, the team/organization find ways to bring work done in either the preparation stage or the close stage into every iteration of the agile portion of the project. By moving the work from these “bookend” stages into the iterations, you reduce the amount of time spent in those stages and simultaneously create a more complete delivery every iteration. The “definition of done” is now expanded to contain the results or value delivered by the work that was taken out of the startup and shutdown stages of the project. By expanding the definition of done, each iteration delivers a more “complete” increment of value, and there is less work done before or after iterations in order to plan or deliver. This gradual process allows the team to get better at doing agile.

There are four methods for transferring work from the start and end of a project into the iterations of a project.

Expand the Agile Team’s Skill Set

In some ways, this is the simplest and most common approach to expanding the definition of done in the agile portion of a project. By training, coaching, mentoring, re-assigning or hiring, a team’s capacity to do work is expanded and used to expand the definition of done. As a simple example, a software developer might learn to use an automated unit testing framework and therefore expand the definition of done to include some amount of unit test coverage of delivered code. In general, training, coaching and mentoring existing team members should be preferred over adding people to the team since the addition disrupts the team’s development and can increase communication overhead among team members.

Expand the Agile Team’s Authority

Sometimes, a team is not able to do part of the preparation work or close up work because they are not authorized to do so. This may be a policy, a unspoken assumption or a bureaucratic procedure. By giving the team (or some person on the team) the authority to do this work, the team can find ways to do it every iteration instead of having to work through another non-team individual. Again, a simple example here is a situation where a technical person is given permission to talk directly to an end user in order to reduce the need for up-front requirements gathering and analysis and reduce the need for end-of-project user acceptance testing. The obvious challenge to do this is the question of trust (or lack thereof).

Automate an Existing Manual Process

Automation is often given far less than its due consideration. This is primarily be cause automating a process is an investment of work in and of itself. Fortunately, it is often easy to measure the ROI or savings involved with automation. In many agile environments, heavy automation is critical and a huge enabler for very short iterations. Automated testing, automated translation, automated build processes, are all common areas of improvement. Agile teams should always be looking for opportunities to automate their own work. In this way, the automation work itself is transformed from a separate project to a responsibility of the team.

Remove Wasteful Processes

There are some parts of the project preparation work and the project close up work that are pure waste! There is no independent value to these activities, nor is there indirect value to them. An excellent example of this sort of thing is an approval process that _always_ grants approval (“rubber stamping”). One insurance organization I worked with as they were converting to an agile approach discovered that their “second stage” approvals always allowed proposed projects to proceed. Since they often incurred a 4-6 week delay for this approval process, it became obvious that they should “get rid of it”. Now, what they actually did is made it so that it became a parallel review process rather than a gated approval process; this was so that the true purpose of the activity could still be met: to help stakeholders understand the projects that were being worked upon. Here, there is no need to take this approval process and somehow work it into every iteration. An agile approach tends to increase the visibility of the work anyway, so it may be discovered later on that the review process can also be done away with.

references: http://www.agileadvice.com/archives/training/index.html

    Today, we will look at developers’ top 5 benefits using Agile Approach. If you are developer and wanna know why Agile is widely used todays, please do not hesitate to read the article below.

Now, Let’s go and see them>>

First,

More involvement with the customer

Our team agrees that this is the #1 benefit of agile development. Damien told me, “…so you both gain a better understanding of how the app will work and be able to resolve issues and design adjustments quicker.” I couldn’t agree more. When I was playing the middle man role of PM I found that my translating back to the team wasn’t always 100%. When the team can interact directly with the customer, asking questions, getting clarification, discussing ideas, then there is a greater likelihood that what is produced is what the customer wants. This will, in our experience, work out well if the following is in place:

• The scrum master trusts their team
• The project is using scrum
• The customer understands scrum
• The customer understands that once a sprint begins it cannot be changed, unless they decide to prematurely stop it, and have meeting explaining why

Second,

Self-managing teams

As I said in my post about the business benefits of agile, I had heard this term thrown about without explanation. Let me explain it here. With scrum, the product owner (a.k.a. customer) puts stories into the backlog, and then controls the development by prioritizing the stories, with the most important on the top. At the beginning of each sprint at the sprint planning meeting, the team determines what they will commit to over the next 10 business days. They write out the tasks that make that story happen, and development begins. Each day there is a scrum, where the team and the scrum master get together. The team reports on the following:

• What did you do since the last scrum?
• What are you planning to do until the next scrum?
• Is anything holding back your progress?

In the daily scrum, the scrum master is a leader, leading the team through the process. While the scrum master can offer advice, he does not tell the team how to go about their daily development activities. It is up to the team to decide the best course of action. They are empowered! What a novel idea, empowering the people that are doing the actual work. That is what is meant by self management: the team manages the “how” rather than a project manager telling them. For us, this is a no brainer. There is literally no way for me, as a manager, to be involved in the code as deeply as the development team, so why not have them make their own decisions? I trust them, and we all learn from our mistakes.

Third,

Centralized controls fail in the face of increased complexity

Another step in removing the bureaucracy of the past is to delegate decision making to the feet on the ground people, in our case the development team. This becomes increasingly important as complexity grows. Should the understanding of what “done” means for a particular story, the team is the best equipped to determine impact, to decide what changes are necessary, and to put the changes in place.

Forth,

Increased team participation

According to Ken Schwaber in Agile Project Management with Scrum, “optimally, a team should include seven people.” Schwaber is obviously referring to larger projects, as that would involve our entire team. The point here though is that the larger the group, the less overall communication you have. I will use my senior project class as an example. We had 21 people in the class and started out using a waterfall methodology (due to the teacher creating the groups – UI, database, etc.). When we were all together as a large group, the dominant personalities stood out and only they spoke. When we broke into our smaller groups there was a lot more interaction and everyone had a chance to speak. Perhaps there is something intimidating about large groups that cause many to shy away from speaking…

and last,

Happy developers = productive developers

Moving to agile development and scrum, empowering our team to make their own decisions, and removing the communication barrier between our team and our customers are definitely the best decisions I have made in regards to our development methodology. Our entire team is very happy to be using agile, and love daily scrum; we look forward to it every day. The team knows that they are trusted to make their own decisions, and don’t have to check with a manager before implementing them. They are happier developers for it, and are many times more productive, as they are left to focus on producing the highest quality product that the possibly can.

Using agile development with scrum can require a fundamental shift in the way project managers think and approach software development projects. It requires one to be more of a leader than a manager. It requires a great amount of trust; however, if you don’t trust those you work with then there is a fundamental problem that cannot be addressed in this post. Ultimately, in my experience, the result is a happier customer who is getting what they want – a high quality product that is what the envisioned. If the customer is happy, then we have been successful.

  If you wonder how to make Agile become real.  Here is a list of some practices that help us turn Agile into more practical ways.  I write them in an alphabetical order. Let’s start ^_____^

• Acceptance Testing
  The customer writes acceptance tests. The tests demonstrate that the story is complete. The programmers and the customer automate acceptance tests. Programmers run the tests multiple times per day.
• Coding Standards
  The code needs to have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style.
• Collective Ownership
  The team owns the code. Programmer pairs modify any piece of code they need to. Extensive unit tests help protect the team from coding mistakes.
• Continuous Integration
  Programmers integrate and test the software many times a day. Big code branches and merges are avoided.
• Customer Team Member
  Teams have someone (or a group of people) representing the interests of the customer. They decide what is in the product and what is not in the product.
• Metaphor or Vision
  The system metaphor provides an idea or a model for the system. It provides a context for naming things in the software, making the software communicate to the programmers.
• Open Workspace
  To facilitate communications the team works in an open workspace with all the people and equipment easily accessible.
• Pair Programming
  Two programmers collaborate to solve one problem. Programming is not a spectator sport.
• Planning Game
  XP is an iterative development process. In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimating the feature costs. Customers select features and package the development of those features into small iterations (typically 2 weeks). Iterations are combined into meaningful end user releases.
• Refactoring
  As programmers add new features to the project, the design may start to get messy. If this continues, the design will deteriorate. Refactoring is the process of keeping the design clean incrementally.
• Simple Design
  The design in XP is kept as simple as possible for the current set of implemented stories. Programmers don’t build frameworks and infrastructure for the features that might be coming.
• Small Releases
  Programmers build the system in small releases defined. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system.
• Sustainable Pace
  The team needs to stay fresh to effectively produce software. One way to make sure the team makes many mistakes is to have them work a lot of overtime.
• Test Driven Design
  Programmers write software in very small verifiable steps. First, we write a small test. Then we write enough code to satisfy the test. Then another test is written, and so on.
• User Story
  A User Story represents a feature of the system. The customer writes the story on a note card. Stories are small. The estimate to complete a story is limited to no greater than what one person could complete within a single iteration.

     I recommend you all to try this Agile’s practices by gradually changing your company process. Then I’m sure you will love this light-weight methodology.

Today, we will focus on process of agile.  I didn’t write this article myself but I find that it’s a very good one. If you would like to know more at the original site. please visit  http://www.objectmentor.com/omSolutions/agile_what.html

Agile/XP teams use an iterative design process. The process is described briefly below:

• Envisioning
  The process begins with envisioning where the team gathers information about the market and the product. They assess the risks associated with building the product from a market and development perspective. Product requirements are entered into a requirements backlog and risks are entered into a risk backlog.
• Definition
  The team proceeds to definition where product requirements are converted into product features containing concrete use cases and acceptance criteria. These features are sorted into product releases and initial development estimates are created. In addition, a product architecture is also created. In large-scale development environments, teams are organized around the architecture (e.g. application teams, component teams, platform teams) and given ownership for specific parts of the architecture.
• Development
  From there, the team proceeds into the development. The teams divided the features they need to develop into stories. These stories are small units of functionality taking about a week or two to code and test. Developers now prepare estimates for the stories and compare their estimates to the original estimates created during the definition phase. Discrepancies or anomalies between the estimates are resolved through negotiation. This process ensures the integrity of the estimates. It allows the customer to prioritize development based on the value and time cost of the stories. It allows developers to “own” and “commit” to their deliverables. And it allows “stakeholders” to set release dates that can be used by the rest of the company. Development is done iteratively and incrementally using Test Driven Development Model and a Continuous Build and Integration Environment. Test are written for each unit of code and only code that passes its test is committed to the build. Every two weeks, the development team delivers working stories that pass their tests.
• Release Engineering
  End-to-end release engineering is performed on an ongoing basis as the development proceeds and the product evolves. Like unit tests, end-to-end acceptance tests are run from day one to ensure the overall continuity and integrity of the system as a whole. As a result, a robust and reliable system grows in functionality, piece by piece, from the very first day. This means that, at any point in time, a “potentially shippable product” is available for release. Practically speaking, it is highly unlikely that the initial builds would actually be “shipped” but the theory behind the Agile/XP methodology is that any software developed should be reliable and robust at any point in time.

Throughout this iterative process, progress is measured and tracked by automatically querying the code library and generating daily and weekly reports. Everyone from developers to stakeholders can see how many stories have been built, how many stories have passed their tests, how many stories have failed and how many stories still need to be built. So rather than relying on “hand-crafted” GANT charts, Excel spreadsheets or PowerPoint slides, Agile/XP measures progress by interrogating the system itself. In essence, the system becomes the measure of its own success.

    Behind agile, ther are many principles placed on communication, simplicity, feedback and spirit. These are expressed as principles for agile methodology for software development process. Now, I can summarize these principle into lists below:

• early and continuous delivery of valuable software
• frequent delivery of working software
• working software is the primary measure of progress
• welcome and adapt to changing requirements
• demand daily communication between business people and development
• demand direct communication between business and development
• build projects around teams of motivated people
• trust and support the teams
• allow teams to work at a pace that can be sustained forever
• allow teams to organize themselves
• allow teams to reflect on their successes and failures
• strive for simplicity in design and execution
• strive for technical excellence in design and execution

   for more information and more formal principles, you can simply find at http://www.objectmentor.com/omSolutions/agile_what.html

 >> Team Member<<

As I’ve stated before, Agile is a light-weight methodology that allows teams to develop software in the face of vague and rapidly changing requirements. This light-weight methodology combines a set of principles, practices and processes that allows the development team to build software quickly and build software properly. The methodology can be successfully deployed in small, medium or large-scale business environments.

      At the heart of the methodology is the Product Team. This team contains all of the skills necessary for successfully delivering a working software product. It includes people who perform the roles of a product owner, developer, architect, quality assurance, requirements engineer, business analyst, documentation specialist, and user interface designer. It also includes a person who is an actual customer of the product or who can act on the customer’s behalf. This person plays a pivotal role in defining concrete requirements, prioritizing requirements and setting acceptance criteria for requirements. By working together, this team moves from initial concept to final delivery. Don’t forget that communication ways of agile team is horizontal not vertical, so decision making is based on functional core team not a team leader.

      First of all, I would like to say that I wanna improve my english especially writing so i would write all articles about agile in English. ^ , ^

Many people who get involved in software development process may familiar with this word, “Agile”.  But for ones who have never heard about this word before and interested in software engineering, this article can help you.

>>Let’s start<<

Overview

>>Agile Methodology is a conceptual framework of software development process. We develop software in short amount of time called iteration. Agile focuses on doing things in small increments with minimal planning rather than long-term planning. Each iteration usually lasts in 1 to 4 weeks and passes through a full software development cycle including  planning, requirements analysis, design, coding, test and delivery some features to customers. Then team would re-evaluate project priorities before starting new iteration. >> With Agile, customers can gradually see Their products, if there exists any errors or any faults, developers can correct them and release in the next iteration.