532 Introduction To Agile Management

Unit 1
INTRODUCTION TO AGILE
Structure
1.1 Introduction
1.2 How does Agile works
1.3 How Agile is different
1.4 Agile Myths
1.5 Agile Vs Waterfall
1.6 The Agile Approach
Summary
Keywords
Self-Assessment Questions
Suggested Readings
Objectives
After going through this unit, you will be able to:

 Study the Agile concept
 Appreciate how Agile works
 Clarify Agile Myths
 Outline Agile Approach
1.1 Introduction
Agile is a time boxed, iterative approach to software delivery that builds software
incrementally from the start of the project, instead of trying to deliver it all at once near the
end.
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.
1.2 How does Agile work
At its core, Agile does the same thing you and I do when faced with too much to do and not
enough time.
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.
1.3 How Agile is different
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.
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.
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.
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.
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 teams maintain the
integrity of their plans, work within their means, and avoid the burn out, drama, and
dysfunction traditionally associated with our industry.
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.
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.
1.4 Agile Myths
Over the years several myths have formed around Agile delivery. Here are some of the more
popular ones.
Agile is a silver bullet
I wish this were true - but it isn't. 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.
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.
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.
1.5 Agile vs Waterfall
Waterfall challenges
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.
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.
Can't handle change
And finally, most importantly, it's just not a great way for handling change.
1.6 The Agile Approach
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.
User Stories
Because life's too short to write everything down

User stories are features our customers might one day like to see in their software.
User stories are like Agile requirements except that they’re not. For one there’s no guarantee
all these features are going to make it into the final version of the software. Secondly, Agilists
know their customers are going to change their mind - and that’s OK. Because they weren’t
really requirements to begin with.
They are written on index cards to encourage face-to-face communication.
Words are slippery things. Get a comma wrong and it can cost you a million dollars. That’s
why Agilists love index cards. They make it impossible to write everything down and instead
force you to get off your butt and go talk to your customers about the features they’d like to
see in their software.
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.
Estimation
The fine art of expectation guessing
While we aren’t very good at estimating things absolutely, it turns out we are pretty good at
estimating things relatively.
Sizing stories relatively means not worrying about exactly how big a story is, and worrying
more how this story's size compares to others.
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.
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).
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.
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.
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.
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.
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.
Summary
 Agile is a time boxed, iterative approach to software delivery that builds software
incrementally from the start of the project, instead of trying to deliver it all at once
near the end.
 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.
 In Agile, you make lists, you size things up, you set some priorities, you start
executing and you updates the plans as you go.
 Agile isn't anti-documentation. A more accurate way to say it would be Agile doesn't
do documentation for documentation's sake. Agile requires meticulous planning.
Agile is a very disciplined way of delivering software. Agile scales like any other
software delivery process.
Keywords
 Agile: Agile is a time boxed, iterative approach to software delivery that builds
software incrementally from the start of the project, instead of trying to deliver it all at
once near the end.
 Acceptance Criteria: The conditions under which a piece of work may be held to be
complete and fit for potential release.
 Agile Transformation: The process of realigning an organisation towards the timely
and empirical delivery of emergent value, in order that innovative potential might be
harnessed. The change required is typically deep and pervasive.
1. What do you understand by Agile? How does Agile work?
2. Several Myths have been formed around Agile delivery. Identify, Explain and justify
them.
3. Agile requires continuous integration. Comment.
Suggested Readings
 http://agilemanifesto.org
 https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-
Guide.pdf#zoom=100
 http://www.infoq.com/articles/agile-teenage-crisis
 Cohn, M., 2010. Succeeding with Agile. 1st ed. Boston: Addison-Wesley.
 Wanga, X., Conboyb, K. & Cawley, O., 2012. “Leagile” software development: An
experience report analysis of the application. The Journal of Systems and Software,
Issue 85.
Unit 2
Principles of Agile
Structure
2.1 Introduction
2.2 Manifesto for Agile Software Development
2.3 Scrum
2.4 Principles of Agile
2.5 Agile Principles explained
Summary
Keywords
Suggested Readings
Objectives

 Analyse the manifesto for agile software development
 Appreciate Scrum
 State the Agile principles
2.1 INTRODUCTION
Agile is one form of software development methodology. Its main focus is on client
satisfaction through continuous delivery. The focus of Agile is more on limiting the project
scope. An agile project sets a minimum number of requirements and turns them into a
deliverable product.
Agile development methodology provides opportunities to assess the direction of a project

throughout the development lifecycle. By focusing on the repetition of abbreviated work
cycles as well as the functional product they yield, agile methodology is described as
“iterative” and “incremental”. In waterfall, development teams only have one chance to get
each aspect of a project right.
So what is agile? It’s a great way to manage your project, if you’re looking for a looser
structure that embraces change and collaboration.
(Haag & Cummings, 2009) says an Agile project sets a minimum number of requirements
and turns them into a deliverable product. Agile means what it sounds like: fast and efficient;
small; lower cost; fewer features; shorter projects.
2.2 Manifesto for Agile Software Development
In February 2001, the Manifesto for Agile Software Development (The Agile Manifesto,
2001) was created by seventeen people with desires to find alternative approaches to software
development. Each of them played a prominent part in the opposition of the prevailing
software development processes, which they considered rigid, heavyweight and too focused
on documentation. Their response, summarized in the manifesto, clarifies their focus by
valuing:
 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
In Agile literature, Agile methods generally denote a family of methods under the umbrella of
the Agile Alliance, including: extreme Programming, Scrum, Dynamic Systems Development
Method, Crystal Methods, Feature-Driven Development, Lean Development and Adaptive
Software Development. Although differing in specific techniques, these methods have much
in common, including short iterative life cycles, quick and frequent feedback from customers,
and constant learning. Among them, Scrum and XP/Scrum hybrid are by far the most widely
adopted in the past decade. Agile processes bring about a dramatic increase in productivity
and quality. This is achieved through a high degree of communication and interaction, short
iterative development and a strong sense of team responsibility.
The choice of traditional or agile methods for a given project is largely contingent on five
factors:
 The size of the systems development project and team

 The consequences of failure (i.e., criticality)
 The degree of dynamism or volatility of the environment
 The competence of personnel
 Compatibility with the prevailing culture
Barriers to Agile adoption include an inability to change an organization’s culture, followed

by general resistance to change and trying to fit agile into a non-agile framework. The
framework for organizational change is useful for assessing the effort required to meet these
challenges. The biggest concerns about Agile include lack of upfront planning, loss of
management control, and management opposition. Other reasons include communication
problems between development teams and other areas of the business and problems with the
Scrum
2.3 Scrum
The founder of Scrum (Schwaber& Sutherland, 1995) described Scrum as a process

framework that has been used to manage complex product development since the early
1990s. Scrum is not a process or a technique for building products; rather, it is a framework
within which you can employ various processes and techniques.
Scrum is about organizing people and work into short “sprints” of activity, to develop code in
short, small chunks, rather than building one big monolithic blob of code that takes forever to
build, test and “drop” into the system.
Illustration of Scrum framework
Three distinct roles are identified within the Scrum methodology:
 The Scrum master, who ensures the process is followed, removes impediments, and
protects the Development Team from disruption
 The Product Owner, who represents the stakeholders and the business
 The Development Team, a cross-functional, self-organizing team who do the actual
analysis, design, implementation, testing, etc.
Scrum is a suitable method to support development process. It is very efficient in creating

solutions with the highest business value in the shortest possible time. Due to the daily
scrums, any impediments are known to everyone as they occur making it possible to
resolve them as quickly as possible. Furthermore, it adds support to prioritize work and
closely monitor the progress of a project with little to no overhead.
Delving deeper than what they value in a project, the writers of the manifesto agreed on 12
principles, which further defines how to run an agile project.
2.4 Principles of Agile
Agile software development comprises various approaches to software development under

which requirements and solutions evolve through the collaborative effort of self-organizing
and cross-functional teams and their customer(s)/end user(s).It advocates adaptive planning,
evolutionary development, early delivery, and continual improvement, and it encourages
rapid and flexible response to change.
The term agile (sometimes written Agile) was popularized, in this context, by the Manifesto
for Agile Software Development. The values and principles espoused in this manifesto were
derived from and underpin a broad range of software development frameworks, including
Scrum and Kanban.
The Manifesto for Agile Software Development is based on twelve principles:
1. Customer satisfaction by early and continuous delivery of valuable software.

2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts
accordingly
2.5 Agile Principles Explained
Let’s look at each of these 12 principles to learn what they are and how they can help you
manage your projects.
1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
By shortening the time between documenting the project, reporting to your customer and then
getting feedback, you can focus on the real goal of the project, which is delivering what the
customer wants, not what you planned.
2. Welcome changing requirements, even late in development. Agile processes harness

change for the customer’s competitive advantage.
Embrace change. Even when the customer requests a change late in the project phase,
implement it. Why wait for another project to explore another iteration when you can do it
now and get the results immediately? Agile wants you to stay nimble and on your feet so you
can pivot without having to constantly reinvent the wheel.
3. Deliver working software frequently, from a couple of weeks to a couple of months,

with a preference to the shorter timescale.
If you’re going to embrace change, then you’re going to have to give up on your etched-in-
stone schedule, or at least create a shorter range to run your tasks. One way agile does this is
by cutting out a lot of the documentation that is required with traditional project management
when planning your schedule before you ever start a task. The trouble is a lot of that
paperwork isn’t necessary. It only slows things down.
4. Business people and developers must work together daily throughout the project.
It’s like they’re talking two different languages, and in a sense, they are, but both the business
and developer side of the project are crucial to its success. You must build a bridge between
the two so they can understand each other and, as important, work together. Use the same
tools you would manage remote teams to facilitate an exchange of ideas that both sides
understand and are on board with.
5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
In other words, don’t micromanage. It doesn’t work. It takes you away from what you should
be focusing on. It erodes morale and sends talent packing. You assembled the best, now let
them do what they’re good at. If you did the due diligence beforehand, then you can trust
them to do the work. Of course you’ll monitor that work, and step in as needed, but stay out
of their way.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Documenting conversations, creating email narrative streams, even using collaboration

