2. The Beginning:Why was this Method
proposed
In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software
Systems,” which criticized sequential development. He asserted that software should not be developed
like an automobile on an assembly line, in which each piece is added in sequential phases. In such
sequential phases, every phase of the project must be completed before the next phase can begin. Dr.
Royce recommended against the phase based approach in which developers first gather all of a project’s
requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce
specifically objected to this approach due to the lack of communication between the specialized groups
that complete each phase of work.
• At the end of a project, a team might have built the software it was asked to build, but, in the time it
took to create, business realities have changed so dramatically that the product is irrelevant. In that
scenario, a company has spent time and money to create software that no one wants. Couldn’t it have
been possible to ensure the end product would still be relevant before it was actually finished?
3. Agile Model: What is it?
Agile according to English Dictionary means “Someone who can move Quickly and Easily”.Likewise:Agile
Model works time-bound approach that builds software incrementally from the start of the project, instead of
trying to deliver it all at once near the end.
4. • It works by breaking projects down into little bits of user functionality called user stories, prioritizing
them, and then continuously delivering them in short two week cycles called iterations.
5. • Iterative approach is taken and working software build is delivered after
each iteration. Each build is incremental in terms of features; the final
build holds all the features required by the customer.
6. Agile Methodology and Agile
Manifesto
The most popular Agile methods include Rational Unified Process (1994), Scrum (1995), Crystal Clear,
Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and
Dynamic Systems Development Method (DSDM) (1995). These are now collectively referred to as Agile
Methodologies, after the Agile Manifesto was published in 2001.
• Following are the Agile Manifesto principles −
Individuals and interactions − In Agile development, self-organization and motivation are important,
as are interactions like co-location and pair programming.
Working software − Demo working software is considered the best means of communication with
the customers to understand their requirements, instead of just depending on documentation.
Customer collaboration − As the requirements cannot be gathered completely in the beginning of the
project due to various factors, continuous customer interaction is very important to get proper product
requirements.
Responding to change − Agile Development is focused on quick responses to change and continuous
development.
7. How does it work?
• You make a list :Sitting down with your customer you make a list of features they would like to see
in their software. We call these things user stories and they become the To Do list for your project.
• You size things up
• Then, using Agile estimation techniques, you size your stories relatively to each other, coming up
with a guess as to how long you think each user story will take.
• You set some priorities
• Like most lists, there always seems to be more to do than time allows. So you ask your customer to
prioritize their list so you get the most important stuff done first, and save the least important for last.
• You start executing
• Then you start delivering some value. You start at the top. Work your way to the bottom. Building,
iterating, and getting feedback from your customer as you go
• You update the plan as you go.
• Then, as you and your customer starting delivering, one of two things is going to happen. You'll
discover:
• a You're going fast enough. All is good. Or,
• b You have too much to do and not enough time.
• At this point you have two choices. You can either a) do less and cut scope (recommended). Or you
can b) push out the date and ask for more money.
8. How is it different?
1.)Analysis, design, coding, and testing are continuous activities
You are never done analysis, design, coding and testing on an Agile project. So long as there are features to build, and the means to
deliver them, these activities continue for the duration of the project.
9. 2.Development is iterative
Iterative development means starting with something really simple, and adding to it incrementally over time.
It means evolving the architecture, accepting that your requirements are going to change, and continuously refining and tweaking
your product as you go.
10. 3.Planning is adaptive
When reality disagrees with their plans, Agilists find it easier to change their plans than reality. They call this adaptive planning.
And while there are many ways to changes plans, the preferred way is to flex on scope.
4.Roles blur
Roles really blur on Agile projects. When it’s done right, joining an Agile team is a lot like working in a mini-startup. People pitch
in and do whatever it takes to make the project successful—regardless of title or role.
Yes, people still have core competencies, and, yes, they generally stick to what they are good at. But on an agile project, narrowly
defined roles like analyst, programmer, and tester don’t really exist - at least not in the traditional sense.
11. 5.Scope can vary
Agile deals with the age old problem of having too much to do and not enough time by doing less.
By fixing time, budget, and quality, and being flexing around scope, Agile team's maintain the inte
grity of their plans, work within their means, and avoid the burnout, drama, and dysfunction
traditionally associated with our industry.
6.Requirements can change
Traditionally change has been shunned on software projects because of it's high perceived cost late in the game. Agile challenges
this notion and believes the cost of change can be relatively flat.Through a combination of modern software engineering practices,
and open and honest planning, Agilsts accept and embrace change even late in delivery process.
12. 7.Working software is the primary measure of success
The rate at which teams can turn their customer's wishes into working software is how Agilists measure productivity. Project plans,
test plans, and analysis artifacts are all well and good but Agilists understand they in themselves are of no value to the end customer.
13. Agile Myths
• Agile is a silver bullet:You can fail just as spectacularly on an Agile project as you can using any other
traditional method. You'll fail faster using Agile (due to the transparency and visibility it brings) but unfortunately it's not a silver
bullet or an excuse to stop thinking.
• There's nothing inherently magical about Agile. It basically says
• Bring your development team and customer as close together as you can, give them what they need, and then get out of the way.
• Now if you don't have people that like being empowered, taking initiative, and getting things done, that's a different problem.
Agile just gives them permission to do their best work and be accountable for the results.
• Agile is anti-documentation:Agile isn't anti-documentation. A more accurate way to say it
would be Agile doesn't do documentation for documentation's sake.
• Documentation gets treated like any other deliverable on an Agile project. It gets estimated, sized, and
prioritized like any other user story.
• Where Agile pushes back on documentation is as a means of communication. Agile prefers face-to-face
communication over relying on the written word.
14. • Agile is anti-planning:Not sure where this one comes from. There's actually a lot of planning that
goes on in Agile projects.
• You've got your:
• 1 Daily planning with the 10 minute daily standups.
• 2 Bi-weekly planning with the Iteration/Sprint Planning Meetings
• 3 Release planning where team's decide what to ship every three to four months.
• But it wouldn't be fair to say Agile is anti-planning. If anything it is anti-static planning. Meaning Agilist's
expect their plans to change and use tools like burndown charts to track and make these changes visible.
• Agile is undisciplined:When Agile started gaining popularity, its reputation suffered a bit from
some teams taking the easy parts of Agile (like attending daily standups) but leaving out the hard (like upfront
testing and regularly shipping production ready working software).
• The truth is Agile is a very disciplined way of delivering software.
• • You have to test.
• • You have to get feedback.
• • You have to regularly ship software.
• • You have to change and update the plan.
• • You have to deliver bad news early.
• This isn't easy stuff. It's not for the faint of heart and requires a lot of hard work, courage, and discipline.
15. • Agile requires a lot of rework:Rework comes in two forms on an Agile project. You've got the rework of requirements - customers
discovering what they really want. And you've got the rework of the software - development teams discover better ways to design the software.
• Both need to be balanced and tempered. Just as business can't indefinitely keep changing their mind, development teams can't forever keep
redesigning the software. At some point we have to ship.
• Agile deals with this tension by empowering both sides with the power to iterate, so long as they work within the project's means.
• Burndown charts play in big role in tracking how Agile project are doing. Just as tools like the Agile Inception Deck make sure everyone is on the
same page with regards to time and money.
• It's a balancing act not unique to software delivery. Any creative work with a deadline (i.e. plays, movies making, or the publishing of daily papers)
faces the same challenges.
• The trick is to do the best work you can, with the time and resources you've got.
• Agile is anti-architecture:Something we got really good at as an industry in the 1990's was building big, complex, expensive, hard to
maintain systems.Agile pushed back on this over engineering by creating terms like YAGNI (You Aint Gonna Need It) to remind teams to keep
things simple until proven otherwise.
• That doesn't mean Agile teams stop thinking, or don't leverage previous experiences.
• It's more an attitude that the best way to build systems is to keep things simple, and only add the complexity when you need it.
• Agile doesn't scale:Agile scales like any other software delivery process. Not that well.
• Look - scaling is hard. There is no easy way to magically coordinate, communicate, and keep large groups of
people all moving in the same direction towards the same cause. It's hard work.
• The one thing Agile does bring to the conversation, is instead of looking for ways to scale up your project, look for
ways to scale things down.
• In other words, if we know we are really good at delivering with small, nimble, agile teams of ten, why don't we
structure our work that way.
16. Agile VS Waterfall
Traditional Waterfall treats analysis, design, coding, and testing as discrete
phases in a software project. This worked OK when the cost of change was
high. But now that it's low it hurts us in a couple of ways.
Poor quality
First off, when the project starts to run out of time and money, testing is the only phase left. This means good projects are forced to
cut testing short and quality suffers.
17. Poor visibility
Secondly, because working software isn't produced until the end of the project, you never
really know where you are on a Waterfall project. That last 20% of the project always
seems to take 80% of the time.
Too risky
• Thirdly you've got schedule risk because you never know if you are going to make it until the end.
• You've got technical risk because you don't actually get to test your design or architecture until late in the project.
• And you've got product risk because don't even know if you are building the right until it's too late to make any changes.
18. Can't handle change
And finally, most importantly, it's just not a great way for handling change.
19. • Agile on the other hand :
• Instead of treating these fixed stages Agilists believe these are continuous activities.
• By doing them continuously:
• • Quality improves because testing starts from day one.
• • Visibility improves because you are 1/2 way through the project when you have built 1/2 the features.
• • Risk is reduced because you are getting feedback early, and
• • Customers are happy because they can make changes without paying exorbitant costs.
20. Concepts
1:User stories
Typically no more than a couple days work, they form the basis of our Agile plans.
User stories form the basis of the Agile plan. They are sized and prioritized like any other wish list. You simply
start at the top and work your way down. Nothing big or complex. Just a prioritized todo list and a desire to get
things done.
We get them by sitting down with our customers and asking lots of questions.
Big rooms with lots of white space to draw are great for gathering user stories. In these story gathering
workshops we draw lots of pictures (flowcharts, screens, storyboards, mockups, anything that helps) and break
the functionality down into simple easy to understand words and phrases our customers understand. User stories!
21. 2.Estimation:This style of estimation (relative over absolute) forms the corner stone of Agile Planning. By sizing our
stories relatively, and feeding actuals back into our plan, we can make some really accurate predictions about the future while based
on what we've done in the past.
22. • Iterations:Agile's engine for getting things done
An Agile iteration is a short one to two week period where a team takes a couple of their customers most important user stories and
builds them completely as running-tested-software.This means everything happens during an iteration. Analysis, design, coding,
testing. It all happens here. The beauty of working this way, is every couple weeks the customer gets something of great value
(working software), but it's also a great way to track progress (measuring the rate at which the team can turn user stories into
production ready working software).
23. • Planning:The fine art of expectation setting
In its simplest form, agile planning is nothing more than measuring the speed a team can turn user stories into
working, production-ready software and then using that to figure out when they’ll be done.Our to-do list on an agile
project is called the master story list. It contains a list of all the features our customers would like to see in their
software.
• The speed at which we turn user stories into working software is called the team velocity. It’s what we use for
measuring our team’s productivity and for setting expectations about delivery dates in the future.
• The engine for getting things done is the agile iteration - one to two week sprints of work where we turn user
stories into working, production-ready software.
• To give us a rough idea about delivery dates, we take the total effort for the project, divide it by our estimated team
velocity, and calculate how many iterations we think we’ll require to deliver our project. This becomes our project
plan.
• # iterations = total effort / estimated team velocity
• For example:
• # iterations = 100 pts / 10 pts per iteration = 10 iterations
• Now, as we start delivering, one of two things is going to happen. We are going to discover that a) we are going
faster than expected or b) we are going slower than we originally thought.
• Faster than expected means you and your team are ahead of schedule. Slower than expected (more the norm)
means you have too much to do and not enough time.
• When faced with too much to do, agile teams will do less (kind of like what you and I do when faced with a really
busy weekend). They will keep the most important stories, and drop the least important. This is called adaptive
planning and it’s how Agile teams work within their budgets and keep their projects real.
24.
25. • Unit Testing
• Unit tests are snippets of test code developers write to prove to themselves that what they are developing actually works. Think
of them as codified requirements.
• They are powerful because when combined with a continuous integration process they enable us to make changes to our software
with confidence.
26. • Refactoring:As we add more functionality to the system we need a way of maintaining our design and keeping our
house in order. In Agile we call this refactoring.
• For example, instead of copying and pasting code every every time we need some functionality, it's much easier to maintain if
we extract that code into a one place and call it from where ever we need it.
27. Continuous Integration
Continuous integration is about keeping it all together. On a team of more
than one, you are going to have people checking code in all the time. We
need a way to make sure that all the code integrates, all the unit tests pass,
and a warning if anything goes wrong.
28. Test Driven Development
Test Driven Development is about writing the test first before adding new functionality to the system. This seems backwards as first,
but doing this:
• Defines success up front.
• Helps break our design down into little pieces, and
• Leaves us with a nice suite of unit tests proving our stuff works.
Agile developers work in this circle of life when adding new code. Write the test first. Make it pass. Then refactor.
