Agile Software Development
By now, you've googled the keywords 'Agile Software Development' or a variation of that and after getting
tens of 1000's of links you've stubmled on this link. Assuming that 90% of the visitors want a quick
definition, we are putting this at the top.
For the remaining 10% that want as much detail and supporting information possible, we have compiled
supporting documentation from books, articles, our own knowledge and experience and structured it to your
benefit so feel free to stay on the site and learn as much as you can.
Definition of 'Agile Software Development':
Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an
answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative
approach to software development using shorter and lightweight development cycles and some different
deliverables.
After extensive research, we have found that like other resources, the term Agile as it relates to modern
software development, was being used during the 1990's in various published articles both on the internet
as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to
software process. While the ideas were not new, they gained enough steam for people to pay close
attention especially while search engines on the internet became very popular.
There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site
that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original
concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the
consitution and the Declaration of Independence.
They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in
the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software
Development.
The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt
were actively involved in software development communities with these similar ideas and got seventeen of
them together for the Snowbird workshop. Initially, they wanted to get together and build better
understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that
could be used to rally the industry behind these kinds of techniques. We also decided we wanted to
choose a name to act as an umbrella name for the various approaches.
One next step that did follow, with the active involvement of many of these authors, was the formation of
the agile alliance. This group is a non-profit group intended to promote and research agile methods.
Amongst other things it sponsors an annual conference in the US.
Under this broad term of 'Agile Software Development' there are other approaches such as Extreme
Programming, Scrum, Lean Development, and RUP. Each of these more particular approaches has its own
ideas, communities and leaders. It is important to understand that Agile is not a specific methodology,
but a higher concept representing and Iterative approach with newly defined underlying principles. It is
with each approach you can see the specific deliverables and concepts for how to work the process.
XP (Extreme Programming)
Extreme Programming (XP) is actually a deliberate and disciplined approach to Agile software development.
One of the first approaches to gain main-stream success, Extreme was found to be most successful at
smaller companies especially in the dot-com boom.
XP is successful because it stresses customer satisfaction. The methodology aims to deliver the software
your customer needs on time. XP allows the software developers to confidently respond to changing
software requirements, even late in the life cycle.
This methodology additionally focuses on team work. Managers, customers, and developers are all part of
a team dedicated to delivering quality software. XP implements a simple and effective way to enable
groupware style development.
XP improves a software project in four essential methods; communication, simplicity,feedback, and courage. XP programmers communicate with their customers and programmers. The design should
be simple and clean. They get feedback by testing their software starting on day one and deliver the
system to the customers as early as possible and implement changes as suggested.
Agile Development with Scrum
Agile and Scrum development methodologies aim to correct the problem of projects not having an end in
site most likely from out of control software requirements. Scrum solves this by applying what will
appear to be common sense after you engage in the methodology for a few projects. This Agile software
development method has some very key principles.
1. Deliver products based on need from high-priority down.
2. Deliver the absolute minimum that the customer wants.
3. Eliminate waste from your projects wherever possible.
4. Deliver projects in short bursts, called iterations.
Scrum is a rugby offensive term where a team pushes forward to score as a single unit. Scrum is a
communication methodology more than a development methodology and because of that, it can be applied to
almost any type of project. Scrum consists of the following core believes:
1. The customer lists all the features they want in priority order.
2. Development efforts are broken into 30 day iterations called sprints.
3. Scrum teams are multi-functional teams of 5-10 that contain all the facets of the team that is needed
to complete the projects.
The Agile (Rational) Unified Process Framework
Another well-known process to have come out of the object-oriented community is the Rational Unified
Process (sometimes just referred to as the Unified Process). The original idea was that like the UML
unified modeling languages the UP could unify software processes. Since RUP appeared about the same time
as the agile methods, there's a lot of discussion about whether the two are compatible.
RUP is a large collection of methods and is a process framework rather than a process. Rather than give a
single process for software development it seeks to provide a common set of concepts for teams to choose
from for an individual project. As a result a team's first step using RUP should be to define their
individual process, or as RUP calls it, a development case.
The key common aspects of RUP is that it is Use Case Driven (development is driven through user-visible
features), iterative, and architecture centric (there's a priority to building a architecture early on
that will last the project through).
Out of all of the Agile iterative software development methods, I find that RUP is the most intensely
defined and works very well at larger corporations that need documented processes. Again, RUP provides a
toolkit of deliverables and it's up for the organization using it to decide how it should work. Toyota
Customer Services HQ in California has their own brand of RUP called BluePrint.
Having experienced both waterfall projects and Agile projects, it's easy for me to give a fair assessment
on how these two stack up against each other. The short answer is that there is no right answer because
both have their place in the IT world. Many of you would grimmace at this notion, but the truth is there
are large corporate and governemnt environments where projects need to go through a rigid life cycle for
them to be successful. This is where Waterfall really pays off.
With that said, for projects that are less than six months in duration, and there is a real need to phase
in the project, Agile all the way. Agile software development projects will allow various groups
including dev, QA and analysts not to constantly wait for each other. What you're really doing is taking
a big project and turning it into several smaller waterfall projects -- each with their own requirements,
design, dev and QA stages.
From a customer perspective, typically a fast-paced customer wants to see progress rather than wait for
everything at once. Agile practices provide this ability.
Organizations need a way to lower engineering costs, increase software reliability, decrease engineering
time and ensure applications are bought off by the business, rather than against them. These four issues
are a demanding order for anyone to fill, although Agile software development techniques can do it in
many application programming scenarios. Agile makes business sense because you can lower costs by
reducing the number of mistakes developers make when building applications. also, Agile programming
techniques can eliminate the huge risk of a failed application.
However, even when an application is deployed and you have it installed on your server, reliability costs
can erode the gain from an application. The five 9's of reliability that most companies strive to achieve
can happen only with a well-designed application that doesn't spend more time in the digital repair shop
than it does answering users' needs. Agile accomplishes this by reducing most development errors per
program and by providing constant testing that locates errors fast.
Many organizations are looking for a fast ROI for any development project. Instead, most projects get
delayed for years as the company waits for the developer to complete the application. Rather than wait
for the entire application, Agile software development techniques help you use at least part of the
application today, which means you obtain a significantly faster benefit from the system. In short, you
can obtain part of the system free because the savings you realize go into the development of the
remainder of the system.
Agile software development helps you avoid the scenario of a deployed broken application by involving the
user early in the development process. If the vendor had followed this approach, the first iteration of
the application would have helped the company realize the expected gain. Instead, many companies spend
time and still more money reworking the application.
In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict
accurately how much work is involved in each project activity. This leads to a significant investment
early in the project, when it is uncertain that the designed functionality is actually desired. Any agile
approach to large-scale development has to avoid the reintroduction of the big design up front. One
solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning
activities for large-scale development efforts should rely on these five levels.
Level 1 - Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this
vision, they explain what an organization or product should look like after project completion. They
indicate what parts of the system need to change and what efforts can be used to achieve this goal.
Level 2 - Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster
frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller
timeframes force a product owner into thinking in steps - into thinking of a road towards the final
product. A product roadmap is created and communicated to fellow delivery people to provide a map so
concept is more of a reality.
Level 3 - Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and
deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of
this changes when applying agile concepts to programs. The first time when rouping activities and
allocating them to teams occurs during release planning.
Level 4 - Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy.
Before or during the session, detail is added to the features by breaking them down into tasks. The
actual capacity of the individual teams is known with more certainty than during the release planning
session. The combination of these increased accuracies helps the team commit to delivering a number of
features during the iteration with a high degree of certainty.
Level 5 - Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a
planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in
the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and
the success of delivering the desired features within the iteration can be determined after the meeting.
Agile software development utilizes a "feature driven" approach of rolling up development progress that
provides an easily digested summary of project status using Parking Lot diagrams. Yet, their appreciation
and use outside of Agile is quite rare. This artifact is a very powerful tool because it provides a
high-level and visual depiction of a project as well as the status of different components.
Parking lot diagrams are not just for Agile "feature driven" projects, they can be used equally as well
on XP, Scrum, or RUP projects. Below is a diagram of a good example of one of these diagrams used in
action.
As projects get larger the number of features or use cases you likely have to manage increases. Small to
medium size projects with a few hundred features can be managed fine with decks of cards, task boards,
and burn-down charts, but as projects scale this information becomes hard to manage and difficult to
digest by stakeholders. Parking Lot diagrams roll-up features into functional groups and then these
groups into functional areas to better show overall progress against business areas.
Agile Feature Driven Development promotes the idea of a chief programmer, an individual who is
responsible for a piece of functionality. Their initials “FB” can be shown above the parking lot diagram.
If a stakeholder has a question about this area, then they know somebody is the designated person to
speak to. Alternatively, if you are working on an XP project with shared code ownership it may not be
appropriate to display initials, in which case simply don’t.
The color of the box indicates status. With the scheme below, white means not started, yellow for work in
progress, Green for complete, and Red for late. Standards vary, some people use Blue for work in
progress, Yellow for nearing the due date, and Red for late, but as long as there is a consensus among
stakeholders for what each color means you should be fine. The main box also contains a percent complete
figure based upon the combined status of each of the (15) features within it.
The bottom area of the box contains a progress bar that duplicates the percent complete figure to give a
more visual measure of this number and the target completion month for this group of features. The real
power of this technique comes when these feature groups are combined into feature areas and an overall
dashboard for the entire project is created.
This Agile Parking Lot Diagram was created using GatherSpace.com. Rather than trying to pull this document together in
visio or another modeling tool, GatherSpace will create this stunning report for you on-the-fly based on
the requirements you have in the system.
While there is no single, agreed to leadership manifesto, industry experts offer similar advice. Based on
key findings in the area of Agile Software development, the below leadership methods have been
identified.
• Modeling desired behaviour
• Creating and communicating a common vision
• Willingness to challenge the status quo
• Empowering others
• Encouraging others
These behaviours have strong correlation with agile project management and software development
recommendations.
1. Modeling desired behaviour
– agile project managers should demonstrate the behaviours they wish their
team to exhibit. Admit your mistakes, promote candid discussion of issues and show humility. Adopt a
sharing, abundant mentality to information and focus on communications.
2. Creating and communicating a common vision – Teams need to have a powerful, uniting vision about the
project and what the system they are building should do. People need to be pulling in the same direction
and a common vision helps align their effort. XP uses the concept of a system metaphor to help create a
common vision.
3. Willingness to challenge the status quo
– No process is perfect or optimally configured for the unique
demands of every project and organization. There need to be regular reviews to ensure the team and
process are on track. In Agile projects, the end of iteration retrospectives where the team is asked,
“What went well?”, “What did not go well?”, and “What can we improve for the next iteration?” Is where
the status quo is challenged. This is an important leadership concept, never to accept the current
process just because it is established.
4. Empowering others
– Really great leaders know that people work best when empowered to make decisions
and given the freedom to self organize and think independently. Agile software development teams leverage
the benefits of empowered working and gain the benefits of greater commitment and accountability. By
allowing team members to sign up for tasks voluntarily, a strong internal commitment to try and deliver
timely to a high standard is generated. Couple this with the agile practice of holding iteration
planning meetings where team members select tasks in the presence with their peers, that gives a sense of
ownership of a product or project which is an increcible way to get employees to feel motivated about the
work they do.
5. Encouraging others – Saying thanks is one of the most cost effective, yet under utilized productivity
tools available to management. It does not take long to do, but if done appropriately with sincerity it
can go a long way towards ensuring continued contribution and motivating staff. Agile projects recognize
this tool and use the iteration retrospectives as opportunities to recognize accomplishments.
|