software like Slack, are all well and good. But when you’re trying to move swiftly, you don’t
have time to wait for a reply. You need immediate answers, and the only way to achieve that
speed of response is by talking to your team member or team in person. You can do this by
working in the same physical space or having distributed teams. But if it’s the latter, you
want to try and keep the schedules to the same hours, so you can at least video conference.
That creates a more collaborative environment.
7. Working software is the primary measure of progress.
That means, is the software (or whatever product or process you’re working on in the project)
working correctly? You’re not measuring progress by checking off tasks and moving across
your scheduled timeline, but by the success of the software (or whatever) is the subject of
your project. Basically, it’s staying focused on what’s important. The process is what gets
you to achieve the goal of the project, but the goal of the project isn’t the process.
8. Agile processes promote sustainable development. The sponsors, developers and users
should be able to maintain a constant pace indefinitely.
One reason for short sprints of activity is not only that they lend themselves to accepting
change more readily, but they also help to keep your teams motivated. If you’re working on a
project for an extended period, there’s going to be burnout. It’s unavoidable. Don’t overtax
your team with too much overtime. It’s going to impact the quality of your project. So, get
the right team for the job, one that will work hard but not overextend themselves and put the
project quality in jeopardy.
9. Continuous attention to technical excellence and good design enhances agility.
Whether you’re working on code or something more concrete, you want to make sure that
after each iteration it’s improving. You don’t want to have to come back and fix things later.
Fix them now. Better still, make sure they’re getting better. Use scrum, an agile framework
for completing complex projects, to help review and keep the project evolving.
10. Simplicity—the art of maximizing the amount of work not being done—is essential.
If you’re looking to move quickly through a project, then you’re going to want to cut out
unnecessary complexities. Keeping things as simple as possible is a great ethic to streamline
your process. You can do this many ways, including the use of agile tools that cut out the
busy work and give you more control over every aspect of the project.
11. The best architectures, requirements and designs emerge from self-organizing
teams.
When you have a strong team, you want to give that team the autonomy to act independently.
This means they can adapt to change quicker. In fact, they can do everything with greater
agility because you’ve given them the trust to act without second guessing them. If you’ve
done your job in collecting the right people, then they’ll do their job addressing issues and
resolving them before they become problems.
12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
Another benefit of creating a well-rounded team is that they will stop, reflect and tweak the
way they do things throughout the course of the project. They don’t act by rote or just blindly
follow protocol, but think through their relationship to the project and adjust when necessary.
The last thing you want is a complacent team, one that stands on their laurels. What you need
is an ever-evolving group that is constantly engaged and looking for ways to improve
productivity.
Summary
 Highest priority is to satisfy the customer through early and continuous delivery of
valuable software. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
 Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale. Business people and developers must work
together daily throughout the project.
 Build projects around motivated individuals. Give them the environment and support
they need and trust them to get the job done.
 The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation. Working software is the primary
measure of progress.
 Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
 Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential. The best
architectures, requirements, and designs emerge from self-organizing teams. At
regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Keywords
1. Continuous Delivery: The automated elevation of increments of release quality into a

production environment. See also: continuous deployment, continuous integration.
2. Continuous Deployment: The automated elevation of work done into successive
environments which approach production quality. See also: automation, automated
build, automated testing. See also: continuous delivery, continuous integration.
3. Continuous Integration: The automated integration of work done into an increment
of potential release quality. See also continuous delivery, continuous deployment.
4. Cross Functional: The quality of a team which allows them to complete work-in-
progress by themselves, and without recourse to skills or resources outside the team.
Compare with Skills Silo.
5. Daily Scrum: A daily inspect-and-adapt event conducted by Scrum Development
Teams, in which they re-plan their progress towards their Sprint Goal.
1. ‘Manifesto for Agile Software Development was created with the desire to find
alternative approaches to software development’. Comment!
2. The choice of traditional or agile methods for a given project is largely contingent on
which five factors?
3. What do you understand by Scrum?
4. Explain various principles of Agile in detail.
Suggested Readings
Guide.pdf#zoom=100
Issue 85.
Unit 3
Benefits and Advantages of Agile for Project Management
Structure
3.1 Introduction
3.2 Benefits of Agile
3.3 Advantages of Agile for Project management
Summary
Keywords
Suggested Readings
Objectives
 Analyse the Benefits of Agile

 Appreciate the advantages of Agile for Project management
3.1 INTRODUCTION
Adopting Agile software development practices, we have seen solutions delivered on time
and with a higher degree of client and customer satisfaction. By incorporating the ability to
change, we have been able to better incorporate feedback from demos, usability testing, and
client and customer feedback.
Agile is a powerful tool for software development, not only providing benefits to the
development team, but also providing a number of important business benefits to the client.
Agile helps project teams deal with many of the most common project pitfalls (such as cost,
schedule predictability and scope creep) in a more controlled manner. By reorganizing and
re-envisioning the activities involved in custom software development, Agile achieves those
same objectives in a leaner and more business-focused way
3.2 Benefits of Agile
1. Stakeholder Engagement
Agile provides multiple opportunities for stakeholder and team engagement – before, during,
and after each Sprint. By involving the client in every step of the project, there is a high
degree of collaboration between the client and project team, providing more opportunities for
the team to truly understand the client’s vision. Delivering working software early and
frequently increases stakeholders’ trust in the team’s ability to deliver high-quality working
software and encourages them to be more deeply engaged in the project.
2. Transparency
An Agile approach provides a unique opportunity for clients to be involved throughout the
project, from prioritizing features to iteration planning and review sessions to frequent
software builds containing new features. However, this also requires clients to understand
that they are seeing a work in progress in exchange for this added benefit of transparency.
3. Early and Predictable Delivery

By using time-boxed, fixed schedule Sprints of 1-4 weeks, new features are delivered quickly
and frequently, with a high level of predictability. This also provides the opportunity to
release or beta test the software earlier than planned if there is sufficient business value.
4. Predictable Costs and Schedule
Because each Sprint is a fixed duration, the cost is predictable and limited to the amount of
work that can be performed by the team in the fixed-schedule time box. Combined with the
estimates provided to the client prior to each Sprint, the client can more readily understand
the approximate cost of each feature, which improves decision making about the priority of
features and the need for additional iterations.
5. Allows for Change

While the team needs to stay focused on delivering an agreed-to subset of the product’s
features during each iteration, there is an opportunity to constantly refine and reprioritize the
overall product backlog. New or changed backlog items can be planned for the next iteration,
providing the opportunity to introduce changes within a few weeks.
6. Focuses on Business Value

By allowing the client to determine the priority of features, the team understands what’s most
important to the client’s business, and can deliver the features that provide the most business
value.
7. Focuses on Users
Agile commonly uses user stories with business-focused acceptance criteria to define product
features. By focusing features on the needs of real users, each feature incrementally delivers
value, not just an IT component. This also provides the opportunity to beta test software after
each Sprint, gaining valuable feedback early in the project and providing the ability to make
changes as needed.
8. Improves Quality
By breaking down the project into manageable units, the project team can focus on high-
quality development, testing, and collaboration. Also, by producing frequent builds and
conducting testing and reviews during each iteration, quality is improved by finding and
fixing defects quickly and identifying expectation mismatches early.
Other important Benefits
 Iterative, incremental and evolutionary
Most agile development methods break product development work into small
increments that minimize the amount of up-front planning and design. Iterations, or
sprints, are short time frames (timeboxes) that typically last from one to four weeks.
Each iteration involves a cross-functional team working in all functions: planning,
analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration
a working product is demonstrated to stakeholders. This minimizes overall risk and
allows the product to adapt to changes quickly. An iteration might not add enough
functionality to warrant a market release, but the goal is to have an available release
(with minimal bugs) at the end of each iteration.Multiple iterations might be required to
release a product or new features. Working software is the primary measure of
progress.
 Efficient and face-to-face communication
The principle of co-location is that co-workers on the same team should be situated
together to better establish the identity as a team and to improve communication. This
enables face-to-face interaction, ideally in front of a whiteboard, that reduces the cycle
time typically taken when questions and answers are mediated through phone,
persistent chat, wiki, or email.
No matter which development method is followed, every team should include a

customer representative ("Product Owner" in Scrum). This person is agreed by
stakeholders to act on their behalf and makes a personal commitment to being available
for developers to answer questions throughout the iteration. At the end of each iteration,
stakeholders and the customer representative review progress and re-evaluate priorities
with a view to optimizing the return on investment (ROI) and ensuring alignment with
customer needs and company goals.
In agile software development, an information radiator is a (normally large) physical

display located prominently near the development team, where passers-by can see it. It
presents an up-to-date summary of the product development status. A build light
indicator may also be used to inform a team about the current status of their product
development.
 Very short feedback loop and adaptation cycle
A common characteristic in agile software development is the daily stand-up (a daily

scrum in Scrum framework). In a brief session, team members report to each other what
they did the previous day toward their team's iteration goal, what they intend to do
today toward the goal, and any roadblocks or impediments they can see to the goal.
 Quality focus
Specific tools and techniques, such as continuous integration, automated unit testing,
pair programming, test-driven development, design patterns, behavior-driven
development, domain-driven design, code refactoring and other techniques are often
used to improve quality and enhance product development agility.This is predicated on
designing and building quality in from the beginning and being able to demonstrate
software for customers at any point, or at least at the end of every iteration.
3.3 Advantages of Agile for Project Management
#1 Reduced Risk
There, the process follows a very strict, step-by-step structure where the entire project is
planned upfront without any scope for changing requirements. In case you need to do a
rework (which happens most of the time), you will need to go back and start applying it from
the very first work phase of your project.
Here comes one of the biggest benefits of Agile which lies within adaptability. Agile teams
are able to better react to emerging changes which reduces the risk of a complete project
failure. This happens through the concept of continuous delivery and getting customer
feedback early in the process, as fast as possible.
In Agile initiatives or projects, instead of having big batches of work, the focus is on breaking
them down into smaller pieces that bring value to the client. These small, but actionable
“deliverables” are being continuously released to the market without waiting for everything
to be completed upfront.
#2 Higher Chances of Meeting Customers’ Expectations
 Identify quality requirements and prepare your team
To implement the built-in quality practice, first of all, you need to have a firm understanding
of your customer’s quality requirements. In an Agile environment, this is done by constant
customer collaboration that occurs throughout the entire project.
Also, you need to make sure that your team members are aware of what is expected of them
in terms of quality at every step of the work process. They should be equipped with the right
tools and training to carry out the operations in the most defect-free way.
 Stop the process when a problem emerges
Once the above is in place, you need to allow the process to be stopped when an abnormality
in the development appears. This ensures that whenever a quality issue is found, the focus of
the entire team goes into its immediate elimination, as opposed to letting it go further
downstream. In addition, your team needs to dive deeper into understanding the root cause of
that problem with the goal of making sure it doesn’t happen again.
 Create an environment of mistake-proofing
The third practice of ensuring “built-in quality” lies within mistake-proofing which aims to
create an environment where the accumulation of errors is as low as possible. To do this, you
can establish certain policies in your work process for your team members to follow and
respect before they commit to executing a specific action.
Also, you need to build quality in through 100 percent inspection. Even though having one
big “Quality Assurance” phase at the end of the process is considered as waste, this doesn’t
mean that you shouldn’t break it down into small pieces and spread it across your workflow.
The way to do that is by applying fast and inexpensive quality checks alongside the
development life cycle (after each successive work operation), in order to determine any
potential defects to be cleared out. A simple example of that in a knowledge work
environment can be seen from the image below.
#3 Relevant Metrics
In traditional project management, metrics are predominantly used to show how closely the
project is tracking against cost and schedule. However, what we see there are estimations that
never come to pass as well as no attention to one of the most important things – efficiency.
That’s why in Agile, the focus is on producing results, optimizing performance and taking
data-driven decisions.
For instance, when optimizing your work process and measuring your team’s performance,
Agile provides you with metrics such as lead time, cycle time, aging work in progress,
throughput, etc.
Let’s briefly examine each one of those examples below:
 Lead Time – with its help you can better measure how long it takes you to process
one work item from a customer request to actual delivery.
 Cycle Time – this metric shows you how much time you actually spend working on a
given work item.
 Aging Work In Progress – with the application of this Agile metric, you can track
how your work in progress matures over time, where across your process it moves
faster and respectively slows down.
 Throughput – this metric shows you the productivity of your team. It measures the
amount of completed work against the time consumed.
When it comes to planning and scheduling a project, Agile focuses on forecasting rather than
estimating on gut feelings. This can be done by relying on historical data which is run
through a number of random simulations with the goal to forecast a probable future outcome.
The method is known as Monte Carlo Simulations.
#4 Improved Performance Visibility & Transparency
It is the same in project management. Without having a visible process, you will have a hard
time adapting to emerging changes as well as measuring performance indicators.
That’s why agile projects are distinguished by their transparent work processes. This allows
you to spot issues inside your workflow, put everybody from your team on the same page and
more effectively respond to changes.
In practice, you can make your project’s life cycle more transparent with the help of
the Kanban board for example. There you can break down your bigger initiatives into smaller
tasks (cards), split your work process into different phases, create separate workflows, make
your work policies explicit and visualize the flow of tasks of your team members.
#5 Clear Process and Continuous Improvement
Another advantage of implementing Agile is that it creates a more clear process by

prioritizing open communication as the most effective way to share ideas. Combined with
visualization, this leads to decreasing the time it takes for one message to be delivered across
the team which in turn increases the level of understanding of what needs to be done at every
step of the process. Having that in place, you can enjoy a more informed team that knows
what the common goal is and what they need to do in order to achieve it.
Besides that, in Agile, there is a big focus on continuous improvement which is seen as a
“religion”. As big piles of work are being broken down into smaller pieces and continuously
delivered for customer examination, agile teams can reflect on the feedback they receive and
keep refining a product or service to make it better and better with time.
Summary
 Agile is a powerful tool for software development, not only providing benefits
to the development team, but also providing a number of important business
benefits to the client.
 Agile helps project teams deal with many of the most common project pitfalls
(such as cost, schedule predictability and scope creep) in a more controlled
manner.
 Some benefits of agile is Stakeholder Engagement, Transparency, Early and
Predictable Delivery, Predictable Costs and Schedule, Focuses on Business
Value and on Users and Improved Quality.
 There are lot many advantages of Agile for Project Management such as
reduced risks, increased Customer satisfaction, working as per relevant matrix,
improved performance visibility and transparency and clear process and
Continuous improvement.
Keywords
 Continuous Delivery: The automated elevation of increments of release quality into a

production environment. See also: continuous deployment, continuous integration.
 Continuous Deployment: The automated elevation of work done into successive
environments which approach production quality. See also: automation, automated
build, automated testing. See also: continuous delivery, continuous integration.
 Continuous Integration: The automated integration of work done into an increment
of potential release quality. See also continuous delivery, continuous deployment.
Self-Assessment Questions:
1. Enumerate the Benefits of Agile

2. Elucidate the advantages of Agile for Project management
3. Differentiate between Continuous Delivery and Continuous Deployment.
4. How can you meet Customers’ Expectations through Agile implementation?
Suggested Readings:
Guide.pdf#zoom=100
Issue 85.
Unit 4
Combining Agile with other Methodologies
Structure
4.1 Introduction
4.2 Hybrid Project Management – Combining Agile and Traditional Methods
4.3 By Contrast: Agile Work Methods
4.4 Resource and Capacity Planning in Agile Projects
4.5 Hybrid project management: optimally combining the two methods
Summary
Keywords
Suggested Readings
Objectives

 Appreciate Hybrid Project Management
 Analyse the roles and processes in the traditional project lifecycle
 Combine optimally traditional and agile methods within a single project
 Summarise Hybrid project management
4.1 INTRODUCTION
Different organizations follow different approaches for their software development life cycle.
It might seem strange but you will always feel a sense of rivalry between proponents of
waterfall methodology and agile methodology. Although agile is taking over the industry but
one cannot deny a few strengths of waterfall.
As a manager, you might find yourself in a position where you ask yourself ‘Which approach
should I go for – waterfall or the agile?’ A choice with a lot of consequences.
Overwhelmed by the popularity of agile, you might want to adopt agile and transform your
waterfall organization into agile.
There are several steps you can take to transform your development model from waterfall to
agile. But since old habits die hard, you can also retain the waterfall approach and
simply make agile work in your waterfall organization.
If you don’t want to completely switch to one approach and discard another, you are
definitely making a wise choice by keeping the best of both approaches. There are several
options to make waterfall and agile get along, so to speak.
These ‘hybrid’ methodologies are designed according to similar principles – combining the
strengths of both waterfall and agile into one approach.
Why make Waterfall and Agile methodology get along?

The most challenging part of starting a new project for any test manager or test lead in a start-
up, small businesses or an enterprise is indeed to plan the project.
Traditionalists believe in waterfall methodology as a well-established practice that depends
on rigorous documentation and rigid governance. However, agile has made a lot of in-roads
in modern teams as it is more adaptable to the changes which often make deliverables quite
unpredictable.
A single methodology cannot be the only hammer to nail all the solutions.
The Agile-Waterfall Hybrid is often considered a smart approach for adopting both
methodologies without compromising too much, essentially utilizing the best of both worlds.
The main aim of the hybrid methodology is to enable teams to define requirements and adapt
to changing requirements through continuous feedback and delivery. The hybrid method
retains the clarity and tracking system of waterfall method, while embracing the adaptability
and flexibility of agile.
Before we get into how a combination of agile and waterfall models work, let’s review how
each of them works individually.
Agile methodology uses an iterative process where all the teams and collaborate and client
provides feedback throughout the entire process of developing a new software product.
In an agile methodology, a large amount of work is divided into smaller chunks called
‘sprints’. A sprint is developed and tested in a parallel fashion. This means that testing is not
a separate phase but an integral part of the development process. The main aim of the testing
team is to ensure early identification of bugs, issues and defects.
Waterfall is a traditional approach which emphasises the sequential movement of a project

and consists of finite phases, where the previous phase must be reviewed and verified before
moving on to the next one.
An independent quality assurance team defines test cases to evaluate whether the product
fully or partially satisfies the requirements outlined. The test team is supposed to execute
these test cases and validate the developed product or program
Water-scrum-fall
One model that makes waterfall and agile get along is the Water-scrum-fall model.
Business analysis and release management teams follow the traditional waterfall methods,
while the development and testing team scrum methods in a limited way.
Water-scrum-fall method employs the traditional waterfall approach for planning,
requirements gathering, budgeting and documenting the project’s progress. When there are
enough details to begin development, the team switches to a timeboxed, iterative version of
Scrum for product development.
This method uses agile principles and scrum communication techniques in day-to-day
activities related product development.
Agile Practice:
Knowledge Areas Application in Agile
Integration
Engagement of team members as local domain experts
Management
Scope is define and refines throughout the project. Backlog
Scope Management
consist the requirement
Schedule Adaptive approach to use short cycle time to work and
Management review the result
Light weight estimation used to generate fast and high level
Cost Management
forecast
Quality
Frequent quality and review steps throughout project
Management
Resource
Team structure that maximize the benefit
Management
Communication
Transparent project artefacts and regular stakeholder review
Management
Risk Management Frequent review of incremental work products
Procurement Known seller with collaborative working relation reduce the
Management risk
Stakeholder
Adaptive engagement and participation with Stakeholders
Management
Agile Manifesto Mapping
Breadth of Coverage
4.2 Hybrid Project Management – Combining Agile and Traditional

Methods
Agile or traditional? If you are weighing the pros and cons of both project management
methods, there is a good alternative. Work with both methods by using hybrid project
management.
This part of the unit explains the best scenarios for using this hybrid approach. An example is
used to illustrate how hybrid project management methodology is put into practice.
Hybrid Project Management
A hybrid approach to project management thereby integrates the various methods (such as
PMI and scrum) or the use of diverse elements from various methods (such as user stories
from scrum with the V model XT software specifications).
Which scenarios are best suited to hybrid project management?
Many organizations function in an environment in which traditional processes have evolved

over time and compliance is required with broad obligations and required standards. For
projects, this means that there is a focus on choosing methods that clearly define the plans
and project goals and require that everything is documented. Or methods are prescribed
by an external source, such as a regulatory authority.
However, times are changing. As software continues to play an increasingly important role in
hardware products, agile methods ‒ with their iterative processes and shifting objectives from
sprint to sprint ‒ have become increasingly popular.
Combining traditional methods for some of the subprojects with elements of the agile
methodology (such as scrum) lets organizations take advantage of the best of both worlds to
find the solutions best suited to their individual needs. This can enhance the project’s benefits
by, for example, achieving better results, reaching the goals faster, or minimizing expenses.
Roles and processes in the traditional project lifecycle:
 Project sponsors
 A project manager
 Several team leaders
 Team members
 A Project Management Office (PMO)
One or more project sponsors define the overall goal. The objectives are then to narrow these
goals down to actual targets, with the expectation that these will be met. It’s important to
determine what skill sets are needed and when, and then find out when these will be
available.
The project is then prioritized and considered when resources are allocated. Team members
are different for each project, as each member is chosen based on the skill sets needed for that
particular project. The team leaders from the various departments need to see what resources
they need to handle their daily operations to find out what resources can be made available to
the project.
As the project progresses, some deadlines may need to be modified and other elements
changed, but the focus should always be on ensuring that the specified goals are met by the
given deadline. Resources can be withdrawn from lower-priority projects and reassigned to
top priority projects so that team members devote most of their energy to those projects
having the highest priority.
Traditional project lifecycle: various reports during the project’s lifecycle and the assigned
roles
It’s important to keep an overview of all the current and new projects and their resource
utilization. In addition, close coordination is required to optimize resource utilization with
regard to the latest requirements and circumstances.
Any changes to the project are carefully tracked and, together with the sponsors and/or end
customer, evaluated with regard to added value and additional cost as compared to the
original specifications. Status reports are prepared to show progress on the delivery of
existing orders. Detailed schedules are created in the form of Gantt charts and milestone trend
analyses. Risk analyses, with recommendations for avoiding these risks or minimizing their
effects, may also be included.
The final result is generally some form of acceptance document that compares the
delivered result with the original order. If there are deficiencies, these will be listed in the
document and subsequently corrected. Sometimes these deficiencies are minor and can be
accepted, but sometimes 100% compliance with the original specifications is required
because, for example, the deliverable is a bridge that must stand or a crash test that must be
withstood.
In the end, there’s a final meeting involving the team members, project managers and
sponsors to discuss and document the lessons learned so that future endeavors may benefit.
This is a good time to ask yourself what can be done better the next time. Achieving goals
and allocating the required resources is completely normal and necessary, right? Yes, if the
goals are absolutely clear and these are the right measures for achieving those goals, then the
traditional approach is the best one.
However:
 What if you are expected to deliver results that can be obtained in several ways?
 What should you do if new insights and technologies become available during the
project?
 How can you integrate these into the existing project plans to deliver a better
solution?
 Wouldn’t it be great if there was some way to get the sponsors, customers, and users
to all agree to these changes without risking non-conformance with the specifications?
Sometimes it’s just not possible to clearly define what the deliverable should be because
those involved themselves don’t know exactly what they want or need. Have you ever not
realized you were hungry until the scent of food made you crave a particular dish? Suddenly
you knew exactly what you wanted.
4.3 By Contrast: Agile Work Methods
Agile approaches are much more common today, especially at the product development stage
in software development or other similar areas. This often applies to cloud solutions, which
must provide uninterrupted service.
Increasingly, the approach is used in other high-tech and complex environments as well. The
traditional approaches described above are just not suitable in cases like this.
Therefore, it has become prevalent, as in agile approaches, for a fixed team to develop
iterative versions of a product while the users are already using the product on a daily
basis. After all, the users also want to see ongoing progress.
A team is often put together only once and then continues to live for and with this software,
just as other teams do with their products. The teams are rarely ever reorganized.
Agile organization with a fixed team per product

Looking at the roles in agile methods (such as scrum), we can identify the following:
The Product Owner
 makes all the decisions regarding the product

 prioritizes and maintains the backlog
 is constantly available
The Scrum Master
 manages the process

 removes impediments
When it comes to resource planning, the following applies: Strategic and tactical planning is
also necessary for agile teams. Staff is needed for ongoing projects, new staff must be trained,
etc.
Remember that no one is permanently available 100% of the time. Plan for absences due to
vacations, etc. What’s the best way to handle resource planning and capacity planning?
4.4 Resource and Capacity Planning in Agile Projects
Agile methods offer an advantage in resource planning: their fixed product and project teams,
as well as the fixed cadence, make overall planning and the shifting of staff between
projects much easier.
Agile teams are mostly self-organized and have the experience necessary to estimate the
effort involved. This starts with a rough estimate that becomes more detailed in the course of
the project. The teams report when something has been completed and give feedback in
reviews and retrospectives.
Together with the product owner, they gather stakeholder feedback in review meetings.
Kick-off meetings are no longer required in agile environments.
Regular sprint planning, reviews, and retrospectives, on the other hand, are mandatory.
In addition, the development team meets daily to discuss progress with regard to the sprint
goal.
The only remaining targets can be found in the product backlog or the sprint backlog as a
subset for each sprint. If something is not documented in the backlog, it will not be done.
Communication with the stakeholders is not only through the reviews but also via public
boards with sprint or product burn down charts. This is why the traditional reports with their
schedules, costs, and status are superfluous at best.
Yet, what may be missing is a meaningful multi-project overview.
Lifecycle differences between traditional and agile project planning
4.5 Hybrid project management: optimally combining the two methods
How can you combine these two different worlds?
There are many approaches to introducing hybrid methods:
1. Concurrent Use of Traditional and Agile Methods:
 Some business units always use traditional methods (e.g. consulting). Others always
use agile methods (e.g. software development).
 Some projects use a traditional approach, others an agile one.
 Some parts of a project are implemented in a traditional way, other parts using agile
methods.
 High-level planning employs a traditional approach, detailed planning an agile one.
2. Combining Traditional and Agile Methods in a Single Project:
 In traditional projects:
o Closer coordination with users and more frequent, implementable intermediate
results
o Regular meetings to discuss progress (not necessarily daily – once a week is a
good start)
o Retrospectives (Lessons Learned) after each status update meeting, not just at
the end
o There is a fixed team for the entire duration of development
 In agile projects:
o Scrum masters also serve as project managers in the traditional sense
o A backlog is created for each project phase rather than as a specification for
the overall product
o Project planning is synchronized with the sprint lengths
o Projects are planned using phases and milestones – at a higher level than the
sprints and in addition to them
o There are status reports and milestone trend analyses for management and for
the stakeholders
o (By the way, many agilists are unhappy with the latter two examples, as they
can water down the basic agile principles).
Hybrid project management: Example:
For customer consulting projects, you always use traditional methods whereas the endeavors
focusing solely on product development follow agile principles. What to bear in mind:
Customer wishes have to be aligned between the business units.
This means that the sales department must have a say in the release planning.
Hybrid handling of projects with customer consulting and associated product development
Traditional and agile methods within a company: using both methods
Please note: Frequent changes between traditional and agile approaches from one project to
the next pose a risk to the process stability.
Frequent changes between traditional and agile approaches can have a negative impact on
process stability
Therefore, another option is to combine methods in a meaningful way – rather than changing
between methods in projects. To give you an example:
 Traditional concept, specification and implementation for the hardware,

 agile software development
 Traditional acceptance test
or:
 Agile concept and specification

 Traditional implementation and acceptance test
or:
 Traditional methods for everything up to the integration

 Agile integration
Tip: If you use hybrid approaches within a single project, follow this proven approach: use
agile methods for unclear parts of the project while using traditional methods for the clearer
parts.
Combining both methods within a single project: using traditional methodology for
rough planning and agile methodology for detailed planning
Another approach has been proven successful for using hybrid methods in the same project:
 Use traditional methods for high-level planning as a kind of superstructure.
 Add an iterative element afterward using agile work methods.
This approach lets you continue to plan milestones and status meetings. While the same time
benefiting from the advantages of agile work methods.
Making the meeting frequency rhythmic also will minimize friction and the general
coordination effort – which ultimately increases productivity.
Synchronization makes it easier to combine traditional and agile methods
A survey on hybrid PM conducted during one of our webinars held in April 2018 involving
256 respondents (multiple answers possible) revealed that:
 11% of the participants carried out their projects according to the defined methods of
that business unit
 41% decided the method project by project
 40% chose the method based on the project situation
 41% did their high-level planning with traditional methods and used agile ones for
their detailed planning
 18% were still unsure
Agile, Traditional or Hybrid Approaches in Program Management?
Multi-project management will always require an overview of the status, necessary decisions,
and delivery dates.
 Status
 Required decisions
 Delivery deadlines
Problems concerning the project status need to be quickly and clearly discernible (e.g. with
the aid of a red traffic light symbol).
This is another difference. In typical (multi-) project environments, traditional methods will
always be necessary. In the course of product development for “small-scale projects” from
version to version, it is a little different. They can be planned with agile methods without any
problems.
As agile environments do not provide methods for multi-project management, further

questions are unnecessary.
Summary
 The above contents has introduced you to ways in which hybrid project management
– a mix of agile and traditional approaches – can be applied in practice.
 You have learned that there are many ways to apply hybrid methods. For example,
you can use traditional and agile approaches concurrently in different business
units or combined within an individual project.
 There are situations in which traditional methods continue to make sense – despite
growing agility. Moreover, it’s essential that you closely involve all the relevant
departments (such as sales) right from the beginning.
 The best strategy is to introduce the method’s step by step and to find a good team
rhythm for the project.
 Another important point: Special situations or environments often require a
customized combination of methods. It is always better to find a tailored solution for
every individual project (as in our examples above) than to impose an approach from
externally.
 It is sometimes tough to depend exclusively on one approach. The test team manager
or lead needs to choose the methodology that best suits the project’s need, which in
turn entails knowing about the pros and cons of the different methods that can be
implemented.
 There are various hybrid models for the software development life cycle.The water-
scrum-fall model, planning, budgeting and production is done following traditional
approaches, whereas analysis, design, development and testing follows agile
principles.
 By combining the best practices of both methodologies and incorporating the right
hybrid techniques, the entire project can be a success. As long as there is good
communication and effective cooperation between team members, then adopting a
hybrid approach can often be a very effective approach to execute complex projects
with rapidly changing requirements.
 Originally, Agile began as an approach for more effective delivery of software

solutions. However, more and more companies outside the IT sector have started
adopting and realizing the benefits of Agile project management which can be
summarized below:
 Reduced Risk
 Improved Chances of Meeting Customers Expectations
 Relevant Metrics
 Improved Performance Visibility & Transparency
 Clear Process and Continuous Improvement
Keywords
o Hybrid Project Management combines the formal and Agile methods to
create a new project management method. Hybrid employs the thoroughness
of Work Breakdown Structure (WBS) with speed and lean benefits of Agile
for a new project management method which is both detailed and fast.
o Agile Project Management (APM) is an iterative approach to planning and
guiding project processes.
o Water-Scrum-Fall is a software delivery system that sandwiches Scrum
methodology between an up-front design phase and a legacy deployment
mechanism. Many variations of this system exist, and it sometimes goes by
other names, including Scrummerfall and ScrumFall
1. Why make Waterfall and Agile methodology get along?
2. Explain the concept of Water-Scrum-Fall
3. Write a short note on Application in Agile Practice with reference to knowledge areas.
4. How can we combine the Traditional and Agile Methods?
5. Which scenarios are best suited to hybrid project management?
Suggested Readings
Guide.pdf#zoom=100
Issue 85.
Source: By Johann Strasser https://www.theprojectgroup.com/blog/en/hybrid-project-

management/
Unit 5
Popular Agile Methodologies
Structure
5.1 Introduction
5.2. Popular Agile Methodologies
5.2.1. SCRUM
5.2.2 Extreme Programing
5.2.3 Kanban Method
5.2.4 Crystal Method
5.2.5 Scrum Ban , Feature Driven Development
5.2.6 Dynamic System Development Method
Summary
Keywords
References
Objectives
5.1 INTRODUCTION
The Agile methodologies outlined below share much of the same overarching philosophy, as
well as many of the same characteristics and practices. From an implementation standpoint,
however, each has its own unique mix of practices, terminology, and tactics.
The most widely-used Agile methodologies include:
 Agile Scrum Methodology

 Lean Software Development
 Kanban
 Extreme Programming (XP)
 Crystal
 Dynamic Systems Development Method (DSDM)
 Feature Driven Development (FDD)
5.2 Popular Agile Methodologies
5.2.1. SCRUM
Scrum is an Agile methodology that consists of a more complex set of development

principles. They focus on the management aspects of projects. Under this method, the owner
of a given product will collaborate with information technology teams and businesses to
collectively isolate and harness the functions of a system in what is known as a product
backlog. Assorted team members will then distribute a software program in increments —
this is called a sprint, and the typical duration is one month. Upon delivery, an analysis is
made of the product backlog, and priorities are shifted if necessary with each repetition of the
cycle.
As with XP, implementing SCRUM offers a mix of benefits and disadvantages. On one hand,
this Agile methodology enables management teams to spot problems at the development
stage — SCRUM also promotes transparency among colleagues. However, SCRUM can also
result in slapdash programming and leave scant records for handover. As such, the method is
most appropriate for information technology businesses that focus on products, features, and
delivery in partnership with management teams. A good practice from SCRUM is the daily
stand-up meetings – a timeboxed daily event, where all team members discuss work progress
and possible obstacles.
SCRUM is one of the frameworks that revolutionized the software development industry. It
became popular because of its fast iterations and active collaboration between teams,
customers, and stakeholders. For the sake of better collaboration, there are predefined team
roles:
• Product Owner. The PO is responsible for understanding the business and market
requirements. After this, she/he need to prioritize work, build a product backlog and make
sure that everyone understands the work items.
• Scrum Master. The SM educates the team, the product owner, and the business on
scrum processes. It’s her/his responsibility to manage the workflow of the team and to
schedule all resources needed for the completion of each task.
• Scrum Team. The team usually consists of people with different skills such as
developers, automation engineers, and testers. All team members have to support each other
in order to be successful. Most efficient scrum teams are usually co-located and with the size
of 5 to 8 members.
People who’ve compared XP and SCRUM have said that both operate in brief iterations for
the advancement of collective work, which involves businesses managers, development
teams and test subjects throughout the span of a project.
So, Scrum is;
a. Is a single team process framework for product development

b. Consists of Product owner, dev team and scrum owner
5.2.2 Extreme Programing

One of the foremost Agile methodologies is called Extreme Programming (XP), which
involves a high degree of participation between two parties in the software exchange:
customers and developers. The former inspires further development by emphasizing the most
useful features of a given software product through testimonials. The developers, in turn, base
each successive set of software upgrades on this feedback while continuing to test new
innovations every few weeks.
XP has its share of pros and cons. On the upside, this Agile methodology involves a high
level of collaboration and a minimum of up-front documentation. It’s an efficient and
persistent delivery model. However, the methodology also requires a great level of discipline,
as well as plenty of involvement from people beyond the world of information technology.
Furthermore, in order for the best results, advanced XP proficiency is vital on the part of
every team member.
Essentially, XP works best among small teams comprised of experienced developers with a
proven track record in communication and management.
a. eXtreme Programing (XP) based on frequent cycle
b. Method was formalize with 12 set of primary practice
5.2.3 Kanban Method
Kanban is a scheduling method developed by Toyota engineer Taiichi Ohno for Lean
production. Designed as a system for scheduling, Kanban facilitates production and inventory
control. Acclaimed for its ability to yield vast quantities of product, Kanban is one of the
foremost methodologies through which work teams can accomplish just-in-time (JIT)
production.
The roots of Kanban date back to the late 1940s, when Toyota was brainstorming ways to
mimic the shelf-stocking methodologies of supermarkets in a factory setting. When a
customer goes to a supply store, for instance, that customer will acquire the items that are
needed.
Today, we have adapted Kanban as a workflow management method designed to help us

visualize our work, maximize efficiency and be agile.
Today, we have adapted Kanban as a workflow management method designed to help us

visualize our work, maximize efficiency and be agile. The best way to visualize our work is
by creating and using a Kanban board. The simplest one may consist of three columns –
“Requested”, “In Progress,” and “Done”. The board serves as a real-time information
repository, highlighting bottlenecks within the system and anything else which might get in
the way of smooth working practices.
The Kanban is focused on getting things done and the most important principles can be
broken down into four basic principles and six practices.
The 4 Core Principles of Kanban are:
 Principle 1: Start With What You Do Now;

 Principle 2: Agree to Pursue Incremental, Evolutionary Change;
 Principle 3: Respect the Current Process, Roles & Responsibilities;
 Principle 4: Encourage Acts of Leadership at All Levels.
The 6 Practices of Kanban are:
 Visualize the Workflow;

 Limit Work in Progress;
 Manage Flow;
 Make Process Policies Explicit;
 Implement Feedback Loops;
 Improve Collaboratively (using models & the scientific method).
Visualizing workflow, setting WIP limits, managing flow, ensuring explicit policies and
collaborative improvement will take your process far beyond you could think. Remember to
organize regular feedback loops and all these pieces together will reveal the true power of
Kanban.
So, Kanban is;

c. Is a system for scheduling inventory control and replacement
d. Kanban method is less prescriptive than some agile approach and thus
less disruptive to begin with as “start where you are”
e. This method is best used in condition like:
i. Flexibility
ii. Focus on continuous delivery
iii. Increased productivity and quality
iv. Increased efficiency
v. Team member focus
vi. Variability in workload
vii. Reduction of waste
5.2.4 Crystal Method
The Crystal methodology is actually a family of smaller agile methodologies such as Crystal
clear, Crystal yellow, Crystal red and etc. This set of agile methodologies is introduced by
Alistair Cockburn who actually participated in writing the Agile manifesto for software
development.
There are 3 main factors that will determine the characteristics of different projects: team
size, system criticality, and project priorities. Projects are categorized depending on the
system criticality as there are four levels of criticality: Comfort (C), Discretionary Money
(D), Essential Money (E), and Life (L).
The maximum number of people that need to be involved in a project depends on the size of
the project. Bigger projects, more people. The number of team roles also depends on the
project’s size. If the project is huge there are many different roles and vice versa.
Additionally, these agile methodologies are focused on:
1. Interaction
2. People
3. Community
4. Skills
5. Communications
6. Talents
Like most of the other agile methodologies, Crystal preaches early delivery of working
software, frequency, less bureaucracy and high involvement of users. The Crystal family
suggests that each project is unique and requires the application of different processes,
practices, and policies. This is why it is perceived as one of the most lightweight agile
methodologies.
5.2.5 Scrum Ban , Feature Driven Development:
Scrum Ban is an agile approach from scrum to kanban
Feature driven development consists of six primary role with development:
1. Project Manager
2. Chief Architect
3. Development Manager
4. Chief Programmer
5. Class Owner
6. Domain Expert
5.2.6 Dynamic System Development Method

It is known as constraint delivery method
Eight principle:
1. Focus on business needs
2. Delivery on time
3. Collaborate
4. Never compromise in quality
5. Build incremental foundation
6. Develop iteratively
7. Communicate continuously
8. Demonstrate control
Agile Unified Process
Iterative cycle around seven disciplines
More accelerated cycle and less weight process
Summary
 The Agile methodologies share much of the same overarching philosophy, as well as
many of the same characteristics and practices. From an implementation standpoint,
however, each has its own unique mix of practices, terminology, and tactics.
 The most widely-used Agile methodologies include: Agile Scrum Methodology, Lean
Software Development, Kanban, Extreme Programming (XP), Crystal, Dynamic
Systems Development Method (DSDM), Feature Driven Development (FDD.
Keywords
 Daily Scrum: A daily inspect-and-adapt event conducted by Scrum Development

Teams, in which they re-plan their progress towards their Sprint Goal.
 Kaizen: Improvement, usually taken to mean improvement in a gradual sense by
means of empiricism, transparency, inspection, and adaptation.
 Kanban: A closed economy of production in which work in progress is represented
by a finite number of tokens, and the delivery of value is optimised by inspection,
adaptation, and the ongoing reduction of waste.
1. Explain the significance of various Agile methodologies.
2. Implementing SCRUM offers a mix of benefits and disadvantages. Explain!
3. Differentiate between the roles of Scrum Master and Scrum Team
4. Write a short note on eXtreme Programming
5. Enlist the Core Principles of Kanban. When the method is best used?
6. What do you understand by crystal method?
References
Agile, Kanban Resources, Lean Product Development, Lean/Agile, Resources and tagged
agile, kanban, lean, scrum by Pavel Naydenov.
Guide.pdf#zoom=100
Issue 85.
Case Study: 1
This case study was conducted to evaluate Agile adoption on a project that has to update an
obsolete enterprise data warehouse. The team members have never collaborated with each
other, and the project was their first Agile experience.
The project used the Scrum process to implement Agile. The data gathered on this case study
originates from three focus groups, each of whose conversations were recorded, scribed and
analysed. Though there were various conclusions, the main findings indicate that the Agile
method requires meticulous and thorough planning prior to the transition.
Findings
There was a mixed evaluation of the experience. Participants mainly raised issues regarding
the lack of planning in the implementation of the Scrum process. They praised the
collaborative and dynamic aspects of the process.
Negative Feedback
1. The big picture: Most participants felt that the big picture was missing. Even though
the project had a business case, project scope document and a project plan, the project
team seemingly couldn't visualise the destination and the final product. The Scrum
process didn't advocate the business vision behind the project and how the project fit
within the enterprise strategy. The big picture was not defined upfront. It was
assumed that it was known, and it would be constructed and polished as the process
progressed.
2. Even though the product backlog was built, socialised with the team and stakeholders,
and approved, the team claimed that the itemised nature of the deliverable was too
detailed and too soon in the process. Participants preferred to invest time in defining
goals and requirements before diving into an itemised level of deliverables. One
participant stated, You can easily get caught up in the details and miss the big picture.
3. Lack of documentation: Participants stated the issue of insufficient documentation
as they felt they were missing crucial knowledge. In an Agile process, due to
continuous collaboration between team members, requirements can crop up at any
time during the process. Examining samples of the project's user story shows that the
style of the user story was not adaptable to business intelligence requirements. To
overcome that limitation, team members exchanged information verbally and via
email.
3. Lack of planning: Not enough planning was a consensus amongst the project team.
The team referred to the adoption of Agile as not planned and not thoroughly thought
out. The team felt they were not prepared for Agile. During the focus group,
participants occasionally referred to their previous phased approach as a reference
point.
Positive Feedback
Some aspects of the experience were praised and appreciated by the team.
1. Team spirit: Participants found that using the Scrum process brought them closer,
made them aware of each other's thinking processes and helped build team spirit.
They felt the method facilitated knowledge sharing.
2. Dynamic: Most of the participants also found the process to be very vibrant and
dynamic. The process energised the team, and all team members felt they had a voice.
Lessons Learned
What can be gauged from this case study is that in order for the Agile process to be effective,
the following is required:
 The transition to Agile must be planned thoroughly
 Agility must be introduced iteratively - a single-jump transition to Agile is a recipe for

failure
 A plan for change and education must be put in place to prepare the team for Agile
 A warm introduction of Agile through a change management plan is necessary
 Continuous feedback and improvement of the Agile implementation are needed

Engagement and collaboration are the foundation of the Agile platform. However, Agile is a
generic framework. Its adaptation is not an easy process. Additionally, projects and
organisations frequently fail to define Agile adoption benefits prior to the transition.
In contrast to the simplistic and partial views undertaken by organisations, Agile adoption is
influenced by a number of factors. Most of these factors arise as a direct result of the nature
of the organisation. Thus, self-knowledge is critical when making an organisational process
change.
A pre-evaluation of Agile suitability must be conducted to ensure it is a right choice prior to

implementation. In such an evaluation, various parameters must also be considered and
acknowledged prior to the transition to Agile:
1. Cultural fit: Much depends upon whether Agile can be implemented successfully in
a given organisational culture. Agile is certainly not a cure-all remedy, and
organisations with compatible cultures can achieve benefits to a sizeable degree.
However, when Agile is a miss-match, it becomes a cultural shift rather than a simple
process adoption.
2. Project execution maturity: How good are your team at delivering? Delivery is a
culture and a process. Changing the process won't necessarily make you good at
delivering. Process maturity is a state of robustly defined, inter-related processes that
lead to consistent results and output with the least deviation. Understanding the
maturity level facilitates project execution as the project implementation strategy can
then be adapted to a particular level of maturity.
3. Expectations: The framework lays out a set of principals but does not define benefits.
It's an organisation's responsibility to define what it is expecting from Agile.
4. People: Stakeholders across all concerned divisions need to participate in the decision
to adopt Agile. Educational enhancement activities can allow for better organisation-
wide comprehension of this process.
5. Distributed environment: If the team is geographically distributed, Agile could be a
challenge since the Agile concept is built around a team being co-located. Thus,
distributed Agile implementation is challenging, and the constraint of being
distributed may impact the process.
Agility is not a one-dimensional concept. Organisations tend to have deep-rooted methods of

project execution, and the present degree of agility needs to be accounted for before
switching to Agile.
The management of the transition from the current style of project execution to Agile affects
the large-scale realisation of Agile benefits. This transition needs to be gradual and well-
managed rather than abrupt and sudden. A warm introduction to Agile through a change of
management plan can facilitate the overall transition.
Ultimately, Agile is a difficult-to-master concept. Rolling out a process does not necessarily
mean the end of the journey. The process maturity level is enhanced by the implementation of
a process improvement capability that supports projects and promotes the key concepts and
practices of the methodology - helping to ensure Agile adoption is a success.
Case Study: 2
Agile methodology
Agile software development refers to a group of software development methodologies that

promote the development of iterations, open collaborations, and process adaptability
throughout the life-cycle of the project. It chooses to do things in small increments, with
minimal planning, rather than plan at length. This helps to minimize the overall risk, and
allows the project to adapt changes more quickly. There is also an emphasis on stakeholder
involvement.
Any agile software process is characterized in a manner that addresses three key assumptions
about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist and which
will change. It is equally difficult to predict how customer priorities will change as a
project proceeds.
1. For many types of software, design and construction are interleaved.
2. Analysis, design, construction, and testing are not as predictable as we might like.
An agile process, therefore, must be adaptable.
In this case study we are involving women from different categories of society from
different areas of Andhra Pradesh. They specified a bulk of requirements which they
are in need regularly like Legal issues, Medical issues, Educational issues, Recipes
and Government schemes. For identifying the sources to get the information they
need to spend a lot of time away from home. So, we searched a number of web
Applications which will be providing the information related to these requirements
but no application is there to serve for all the needs. For this purpose we are going to
develop the proposed application to satisfy all these requirements.
After the collaborative communication with the customer we have collected the
following things. They need
 To know the Legal Matters related to Women.
 Different University Notification in a single point access.
 Expert lectures and study material
 To have the information related to the precautions and preventions of various
diseases and likes to have suggestions from the Medical practitioners.
 To know the information related to local, national and international recipes.
 Government Schemes related to women.
a) Legal issues We had collected the information related to legal matters from
Lawyers, Police department and different social organizations.
b) Educational issues Gathering the notifications and proceedings information from
different university websites regularly and updating the related data in our application.
Collecting the study materials and expert lectures related to different domains.
c) Medical issues By having communication with Medical Practitioners we are going

to collect the area wise information related to various diseases, their precautions and
prevention measures.
d) Recipes Collecting the information related to different recipes from websites and
expert chefs.
e) Government Schemes Here the source of information is from www.aponline.gov

and related government sites.
III. Analysis At first we are going to consider the development of this case study by using
XP. In this phase we are concentrating on the requirements of users called stories, consists of
the features and functionalities and these will be placed on index cards. Customers specify
the values for these requirements called Priorities. Depending on the priorities specified by
the customers releases will be done. For this case study the priorities specified by the
customer are represented by the figure
No story should take more than three weeks for the development. If it takes it should be
splitted into small stories. The cost and time scheduling must be done again for these. New
story can be written at any time. Grouping of the stories will be done for the releases. The
releases for this case study are represented by the figure, which is totally depending on the
priorities specified by the customer.
a) CRC cards
As per the system Architecture the following are the classes

• In Legal issues Complaint registration, Complaint status, Advices from Advocates and
Helping Hands. The classes Complaint registration, Complaint status have the internal
relationships.
• In Educational Issues courses, E-Sources, Notifications and Empowering girls are the
individual functionalities no interdependency between the classes.
• In Medical issues Home & Health, Health A-Z, Drugs & Supplements ,Healthy living,
Eating & Diet, Parenting & Pregnancy and Teen Health no interoperability between the
functionality.
• In Recipes there are two functionalities Add Recipes and Download.
• In Government schemes we are going to post the information related to government

schemes. As this is the web application this can be viewed by number of user, according to
their feedback the developers has to modify. If we follow the traditional processes it may
disturb the flow of the system.
b) MVC Design pattern
The model view controller (MVC) design pattern which can weaken the coupling
among the different application tiers and make the development and maintenance
simpler. The MVC is a fundamental design pattern for the separation between user
interface logic and business logic. Since applications are very large in size these days
and the MVC design pattern can weak the coupling among the different application
tiers of application
One way to separate concerns in a software application is to use Model-View-Controller

(MVC) architecture.
 The Model represents the business or database code
 The View represents the page design code
 The Controller represents the navigational code
Acceptance testing
Acceptance Testing is performed after System Testing and before making the system
available for actual use
• Internal Acceptance Testing (Also known as Alpha Testing) is performed by members of

the organization that developed the software but who are not directly involved in the project
(Development or Testing).Here we are involving the analyst and designer.
• External Acceptance Testing is performed by people who are not employees of the
organization that developed the software. selected 50 members of women from different
categories of the society. Depending on the priority chart releases will be done. After Release
#1 the team computes project velocity in turn used to estimate delivery dates and schedule for
subsequent releases and determine whether an over-commitment exists or not.
 Customer Acceptance Testing is performed by the customers of the organization that

developed the software. They are the ones who asked the organization to develop the
software for them. This is the project for social benefit so no specific customer is
there here we are involving the Doctors, Lawyers and members of social
organizations who shared their knowledge to start the process. [This is in the case of
the software not being owned by the organization that developed it.]
 User Acceptance Testing (Also known as Beta Testing) is performed by the end users
of the software. They can be the customers themselves or the customers’ customers.
To perform this task we
Scrum
SCRUM incorporates the following framework activities.

• Requirements
• Analysis
• Design
• Evolution and Delivery
Each framework activity will have work task occur within a process pattern called a sprint, is
defined and often modify in real time by the scrum team. Scrum emphasizes the use of set of
software process pattern that were proven effective for project with tight timely ness
changing requirements and business criticality.
In Scrum, the entire framework activities categorized into three phases:

 Pregame
 Game
 Postgame
Pregame consist of two important activities
1. Planning: Definition of a new release based on currently known backlog, along with
an estimate of its schedule and cost. If a new system is being developed, this phase
consists of both conceptualization and analysis. If an existing system is being
enhanced, this phase consists of limited analysis.
Backlog -A prioritized list of project requirements or features that provide business

values for the customer. The product manager assesses the backlogs and updates
priorities as required. In this case study the prioritized list is common for XP and
Scrum. The requirements already specified above for XP.
2. Architecture: The architecture of scrum deals with the development of design which
specifies the process patterns of work units called sprints.
Sprints – consist of work unit that are required to achieve a requirement defined in the
backlog that must be fit in to a predefined time-box (Typically 30 days).During the
sprint, the work units addresses are frozen and allotted to team members to work in
stable environment.
Game
Game phase includes in the development activities. Development Sprints:

Development of new release functionality, with constant respect to the variables of
time, requirements, quality, cost, and competition. Interaction with these variables
defines the end of this phase. There are multiple, iterative development sprints, or
cycles, that are used to evolve the system.
Postgame
Closure: Preparation for release, including final documentation, pre-release staged
testing, and release. Scrum meetings - are short (typically 15 minutes). Meetings held
daily by the scrum teams. Three questions are asked and answer by the all team
members.
 What did you do since the last team meeting?
 What obstacles are you encountering?
 What do you plan to accomplish by the next team meeting?
These daily meetings help the team to uncover potential problems as early as possible
and lead to knowledge socialization and there by promote a self organizing team
structure. Depending on the work unit size the designing of the sprint is done and
what are the test case studies to be invoked is going to be identified. Demos – deliver
the software increment to the customer so that functionality that has been
implemented can be demonstrated and evaluated by the customer. It is not
compulsory that all functionalities must be covered but they must be delivered within
the time box. Scrum process patterns enable a software development team to work
successfully in a world where the elimination of uncertainty is impossible.
Conclusion
In agile development process by using XP methodology, the stories can be divided in

two number of small depending on the time factor (if a story exceeds 3 week s for the
development that can be divided in to small stories). So in XP the changes can be
allowed in the middle of the development. For example, in this case study if we
consider the legal issues, adding of another new requirement related to complaint like
cybercrime will cause some change in the development which is going to have effect
on the size of the story which already have been specified. These types of changes can
be acceptable in XP.
In Scrum once the sprints are identified and allotted to the team members they must
be stable because they are frozen. No modifications are allowed until the completion
of the development of that sprint. Adding of new sprints in the middle of the
development is not possible. In XP team size should not exceed10 members, and it is
limited to 7 in scrum. XP will not support the distributed development, scrum will
support.
Case Study 3
ABSTRACT
In the microprocessor industry, the product development engineering (PDE) group exists to
provide the test collateral to support cost-effective device screening and classification.
Squeezed between the actual design teams and factory manufacturing teams, PDE is often put
under tremendous pressure without ultimate control of team level deadline, scope,
requirements, or deliverables.
To better coordinate the efforts of the sub-teams within PDE, seven teams comprising
approximately 50 people volunteered to pilot a more integrated approach to product
development.
To organize this integration, the management decided that Scrum was the best project
management framework to employ along with agile engineering best practices. This case
study describes the journey taken by the organization, its lessons learned, and the results of
its investment in Scrum.
INTRODUCTION
In the software engineering world of agile and Scrum implementation, a plethora of best
practices exist. Many of these involve small or medium-sized organizations using small
teams, developing software in object-oriented languages. The Oregon and Pacific (OAP)
PDE team is a large organization needing to implement Scrum and agile across multiple
teams, sites, cultures, and environments. The work product is a Test Program which runs on
Automated Test Equipment (ATE). ATE has a proprietary operating system and interface
languages which prevent the organization from using industry standard, off-the-shelf
software validation solutions. In essence, we are working in a proprietary language
environment with no off-the-shelf unit test framework and no offline testing capabilities.
Additionally, team have a long history of requirements thrash, over-committing, missed

schedules, insane work weeks, poor morale, and high turnover rates. A long history in
fabrication and manufacturing has resulted in a strong waterfall culture at Intel, embraced
widely as the best path to success. Teams are organized in functional “silos” with regularly
scheduled hand-offs of deliverables to other functional silo teams. The result is that some
teams carry an unusual burden at late phases in the lifecycle and had very high turnover at the
end of a project. Finally, each team is comprised of domain experts whose skills seldom
overlap with those of their team members. It is therefore difficult to impossible to pair on
tasks or share responsibility within a team.
Despite all of these challenges, team wanted to move ahead with a different way of managing
and organizing projects to better unite test teams and smooth out the delivery of our work
product. Company chose to introduce Scrum to the organization at the outset of a project,
when most of the work was development of pre-silicon infrastructure and readiness work. If
team could get Scrum to work during this first phase, team felt the best practices learned in
this relatively calm period of the project would find their way into the more stressful
execution phase — when daily work is dependent on the health of actual silicon, dynamic
external business conditions, and the requirements of the Fabrication, Design, and
Manufacturing customers.
PHASE 1: PREPARING FOR SILICON

The initial transition group included six teams and numerous sub-teams. As a first step, team
retained Danube Technologies, Inc. as a Scrum education and coaching vendor.
Approximately 20 group leads and technical leads attended a two-day Certified ScrumMaster
training course as an intense introduction to Scrum principles and practices. Unfortunately,
three senior managers missed the training and this resulted in subsequent impediments
throughout the transition process. Executive sponsorship was critical to our success. Having
our three most senior leaders absent from the initial training led to gaps in their knowledge of
the changes team were trying to make. After the training, participants attended a retrospective
meeting and discussed, without Danube representatives present, their thoughts, reservations,
and commitment level to a Scrum approach to project management. The team leaders agreed
to commit to three months of implementing Scrum principles and practices “by the book”
prior to questioning the effectiveness of the new process or attempting to tailor it to Intel
needs. A Process Action Team (PAT) was formed to monitor the development of Scrum
within the pilot teams and to provide support for process questions. Even though agreement
was there, I could already sense a split in the organization into “pigs” and “chickens” in terms
of supporting Scrum.
Group and team lead functioned as the Product Owners for all seven teams, while I worked as
the ScrumMaster. I felt strongly that Scrum was an important framework to implement within
these teams and I was willing to take the risk to champion it. Although the result of taking
this risk was positive, I nearly didn’t survive a full quarter of Scrum Mastering seven teams!
Working with Danube consultants Michael James and Dan Rawsthorne, team determined that
having volunteer Scrum Masters would be important to each team’s success and to their own
sanity. First, team worked with Intel management to make sure that the role of ScrumMaster
was valued in the performance appraisal system as “real engineering work,” rather than
administrative overhead. Secondly, those who stepped up to take ScrumMaster roles did so
on teams in which they did not have a technical stake. This helped prevent any conflicts of
interest between their own technical projects and their facilitation responsibilities. Budget did
not exist for Scrum Masters to give up their own engineering work in favour of ScrumMaster
work. However, support was lent for a lighter change in product role for those who stepped
up to shepherd the process in ScrumMaster positions.
At the end of three months, there were three additional Scrum Masters to manage seven
teams. Additionally, an eighth team had volunteered to start using Scrum. After
approximately five months, scaling work across the Scrum teams became one of the largest
challenges. Prior to adding the additional five teams that were formed throughout the
remainder of the year, the organization needed more knowledge on how to manage the
dependencies between multiple teams and facilitate better inter team communication. Danube
was again retained to develop a customized Scrum scaling course for some of the original
participants of the Certified ScrumMaster course along with the senior managers who missed
the first class. This day-long training reviewed major principles of release planning, sprint
planning, and, in particular, scaling across multiple teams. Company again took the “learn,
try, inspect, and adapt” approach to this scaling.
After learning a few “best practices” for scaling, team took the issue back to the teams to try
one of the scaling models from class and then tailored the approach to the teams’ real world
environments. After adding some roles to handle technical dependencies and more layers of
organization, the group was able to scale to 12 Scrum teams, each containing approximately
five to nine developers, within a year.
Two of the primary aspects of successful organizational transitions that team discussed with
the Danube consultants were volunteerism and self-organization. Although teams who
committed to a three-month trial period of “by-the-book Scrum” were asked to adhere to the
core principles and practices, adoption was clearly more important than adherence. A “please
just try it” attitude from management resulted in better buy-in from teams. After the three-
month trial, teams were given the freedom to organize themselves and inspect and adapt their
approach every sprint. Although the teams needed to work together, they were given as much
freedom as possible to determine what would work for them. Deviations were discussed, but
not judged in the PAT meeting with all POs and Scrum Masters each week. Our goal at this
stage was unity, not uniformity
Visibility was also crucial to this process. An internal wiki allowed teams to document what
worked for them, what didn’t work well, and suggestions for best practices for Scrum
adoption.
Implementing Scrum “by the book” was an integral part of launching Scrum across the
teams. However, at an organization the size of OAP, it is necessary to conform to certain
organizational structures or requirements. After the three-month pilot period, some
modifications were made to fit Scrum into our culture and environment. First, the team had to
define which roles were most useful to their goals. Company developed the following role
descriptions:
Business Owners: Senior managers or principal engineers charged with oversight of multiple
teams or overarching technical issues for all teams. BOs set the roadmap milestones (Release
Plan) and defined the ‘desired’ features at each milestone. Scrum teams still owned sizing
and committing to meet the feature milestones based on their velocity.
Product Owners: Typically, functional group managers
Technical Owners: Technical leads from each of the functional areas who could collaborate
on integration, dependency, and architectural issues to ensure congruence between teams
with dependent outputs. TOs held ad hoc meetings to break down epics into sprint-able
stories.
Scrum Masters: A cross-team engineer with no specific stake in the project team he or she
was Scrum Mastering. This helped to curb the urge for the ScrumMaster to meddle in the
technical solution.
Teams: Team charged with one output of the test suite, rarely with cross-functional team
members. Almost always a functional silo team.
Transient: Group members with highly specialized skill sets needed by multiple teams for
only a sprint or two at a time. They came and went at sprint boundaries.
Conduit: Team member who represents more than one person including contractor
supervisors or local members of a remote team. Conduits can sign up for many more story
points of work than a normal team member.
Story Owners: A technical expert with knowledge of how to complete a story who can
develop tasks and request the participation of certain team members in completing those
tasks. The one person you can go to and ask, “What’s the status of this story?” and get the
right answer from, every time.
Finally, during this phase of product development, the overall group of Scrum teams was
essentially its own customer. Company were only building infrastructure to support silicon
debug and manufacturing. There was no outside force requesting certain features during the
first year or so of the project. This made business value a difficult metric for prioritization.
Therefore, the POs and BOs tried to prioritize features with a combination of estimated
business value and general priority, mostly as a dependency management strategy.
By the end of the first year, Scrum had taken root within the organization and become the
default framework for planning our work and managing our requirements. The PAT had a
wealth of data on which “tailorings” were and were not working. Silicon loomed on the
horizon. Would the process hold up under real business pressure or would it get thrown out
the window in favor of doing it the “old” way?
PHASE 2: SURVIVING SILICON

First silicon is a tough time to be a product development engineer. If you mapped it on the
Stacey Diagram, it would be the most upper-right pixel in the chaos space! When silicon
arrives, all requirements are ambiguous, and it takes a few weeks to collect the necessary data
on the silicon devices to determine the path the project will take.
I decided to step back and “inspect and adapt” my organization’s approach to Scrum based on
what I saw happen at first silicon. What I saw really surprised me. I had one Scrum team that
reverted to its old habits. A few other Scrums decided that they were done at fist silicon and
disbanded gracefully. The rest clung to Scrum like a drowning man to a life preserver.
Our two-week sprints were impossible to maintain in this environment and most Scrum teams
went to one-day sprints instead. They would meet for one hour every day to plan the next 24
hours and review and reflect on the previous. Scrum’s four meetings collapsed under the
gravity of first silicon into a single meeting. However, when I attended these meetings, I saw
that Scrum’s core behaviors — such as business value based prioritization, team sizing, not
working outside the backlog, peer updates and swarming, implementing process
improvements and reviewing the work product — were all happening, just on a much
smaller, faster scale as knowledge of the device was growing.
In the daily debug meeting, where all of the organization’s leaders and managers were in
attendance, I would hear any ad hoc request being made followed by a PO saying, “Is there a
story in the backlog for that?” I also saw many examples in which developers would grab a
stakeholder or PO and drag them to the test equipment to witness that the content being added
to their program met their acceptance criteria.
This period of intense debug and development went on for a few weeks. At the end of that
time, the surviving Scrums emerged intact and expanded their sprints back to two weeks, like
an accordion. The change was announced in the Friday Debug meeting, occurred over the
weekend, and the two-week sprints remain in effect today
PHASE 3: PREPARING FOR MANUFACTURING

As the silicon became healthier and we prepared for the manufacturing ramp, I noticed that
the functional silo Scrums were being strained by handoffs in the post silicon environment. A
handoff occurs whenever responsibility, knowledge, action, and feedback are separated
(Ward):
 One person decides what to do (responsibility);

• Another person defines how it will be done (knowledge);
• A third person implements it (action); and
• A fourth person validates the work (feedback).
Additionally, Conway’s Law states that organizations which design systems are constrained
to produce designs which are copies of the communication structures of these organizations
(Conway). I knew that cross-functional teams were part of “bythe-book” Scrum and I felt that
they would solve this particular impediment, but had not found a workable solution for
forming them within the organization.
During this time, I noticed a number of Task Forces being formed to deal with silicon content
issues. At Intel, a Task Force is a cross-functional team that is formed in response to a crisis.
If you are tapped to join a task force, it’s because you are an expert. You are immediately
responsible for the success of the Task Force, you drop whatever else you are doing, and you
can’t say no. I couldn’t see how to get the crossfunctional benefit of the Task Force without
changing the organization’s structure.
I had coincidentally scheduled some Lean Product Development Training with Mary and
Tom Poppendieck for the team in this timeframe and the Lean training revealed an important
clue in how to use Scrum effectively in this phase:
Keep Functional Teams: These are useful organizational structures as knowledge and deep
technical expertise live here. They also give Scrum team members a place to “come home to”
between projects.
Create Cross-functional “Feature” Scrums: Functional teams loan responsible experts to
cross-functional feature Scrum teams. Crossfunctional Scrum team members are 100 percent
dedicated and are not influenced by their functional managers during the sprint.
When I heard this, it really resonated with me. A cross-functional Scrum is a Task Force
without the crisis!
Company ran a quick pilot on one content type and the team members loved it. The handoffs
had been greatly reduced. Team members were able to swarm on problems. Communication
and knowledge flowed smoothly. And if a particular team member’s function wasn’t needed
in a sprint, they paired up with another team member to cross-train and help where they
could.
Once again, timing was everything. This cross-functional pilot data rolled in just in time for
our annual offsite leadership meeting. This was a huge opportunity to influence the
organization’s leadership and make a course correction that would allow Scrum to function
even better than before. I presented my observations and the early data from the single cross-
functional pilot and the organization was sold. In fact, all of the naysayers, as well as the
undecided portion of the organization, signed on to the cross-functional Scrum concept. This
added five new Scrums to our process, bringing our total impact up to 18 Scrums over two
years!
RETROSPECTIVE: I’ve used a simple (+) and (-) scheme to indicate what went well and
what didn’t.
Strong Definition of Done (+) Since team don’t have a ‘real’ programming language, team
don’t have a unit test framework or an offline regression. In microprocessor product
development, unit testing means testing silicon units! This led us to focus on writing good
stories and, most importantly, writing good acceptance criteria. Acceptance criteria (AC)
provides a strong definition of done by detailing the requirements for customer satisfaction.
Company also implemented a lightweight verification process that team called the “Pair
Review.” To complete a story, the developer and PO or stakeholder must sit together and
agree that the AC have been met. Company collected simple metrics on this activity in the
form of Adds, Saves, and Escapes.
Adds are additional AC that the SH/PO add to the story during the Pair Review process that
are accepted by the developer for the current sprint and are an indication of ambiguous story
AC. Saves are bugs created in this sprint and caught in this sprint. Escapes are bugs created in
a previous sprint and found in the current sprint. Saves indicate the verification process is
working, while Escapes indicate that it needs to improve.
Additionally, team had to define a robust validation process. Validation couldn’t be

generalized across the Scrums like verification, so each Scrum documented its validation
rules, essentially defining what it means to be done with validation for its work product.
Validation must ensure the story will function properly in the released work product and
usually involves running devices on the test equipment.
A story is only done if all tasks are done and it has been verified and validated.
No Partial Credit (+) When determining velocity for the next sprint, no credit is given for
stories that are not “done” based on our definition above. This may seem draconian, but was
necessary to force the team to pay attention to the verification and validation requirements
and make sure their estimates include these steps. It also forces the team to pay attention to its
commitments. If you committed to 100 percent done and you delivered 90 percent, you
failed.
Nine-day Sprints (+) Company sprint for nine days and hold Review, Retrospective, and
Planning Meetings every other Friday. This way the team is always outside of a sprint every
other weekend. This greatly helped improve the quality of life and morale of the Scrum
teams. Conversely, every other weekend was in the middle of the Sprint and team members
could decide amongst themselves if they needed to work the weekend to meet their goals.
This happened rarely after the first six months and compnay have achieved a repeatable
cadence and a sustainable pace.
Cadence (+) The nine-day sprint cadence allowed POs, BOs and teams to change direction as
necessary, at frequent intervals. This cadence actually helped reduce the requirements thrash
that team had seen on previous projects and high-level managers began to see that the team
was able to produce real work product every other Friday. Data team collected showed that
10 to 20 percent velocity was lost when a sprint was significantly interrupted. Company
called this the “sprint interrupt tax.” Ten percent of velocity was lost if the interruption came
in the first week of the sprint and 20 percent if it came in the second week. Managers were
made aware of this statistic. They began to respect the cadence of the planning cycles.
Company also added a rule that any change to an active sprint forces a renegotiation of
scope. Again, management responded and when interruptions were needed, they usually
came prepared to swap out items from the sprint backlog
PO on the Team (-) As a means of facilitating better communication between Product

Owners and the team, team allowed Product Owners to serve as participating members of
each team. In some cases, it worked quite well, but in others, POs micromanaged the teams,
dictating day-to-day tasks, and impeding honest communication between team members. This
has led to teams holding secret meetings to discuss real organizational impediments out of the
view of their PO/functional manager. Although these situations appear to be resolving over
time, they have crippled the team’s ability to self-organize. When team built the cross-
functional Scrums, team disallowed this practice.
Central Scrum Tooling (+) Scrum requires bookkeeping to generate useful metrics, like the
burn down chart, every day. This is especially true when running multiple Scrums or Scrum-
of-Scrums in your organization. Having a central, open-access tool contributed greatly to the
success of the transition. When team started journey, couldn’t find tooling to support the
Scrum- of-Scrums, so team created their own. Company started with XPlanner and
customized it significantly with Java and SOAP into something team called “XPlanner2.”
Based on those learnings, team created a custom Windows application. This central tool has
been a key enabler for managing multiple teams. While I believe that you must have tooling
to enable and facilitate large-scale Scrum, the available offthe-shelf offerings have matured to
the point which I probably wouldn’t take this homegrown approach again.
Huge Backlogs (-) Managing an “all access backlog” is also a challenge. If anyone, at any
time, can add anything to a team’s backlog, it can feel like the team is being bombarded with
requests. Some POs wanted to lock down their backlogs which don’t allow for input from
other team members or stakeholders. Our tool for Scrum puts “new” stories in a different pile
than “accepted” Stories. The PO can then review each new story, discuss with stakeholders,
and decompose the story appropriately. Company also implemented a “freezer” for stories
that team knew team wouldn’t get to for a few sprints. Stakeholders could see that their
requests were in the freezer and the main backlog was only three to five sprints deep.
Story Points (+) Since most teams didn’t have a common frame of reference, most Scrums
used ideal days. Relative size is better, but harder to get in most of my Scrums. Company had
to watch our use of the word “days” when talking with upper-level managers unfamiliar with
Scrum. Company quickly moved to talking about “points” when reviewing data with
outsiders.
Tasks Take Less than a Day (+) Throwing hour estimations out the window was liberating
for the teams and managers. Stories are assigned a degree of “difficulty” in story points and
tasks are simply items that are binary – either done or not done. A task is always less than a
day, so if a person is working on a task for more than a day, team know they’re probably
impeded.
Burndown Observations in the Daily Scrum (+) Metrics and visual representations of
status were also vitally important to success to date. A visible sprint burndown chart proved
effective in warning teams if they’re falling behind and has prompted conversations with POs
about status, prior to the end of a sprint. The ScrumMaster brought in the burndown chart
every day. As a result, no one walks into a review meeting shocked that something did or did
not get accomplished
Incremental Review (+) Company didn’t like waiting until the Review meeting to seek
approval from the PO. Our Pair-Review verification process encouraged the PO and
developer to sit together as soon a story was deemed ready for verification. This eliminated
most of the surprises in the Review meeting where the final work product was reviewed. It
also made for a much shorter meeting.
Velocity (+) Visibility of backlog, progress reports, and overall metrics help adjust manager
expectations frequently so they can make business decisions based on the actual
accomplishments of the teams. Velocity metrics force POs to schedule work to capacity.
After all, you can’t get 80 story points out of a 50-point team.
Executive Sponsorship (+)
Support has been a crucial win for both teams and managers. Without high-level support
from the organization’s manager, the transition wouldn’t have been successful. Upper
management provided structural support, incentives for those who took a leadership role on
teams, and gave them career credit for their contributions. Leadership also provided
disincentives for those who elected to subvert the process. Human impediments were
“repurposed” to ensure success, but team didn’t lose any people in the transition.
Changing Behaviors (+) Finally, behavior is not learned unless it’s practiced. My team has
learned that the practice of Scrum begets better Scrum behavior and results. By consistently
negotiating scope, practicing prioritization, authoring clear requirements, adhering to time
boxes, keeping an eye on the metrics, and aiming for team self-organization, Scrum survives
and thrives two years after taking our first steps.
RESULTS
Scrum has made an impact in four major ways: Cycle Time, Performance to Schedule,
Morale, and Transparency.
Reduced Cycle Time

• Scrum was a major contributor to a 66 percent reduction in cycle time.
Performance to Schedule
• Company have established and maintained capacity-based planning and a twoweek

cadence for more than a year.
• Company have virtually eliminated schedule slips and missed commitments.
• Customers and upper management are changing their behaviors to protect the two-week
cadence.
Improved Morale
• Improved communication and job satisfaction.
• What was lowest morale team is now best performing team.
Increased Transparency
• Led to adoption of formal, CMMI style, VER, and VAL standards.
• Scrum has uncovered bugs, impediments, weak tools, and poor engineering habits.
Scrum has been a major contributor to a consistent, repeatable, 66 percent cycle time
reduction in the creation of our work product. While team also underwent some major tooling
improvements, I believe that Scrum contributed on the order of 50 percent of those gains.
The nine-day sprint cadence provides robust schedule predictability. This predictability has
actually led to less thrash in team requirements as management seeks to avoid paying the
interrupt tax. Company simply don’t miss deadlines any more through aggressive
management of priority and scope.
Job satisfaction comes from consistently hitting goals established with velocity-based
planning. The team feels incredible pride in its ability to make and meet commitments.
Morale is much higher, and the sustainable pace is greatly valued in the organization.
Many, many traditional engineering practices and systems are being questioned as Scrum
makes inadequacies more visible. This has led us to invest in additional infrastructure to
allow us to adopt even more agile practices.
SUMMARY
Scrum has served us very well in Product Development Engineering. Word of our success is
spreading across the team and I have been spreading the word on the benefits of Scrum.
Company had many false starts along the way and had to learn a lot of hard lessons.
However, team had strong commitment from our management and a tight cadre of Scrum
believers that kept us coming back to make it better. In the end, I think team have made great
strides at changing our organization from a command-and-control, plan-based organization
into an inspecting and adapting, self-organizing, empirical planning-based organization. I was
teaching an internal “Introduction to Scrum” class and a few members from my organization
were in attendance. Halfway through the class, one of them came up during a break and said,
“It’s funny, but I didn’t know there were rules. This is just the way I work.” Changing
behaviors is a long, hard journey, but worth the effort.

532 Introduction To Agile Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

532 Introduction To Agile Management

Uploaded by

Copyright:

Available Formats

Unit 1

After going through this unit, you will be able to:

You make a list

You size things up

You start executing

You update the plan as you go.

a. You're going fast enough. All is good. Or,

1.3 How Agile is different

Analysis, design, coding, and testing are continuous activities

Scope can vary

Requirements can change

Working software is the primary measure of success

1.4 Agile Myths

Agile is a silver bullet

There's nothing inherently magical about Agile. It basically says

Where Agile pushes back on documentation is as a means of communication. Agile prefers

You've got your:

1. Daily planning with the 10 minute daily standups.

But it wouldn't be fair to say Agile is anti-planning. If anything it is anti-static planning.

The truth is Agile is a very disciplined way of delivering software.

 You have to test.

Agile requires a lot of rework

Agile doesn't scale

Can't handle change

By doing them continuously:

 Quality improves because testing starts from day one.

Because life's too short to write everything down

They are written on index cards to encourage face-to-face communication.

The fine art of expectation guessing

Agile's engine for getting things done

The fine art of expectation setting

# iterations = 100 pts / 10 pts per iteration = 10 iterations

Test Driven Development

 Defines success up front.

2.2 Manifesto for Agile Software Development

2.4 Principles of Agile

2.5 Agile Principles explained

After going through this unit, you will be able to:

Agile development methodology provides opportunities to assess the direction of a project

2.2 Manifesto for Agile Software Development

 Individuals and interactions over processes and tools

 The size of the systems development project and team

Barriers to Agile adoption include an inability to change an organization’s culture, followed

The founder of Scrum (Schwaber& Sutherland, 1995) described Scrum as a process

Three distinct roles are identified within the Scrum methodology:

Scrum is a suitable method to support development process. It is very efficient in creating

2.4 Principles of Agile

Agile software development comprises various approaches to software development under

The Manifesto for Agile Software Development is based on twelve principles:

1. Customer satisfaction by early and continuous delivery of valuable software.

2.5 Agile Principles Explained

2. Welcome changing requirements, even late in development. Agile processes harness

3. Deliver working software frequently, from a couple of weeks to a couple of months,

Documenting conversations, creating email narrative streams, even using collaboration

7. Working software is the primary measure of progress.

9. Continuous attention to technical excellence and good design enhances agility.

1. Continuous Delivery: The automated elevation of increments of release quality into a

Benefits and Advantages of Agile for Project Management

3.2 Benefits of Agile

3.3 Advantages of Agile for Project management

After going through this unit, you will be able to:

 Analyse the Benefits of Agile

3.2 Benefits of Agile