Introduction To Agile Software Development

14/04/2019 Skillsoft Course Transcript
Course Transcript
Introduction to Agile Software Development

Agile Software Development
1. Course Introduction
2. History of Agile Software Development
3. Why Agile?
4. Advantages of Agile
5. Agile Principles
6. Agile Values
7. Agile Best Practices
8. Agile Software Development Life Cycle
9. Agile Information Radiator
10. Agile Methods
11. Agile Management
12. Agile Software Development Considerations
13. Issues Transitioning to Agile
Practice: Agile Principles

1. Exercise: Identify Agile Principles
https://cdnlibrary.skillport.eu/courseware/Content/cca/sd_adev_a01_it_enus/output/html/course_transcript.html 1/23
Course Introduction
Learning Objective
After completing this topic, you should be able to
start the course
1.
[Course title: Introduction to Agile Software Development.] Agile software development is an intuitive,
incremental approach to developing releasing software. Agile principles include commitment to timely
and ongoing software deliveries, changing requirements, simplicity in approach, and sustainable
development cycles. Hi, I am Colin Calnan. [Senior Web Developer.] And, in this course, you will be
introduced to agile software development as well as the principles and values behind the agile
manifesto.
History of Agile Software Development

Learning Objective
describe what Agile software development is and its history
1.
[Topic title: History of Agile Software Development. The presenter is Colin Calnan.] In this video,
we're going to look at an overview of Agile software development and describe what Agile software
development is and its history. So Agile software development is a type of project management. And,
obviously, software development is a broad field. But Agile development, in particular, helps to work
with process improvements within the software development life cycle. It can definitely help with
software development application. And it does that through Agile project management. So a little
history of Agile project management. Agile project management can be traced back to 1957. And that
will give us our rudimentary start to project management. And that was when software developers
were working in developing software for IBM and Motorola. They kind of came up with this idea of a
model of developing software. And they came up with this model to combat an existing model – the
waterfall model – for developing and for project managing software development. Now the waterfall
model had been around and it was the prevailing form of project management at the time. And it is
generally loosely affiliated with the idea of Gantt charts and layouts of tasks that need to be done at
certain points in the project in order for the project to move forward.
So generally the waterfall model did not leave much room for error. And it was pretty heavily micro
managed in order to make sure that the processes and the steps in the waterfall were met correctly.
So it was identified that definitely more flexibility was needed in the software development process
because software developers were kind of at their wit's end in terms of what was happening with this
waterfall model. So some more versatile approaches were introduced in the 1990s. And those
include things like dynamic systems development method – DSDM – XP – extreme programming, the
scrum methodology and feature driven development, which is known as FDD. So those were some of
the lightweight and versatile project management systems or approaches that were brought into
software development in the 90s. And those new approaches that happened in the 90s are all – even
though they existed before Agile – they are now considered to be part of the Agile manifesto. So
what is the Agile manifesto? Well, the Agile manifesto was something that was introduced in 2001.
And, at that time, a number of individuals met to work through a solution to the problems that they
were having.
And it was basically to come up with an alternative software development process and something
different than what had been existing in the world up until that point. So what happened? The
outcome of that meeting of these individuals was this manifesto for Agile software development. And
that manifesto for Agile software development was basically seven pages long and it consisted of
four core concepts. And those concepts were individuals and interactions over process and tools,
working software over comprehensive documentation, customer collaboration over contract
negotiation, and responding to change over following a plan. So those were the concepts that they
came up with to help with improving the software development process. And, since then, there's
obviously been a growth in Agile popularity throughout the world. It's been helping people get stuff
done, get through software development projects quicker, within budget, release cycles are faster,
and so on. And, with that, there has been the growth of what we call the Agile Alliance and the Scrum
Alliance. And these are essentially non profit global organizations that help promote Agile and Scrum
throughout the world to make the software developers lives easier and to help projects be delivered
on time. So that was an introduction to Agile software development and the history of Agile
Manifesto.
Why Agile?
Learning Objective
describe why organizations should introduce Agile
1.
[Topic title: Why Agile? The presenter is Colin Calnan.] In this video, we're going to describe why
organizations should introduce Agile software development. So some of the things that we can look
at when describing why organizations should introduce Agile will be the idea of priorities change. So,
obviously, using Agile with their iteration phases that helps prioritize the highest value features first.
So, when you iterate and you go through prioritizing which work needs to be done in each iteration,
that means that basically at any point in time, most of the work done is of high value so the highest
priority work is done first. As well as that customer focus. So some of the most important lessons
you'll get about your software will come from customers. So Agile teams are able to get software into
the hands of customers pretty quickly by building just enough to fulfill their needs. As well as that,
using Agile helps to increase product quality by ensuring that teams are responsible for maintaining a
high level of quality and also verifying that everything that goes out actually works. So thorough
testing processes, quality assurance, etc. Another reason for using Agile would be to allow you to
maintain competitiveness. Now what do we mean by that? Well, generally, most organizations has
some problems with process.
And then, with Agile, you can help find those problems and fix them and help the teams stay
competitive and help your product stay competitive by being able to iterate and allowing teams to
zero in on problems that are maybe slowing them down or making delivery unreliable. And, as well as
that, your software, your product, your business can cope with what we call the loss of a star. So the
loss of an all-star employee, a crack developer, a great project manager, and so on. And the way
Agile helps with that is that generally teams change, new hires come on, employees move between
projects, etc. But Agile handles that through methods such as things like pair programming, where
developers would pair up with one another and work on a similar computer or work remotely via
terminals. And that helps to distribute the knowledge and the know how throughout the organization
so in the event that one of your star developers leaves, that the knowledge has been transferred
across members. So what are the other areas – so revenue, cost, and risk management. So these
are other areas in which your Agile can benefit your business. So, with revenue – because Agile is
iterative – it means that features are delivered incrementally, which basically means that all of the
benefits of those features are realized early on as the product continues to develop.
So you're rolling out features that are valuable early on, thus generating revenue, rather than in a
waterfall method having to wait right until the end until everything is done to release that. So this
iterative cycle helps with that. So cost control...so obviously the idea of things like fixed time scales
with evolving requirements in a fixed budget can help so that the scope of the product and its
features are variable, rather than the cost. So the cost remains fixed, but the things that are delivered
to that cost and the features that are delivered can change. So that helps keep cost under control
instead of this ever creeping cost. We have to get all of these things done by this time and the cost
keeps going up and up and up. The cost is fixed and the time scales are generally fixed. But there's
scope of what's delivered within that changes depending on how things are going. And then finally,
there's the idea of risk management. So because you're doing small, incremental releases and the
product owner and the product team are there to help identify any issues early on, it makes it easy to
respond to change. Therefore, reducing the risk of things being developed or things being created
that are not what was needed or was wanted or don't suit the purpose or the needs of the application
or the organization. And then some other key benefits of using Agile.
Speed-to-market, obviously this iterative process helps you get your application out there quickly, it's
always in a constant beta state. Visibility and transparency – Agile encourages visibility and
transparency between the client and the software development team so that the client and the
stakeholders can always see what's going on and are aware of the state of the project at any time.
Flexibility and agility – again, with this Agile process, instead of fearing things like scope creep and
the never ending project, which might happen in something like a waterfall. With Agile, the time scale
is fixed and then the requirements and the features are modified in order to fit that – so there's some
flexibility there. Business engagement, so obviously, through the product owner or the user
representative, there's a high visibility of the product and the progress. And flexibility is there when
change is needed. And that creates much better business engagement and customer satisfaction. So
the introduction of a user representative, a product owner on the product side can help engage with
the businesses and customer satisfaction.
As well as that, we're building the right product. So one of the ability of Agile development
requirements is the ability to embrace change. And, by doing that, it makes it possible to embrace
changes and to pivot. If things are not going as they should or changes needed to be made, you end
up building the right product for the customer using Agile. So those are some of the reasons why
organizations should introduce Agile software development.
Advantages of Agile
Learning Objective
identify the advantages of Agile over the waterfall approach
1.
[Topic title: Advantages of Agile. The presenter is Colin Calnan.] In this video, we're going to identify
the advantages of Agile over the waterfall model. So let's first have a look at the shortcomings of the
waterfall model. What are some of the shortcomings? Well, first is it's difficult to make changes using
the waterfall model. Documentation is made early on and the project moves on from there. So
making changes is more difficult because all of that stuff has been set at the beginning. Working
software is produced late into the cycle. So it's a step-by-step process – a stage-by-stage process.
And it's not until later on in those stages that any actual working software gets produced. There's also
great risk and uncertainty because it's impossible to predict risk on a long timeline at the beginning
so that generates this uncertainty. It's also not ideal for long duration projects. Because again, as the
project grows over time, that risk and uncertainty grows as well as that software gets produced later
and later in the model. As well as that, it's not suitable for regular requirements changes. The
requirements are set in waterfall at the beginning, they're documented. It's a whole phase of
documentation and requirements.
And then off you go with your software development so regular requirements changes are not
suitable. And it's also not suitable for complex object-oriented projects where there's a lot of
interaction between elements that may need to be revisited as the project moves forward. So let's
have a look at the advantages and disadvantages of Agile versus waterfall. One of those is customer
availability. With Agile, it prefers the customer to be available throughout the project for discussions.
Whereas, in waterfall, they get involved at milestones. Scope – so Agile welcomes changes and then
the changes come at some sort of cost through other features. Whereas waterfall works well when
scope is known in advance or when contract terms limit changes. So the scope is very much set in
waterfall. Feature prioritization – so in Agile, priority is generally organized by what are the most
valuable features? And those are implemented first, kind of, reducing the risk that the product that's
produced is unusable. Or if, for example, funding runs out and there's no money left, at least the
features have been prioritized so that the most important ones are done first. In waterfall, basically
it's a kind of do everything we agreed on approach and they get an all or nothing.
So that kind of increases the risk of failure. In terms of teams, Agile prefers like smaller dedicated
teams that are highly coordinated and they're synchronized. Whereas, in waterfall, there is team
coordination but synchronization between those teams is kind of limited to these handoff points
instead of there being a constant sync. Funding – so Agile works really well for time and materials or
other kind of non fixed funding. Waterfall reduces risk in fixed price contracts by getting an
agreement up front in terms of what should be delivered. And then feasibility. So Agile is better where
it's feasible. So it depends on the project and the situation. But Agile, if it's feasible, is definitely
better. The idea of waterfall may reduce risk depending on certain constraints in the contract. But
generally, it's preferred to go with Agile. So what are some of the strengths of Agile over waterfall?
Well, there's this non linear approach. This iterization approach and constant delivery. Early customer
involvement – so the customer gets to see the product that they're looking for early on.
There's this customer sense of ownership. So the constant communication involving them in
conversations about it helps them feel a sense of ownership. As well as that, there's time to market.
So this quick iteration means that you have a working piece of software out the door as quickly as
possible. And then finally, you've got user-focused development. So, if you're iterating quickly, you
can be checking the feedback from your customers or your users and making sure that your
development is focused on their needs solely. So those are some of the advantages of Agile over the
waterfall approach.
Agile Principles
Learning Objective
identify the principles of Agile software development
1.
[Topic title: Agile Principles. The presenter is Colin Calnan.] In this video, we're going to identify the
principles of Agile software development. And we're going to start with team focus. So what are some
of the things that Agile development can bring to software development? What are the principles we
can apply that will help a team focus? Well, the first one is this idea of self-organized teams. And the
best architectures and requirements and designs, generally, can emerge from self-organizing teams
– teams that have the ability to organize themselves. And Agile can help with that. As well as that, we
have team self-reflection. So, at regular intervals in the project, it's important that the team reflects on
what they're doing. And that helps them to become more effective and then helps them to adjust their
behavior accordingly. As well as that, close and frequent cooperation between partners between the
client and the developers must be there constantly, daily, throughout the project. And then face-to-
face communication is really important as well. One of the principles of Agile is that effective and
efficient communication happens when there is a face-to-face conversation within a development
team. So the next area we can look at is customer and delivery focus. So some of the things we can
look at here are the idea of changing requirements.
So it's important that...and one of the principles of Agile is that we embrace changing requirements.
That we welcome them even late in a development. That we use Agile to kind of harness change and
make it work for the customer in order to give them some sort of a competitive advantage. As well as
that, measure of progress. And the measure of progress is basically the working software. So one of
the principles behind Agile is that a piece of working software is a good measure of progress. Then
we have the idea of software delivery. And, with Agile, we're able to deliver working software
frequently from a very short time scale to a longer time scale, but with a preference for a shorter one.
And then finally, you have customer satisfaction. One of the highest priorities within Agile is to satisfy
the customer. And we can do that through early delivery of the software that's well tested and it's
continuously delivered. And then finally, in the last set of principles, we can look at the individual traits
and processes. So one of the principles around Agile is this idea of motivated people. And obviously,
you want to build a project around motivated people. So give them the environment, the tools, and
the support that they need to help them get the job done.
Then, as well as that, we have the idea of sustainable pace. Agile, in essence, and the processes
that it implements, promotes sustainable development. And the investors, the developers, the clients,
the users should be able to kind of maintain this pace indefinitely if it's done correctly. As well as that,
we have this idea of attention to good design. Obviously, this idea of improvement, continuous
requirements, reviewing, continuous development, that all goes together and works together to help
give good attention and attention to a good design. And then finally, you have this idea of simplicity.
Obviously, when you have processes that try and maximize everything, then that lends itself to being
simplicity. So basically, it maximizes the amount of work done. So those are some of the principles of
Agile software development.
Agile Values
Learning Objective
identify the values of Agile software development
1.
[Topic title: Agile Values. The presenter is Colin Calnan.] In this video, we're going to identify the
values of Agile software development. So we're going to look at these four parts of the Agile
manifesto. The first one is individuals and interactions over processes and tools. So that's essentially
saying that we need to be people focused. And why do we need to be people focused? Well, people
develop software and some of the values that we can use in order to help people develop software is
this team-focused approach. We can make the team our core responsibility something to focus on.
We can help increase and improve interaction between team members as well as wanting to be able
to help team members collaborate with one another. And those values can help us achieve some
desirable outcomes. Those are things like clear communication between team members. The
possibility for innovation, the ability for people to be able to have the space, and the support to
innovate. Effective teamwork allowing team members to work effectively together. The idea that it will
create adaptability within the team – that people will be able to adapt quickly to changes in the
project, as well as ownership.
Creating a team-focused approach with interaction and collaboration can definitely help with having
team members feel some sort of an ownership to what they're working on. So the second part of our
Agile Manifesto is the idea of working software over comprehensive documentation. Obviously, with
documentation, there can be a burden of heavy documentation that can slow everybody down. So, in
Agile, we want to steer away from that. The documents that we create must support product
development. And that's really important, they can't hinder it. They should not really be focused on
what is done so far or what will be done. They're more focused on the software functionality – on the
piece of functionality of the software that you're going to be building. And all of these values can help
achieve some desirable outcomes like more time spent developing as opposed to reading or
developing documentation. Regular code review and iteration that can help fix problems as opposed
to spending all the time up front trying to discover those. Project feature completion – so these
features of the project get completed quicker. And clearly documented requirements, when you start
to focus on discrete pieces of functionality, you can write better documentation for them that are short
and clear. The third thing we're going to look at in our Agile Manifesto is this idea of customer
collaboration over contract negotiation. So you want your customer relationships to be formal and
informal.
And the way, I guess, develop customer collaboration is through that kind of communication with both
formal and informal collaboration as opposed to any kind of strict contract negotiations. The
emphasis really is on collaboration over conflict. You want to involve the client without butting heads
with them. The way you can do that is through the use of communication software and that helps
keep the client up to date. So it's collaborating with them, letting them see, being transparent. The
clients can also tweak requirements so that helps develop a stronger relationship with them. They
see that they have an input through the process consistently and constantly. And that leads to things
like flexible contracts, the ability to be able to have a flexible contract with a client that's not set in
stone. And that changes are made for improvements so changes can be made to make processes
better. And then there's this idea of mutual responsibility that both you and the customer are
somehow responsible for the outcomes of this project. So allowing them to have collaboration and a
window into what's happening helps them feel responsibility for getting the project done.
They have a role to play in getting it delivered. The fourth concept that we'll look at is this idea of
responding to change over following a plan. And we can look at that from the idea of using something
like a flexible project management system to help us respond to change, something that can change
with us. Adaptability and rapid response to change, that's something that as an Agile team you want
to be adaptable and be able to respond to change rapidly. And then, obviously, it's important to know
that many factors may change over the course of a project. So, if we have tools for managing
change, it's going to help us respond and adapt better. We can also look at things in a different way.
We can approach them so we can see through the lens of challenges become benefits. Instead of
challenges becoming things that slow the project down, we see them as a benefit that can help the
project to help us adapt and learn more quickly. And some of the desirable outcomes of this is that
we have this predictability of change. It's no longer a change, it's not a thing that surprises us.
Change is a thing that we understand will come and it can be predictable. We also become easier at
adapting so the outcomes would be that it's easier to adapt to things because we're used to it.
Progress tracking becomes something that is consistent and happens regularly. And then, there's this
idea of transparency that the flexible project management system, the tools that we're using, it helps
to create this transparency within the project. So those are some of the values of Agile software
development.
Agile Best Practices

Learning Objective
identify Agile software development best practices
1.
[Topic title: Agile Best Practices. The presenter is Colin Calnan.] In this video, we're going to identify
Agile software development best practices. So the first thing we're going to look at is product backlog
and ownership. So what should we be doing in order to maintain product backlog and ownership?
The first thing we could look at is the idea of prioritized features lists. That is a list of features with
some technical information about those features. What those features are made up of and what they
require in order to be built. There should also be the idea of some sort of a list of bugs within our
product backlog. And knowledge acquisition, things that we've discovered that need to be recorded
and stored in there for review or for reference. As well as that, we have this idea of functionality
description. We want to be able to list and describe the functionality of these individual prioritized
features in our list. And, that is through this, the use of what we call user stories. User stories built
around the idea of a task or a scenario that a user carries out and what the outcomes might be. And
then it's also important to identify the product owner role. You want to have one individual within the
team who is the product owner, who owns the movement and is the responsibility that they ensure
that the stories are correct, that they have ownership around the product backlog. As well as that, we
have the idea of the Scrum master role and the Sprint backlog.
So the Scrum master is the person who essentially guides the Scrum team. They are generally a
process owner. So they own the process of how all of that works. They also manage the backlog with
the key stakeholders. So they will communicate and discuss how the backlog is being set up with the
key stakeholders. They also help prevent over commitments on team members. So they work to
make sure that that doesn't happen. They organize sprint planning, so they make sure that the sprint
is planned and that the dates are set. They also work with defining what the sprint goals are. What
are the goals of the sprint in terms of the prioritized features in the backlog that we can get done?
And then they also, as I just mentioned, ensure that the backlog is their responsibility, and that they're
able to prioritize it and set it up correctly. So, as well as that, there's this idea of individual input and
commitment. So it's important to have individuals within the team be committed to their work. And the
way we can do this is through things like short, frequent meetings. The daily standup is a good
example of that, or the daily Scrum. Where you come together for a very short period of time to
discuss what you did the day before, what you're doing currently and any hurdles or blockers that are
in your way. There's also the idea of planning poker, where the teams sit down together and go
through this essentially game of estimating between them.
It can help result in more input into solving problems and giving some better context to estimates.
Also this idea of team self-organization, the team should be able to communicate with one another
without the need for a centralized person to communicate between them. There's also the idea of
mutual commitment between the product owner or the Scrum master and the individual team
members that they have a mutual commitment to each other and to the project. As well as that, it's
important to have an open workspace where you have things like whiteboards, and you have your
charts and everything that you need for individuals to be able to see in one space. So that they can
work together. Go to the white board together or start working things out. As well as that, some things
that are good to have are like a window on an open workspace that everybody can go to, to have a
break every once in a while. Another thing that you want to make sure is that people move around
within the project. You want to make sure that individuals have dipped their toe, basically, in all of the
different parts of the project. So that they are not sidled into one specific part and they just work in
that one. Some other best practices are things like burn down charts within the project management.
We can create burn down charts that show how we've progressed so far in term of our estimates,
and how much time we have left. So are we on target, are we off target for the sprint?
Sprint review meetings, so once your sprint is over you sit down to review what happened in the
sprint. Any things that you could have learned, mistakes that were made, things that could be carried
through, sprint retrospective. Actually the sprint review meeting is where you review what's done with
the client and the customer up until now. The sprint retrospective is when you review what happened
in the sprint in terms of things that could be learned, how did the sprint go, etc. Released planning,
obviously it's important that you want to be able to plan your releases, schedule them, make sure that
everybody knows, create code freezes, etc.
And then measure project velocity. Somewhat similar to burn down charts, you want to be able to
look at how many pieces did we get done in this sprint, how many did we get done in the sprint
before. Therefore, we can kind of project out that we can have the same number of things done in the
next sprint, so this idea of velocity. As well as that, coding standards. It's very important to have
those. Pair programming can help with having some coding standards, as well as solving problems.
This idea of creating spike solutions, small programs that can help solve difficult problems. We also
want to make sure that the code is unit tested. So the smallest possible pieces of the code are tested
to make sure that they work. And then regular acceptance testing where basically the delivered parts
are tested to make sure that user stories have been correctly implemented in code. So those are
some of the development best practices when using Agile.
Agile Software Development Life Cycle

Learning Objective
describe the Agile software development life cycle
1.
[Topic title: Agile Software Development Life Cycle. The presenter is Colin Calnan.] In this video,
we're going to describe the Agile software development life cycle. So as I mentioned before, there's
lots of different kinds of Agile software development, but they all kind of follow the same basic
approach. And that approach remains the same depending on whether you're using Scrum, Extreme
programming, or some other Agile method. Step one in this process is this idea of project initiation or
starting the project. Here's a graph that kind of outlays the Agile life cycle. So you can see that it's
cyclical, it's in a circle. And here are some of the parts, some of the components of that development
life cycle. So here on the left, you can see that the first part is to start the project, and this happens
once. So we start the project, and we initiate the project. And what we do then is we kind of define
what the project is, what its goals are. We help create some guidelines around what the project's
requirements might be, so we start defining what exactly it is. And maybe in this point, too, we're
doing things like setting up our environments to make sure that everything is the way it is and we're
ready to go for development when it starts.
So then the next step would be feature development, we jump into developing features. We dig into
our backlog, we start working on things. And then we start integrating those pieces of functionality
into the system and testing them. Then, if the tests succeed, what we do is we move on to the stage
of, well actually what we could then do is go back to working on integrating and building more
functionality and integrating and testing. Build more functionality, integrate and test, more
functionality, integrate and test, until everything passes their tests. Then what we can do is move into
the next steps, which is this idea of review, feedback, and approve. So we can have a look, see if the
piece of functionality is there, provide some feedback on it, and then decide if it's been approved or
not. Then if that has been approved, we push it forward for release. And then once we move that
piece of functionality forward, what we can do is we can kind of record and make changes. So, if it
has not been approved and it doesn't go to release, what we have to do is, we have to look at, okay,
what went wrong? And then implement the changes until that function works.
So there's this kind of record what happened and make some changes. And then we can move
forward to adjusting and tracking. So we can adjust some of our behaviors in terms of what went
wrong. And we can kind of reflect and prioritize and move forward into the next iteration of
development cycle. Where we jump through into the next development phase and take it from there.
So that's an overview of what the Agile development software life cycle looks like.
Agile Information Radiator

Learning Objective
describe what an Agile information radiator is and how it works
1.
[Topic title: Agile Information Radiator. The presenter is Colin Calnan.] In this video, I'm going to
describe what an Agile information radiator is and how it works. So let's start with an overview of
information radiators. So what is information radiator? Well, it's a bit of a generic term, and it's used
to describe any kind of big visible chart, those big visible charts for our Agile projects. And those can
be handwritten, printed, drawn, they could be digital. And usually what those charts contain is the
latest information about what's happening in the project. Those information radiators, they can help
enable informative workspaces. So basically, it's possible for people to be able to see what's
happening at any one time. So all of the information about what's happening in the project is
available at a glance. Things like maybe the number of automated tests, the backlog status, the
velocity, any issues that have occurred, the continuous integration status, and so on. What these
information radiators do is they help promote responsibility and transparency among the team. If this
stuff is always up on the wall and it's always visible, then it promotes ownership and responsibility of
things. The team has nothing to hide from its visitors, from its stakeholders. And it has nothing to hide
from itself. So it acknowledges and confronts problems and issues that might come up in the Agile
project workflow. So here's just some examples of what they might look like on the wall.
You would have a number of these different charts, whether they're handwritten, drawn, using Post-it
notes. You would maybe have a backlog, which would show all of the issues. The analysis state, in
terms of some of the things that you're diving into right now. What's happening in development right
now? What are the things that are being developed? Items that are in test and then elements that
need to be signed off. So that's an example of some of the graphs or the types of graphs that you
might use. And then some tips for creating these information radiators. Obviously, the purpose of
them is to help to keep the team focused on what really needs their attention. So you want to make
sure you determine what to include. What are the things we need to get up here to help everybody
feel included, and to promote transparency? You want to determine the method of presentation, are
you going to do paper or is it going to be digital? How are we going to present this information?
Obviously, the most important thing is that it must be easy to read, understand, and update.
You don't want to create something that's going to take up time. The whole point of our Agile process
is to turn things around quicker and get product out as fast as possible. So you don't want your
information radiator taking time away from that. As well as that, you want to be able to make changes
frequently to it and ensure that it's always up to date. Obviously, that's really important because it
reflects the current state of the project at the current time. So it's important to keep it up to date. So
that's an introduction and a description of what an Agile information radiator is and how it works.
Agile Methods
Learning Objective
describe the Agile methods and the design-code-test loop
1.
[Topic title: Agile Methods. The presenter is Colin Calnan.] In this video, we're going to look at the
Agile methods. First one we're going to look at is the Scrum Agile methodology. This traces back to
the 1990s when it was developed. And it's, essentially, an iterative process made up of sprints. And
those sprints are time chunks of development that will happen in order to achieve that certain
endpoint. It's an incremental development process and it's built to adapt to continuous change. So it's
built so that, as time moves forward, you can pivot quickly and change what's happening on your
project. It consists mainly of this idea of user stories, which are stories based on users' interactions
with the system and what the outcome should be. And then its purpose is to create a potentially
shippable product on each iteration. The next one we'll look at is Agile Modeling. Now Agile Modeling
is basically a collection of values, principles, and practices for modeling software and documentation
that we can apply to a software development project in a lightweight manner. Agile Modeling can be
tailored into a full-fledged software development methodology, like extreme programming, for
example. And luckily, this work has already been done in the form of what we call the Disciplined
Agile Delivery framework.
Now this is a framework that's a lightweight kind of guidance framework to help organizations
streamline their processes and kind of create a solid foundation for agility within their projects. Agile
Modeling is also a collection of best practices, essentially, things like test driven design, model
storming, iteration modeling, executable specifications, active stakeholder participation. So there are
all these best practices that help create what we call Agile Modeling. The next one we could look at is
this idea of Extreme Programming. So Extreme Programming improves our software project in four
essential ways, communication, simplicity, feedback, and courage. So extreme programmers
constantly communicate with their customers and their fellow programmers. They keep their designs
simple and clean. They get feedback by testing their software starting on day one. As well as that,
they kind of deliver the system to the customers as early as possible and then implement changes as
suggested. So they're agile, there's responsiveness and feedback. And then, obviously, every time
they have a success, that kind of creates respect for the contributions of each team member. So that
enables extreme programmers to kind of feel courageous when they're working in their projects to
respond to the changing requirements and technologies.
As well as that, we have Adaptive Software Development, the ASD model. And it has this kind of
principle of continuous adaption for the process. It's divided into four phases, the communication and
planning phase, which is where the project specification documents, proposal documents, and then
risk assessment, etc., are carried out. The analysis, requirements analysis phase, which is started
only when a customer approves a proposal that was prepared in the first phase. So things like the
quality of the software will be approved, an analyst would have gathered details and information. The
software requirements spec document is produced in this phase. Then we jump into the design and
development phase. That's where the ASD process would model a prototype and take a prototype
approach to kind of verify the design and the requirements. And then finally, we have testing and
deployment where test cases are created for the increments. And then each module, or each part of
the software is tested, unit tested, followed by integration testing and so on. So that's that phase. And
then finally, we have the Feature-Driven Development. Obviously, this is a kind of step-by-step
methodology driven around the features that need to be created.
So step one is to develop an overall model, so a kind of like detailed walkthrough with domain
experts to help to create a large model for the work that needs to be done. Then it jumps into building
a features list where you kind of decompose the domains into subject areas and then create
categorized features lists and then plan by features. So you want to be able to dig in to each feature,
work out the scenarios that are there, consider the assignment of tasks to people, as well as
timelines. And then we jump into the design and the build by feature. So you want to be able to
design the models around the software, and then work on building those models in the software. So
those are some of the Agile methods that can be used when working in an Agile software
development framework. [These methods are Extreme Programming (XP) Agile Methodology,
Adaptive Software Development (ASD) Method, and Feature Driven Development (FDD) Method.]
Agile Management
Learning Objective
describe incremental and iterative development (IID)
1.
[Topic title: Agile Management. The presenter is Colin Calnan.] In this video, I'm going to describe
incremental and iterative development – or IID. So what is incremental and iterative development?
Well, it's basically the ability to be able to revisit phases of development dramatically and that helps
improve project efficiency. Now the idea of revisiting these phases over and over is what we call
incremental and iterative development. So the development's life cycle is essentially cut up into
increments or iterations. And then each iteration touches on one of the kind of traditional phases of
development. So, for example, with IID requirements as an ongoing process that's periodically
revisited and then as new requirements surface and as the scope changes, the IID process
continually captures the requirements iteration after iteration. So it's constantly revisiting the idea of
capturing requirements and managing change of scope. So how does it work? Well, it goes back to
the idea of lean development from the 80s. [The Lean development contains the continuously
improve, create value for the customer, eliminate waste, optimize value streams, and empower
people stages.] And it's based around the idea of continually capturing requirements iteration after
iteration. So that's how it would work. The idea is that IID allows for what we call multiple passes or
iterations over a project life cycle to properly address complexities and risk factors that might get
missed through a one-time through. And that's basically key to addressing these complexities and
risk factors.
As well as that, it enables experimentation and learning. There's this kind of trial-and-error approach
that's almost encouraged or an atmosphere of trial-and-error created that basically helps...so like
lead to more efficient innovation. And here we can see how that iterative approach works. In our
graph here, we start in Phase 1 and we work through that and it continues on through the life cycle of
the project. Periodically coming back to revisit Phase 1 and maybe change the requirements or
modify the scope of it, in order for it to keep moving forward. And we see, those phases get shorter
and shorter as we get towards the end of the product. And then finally, there's this idea of the feature
of an iteration. What are the features of an iteration in our development? And in iteration in the
context of an agile project – in this case – is a time box, essentially in which the development takes
place. And that is a certain duration and that duration is usually a number of calendar weeks, maybe
between one and four. And it's usually of a fixed length. So there's a fixed duration for that project. So
let's say it would be a duration of four weeks per iteration. And then it starts with this idea of a vision
and planning phase, where you work through the vision for what's going to happen and the planning
for what's going to happen over the next iteration. And then it would end with a closure phase of
revisiting that talking about what worked and what did not work and so on. So that is a brief
introduction to the iterative development.
Agile Software Development Considerations

Learning Objective
recognize factors to consider when moving to an Agile software development
methodology
1.
[Topic title: Agile Software Development Considerations. The presenter is Colin Calnan.] In this
video, we're going to recognize factors to consider when moving to an Agile software development
methodology. So the first one to consider is, are projects taking too long? So obviously, when you
want to move into an Agile software development methodology, with Agile, results are delivered in
short iterations, with frequent results, and generally, in weeks rather than in months. So that's the
consideration, are projects taking too long? Then, if they are, then you should consider using Agile.
Are changes in scope, cost, or schedule considerations? So, with Agile, feedback and discussion
happen daily and can be approved immediately. So changes to scope or cost or schedule, they're not
cumbersome, and they can happen really easily. Large numbers of defects. So, if your current project
maybe has a large number of defects, you might want to look at Agile. Because with each iteration in
the process, defects are generally resolved quickly. The product is updated, and then deliverables
are released and then tested functionally. So it's the idea of failing quickly, which means that smaller
and less frequent defects generally in the project. Inadequate communication.
If you've got too many cooks in the kitchen, with Agile, team sizes are small, with stakeholders and
lead developers comprising the core team. And then this can help facilitate communication between
team members, and decision making as well. Conflicts are also easily resolved and quickly resolved,
and tend to be handled at a more pragmatic level. And then resource dependencies, so things like
QA testing etc., are dependent on one another before they can move forward. Then with Agile, all
team members and decision makers are involved on a regular basis. And they've worked together
throughout the iteration, so it can speed things up. If your testing is proving costly, then with Agile,
since changes are approved, tested, and implemented during each iteration, the change request
costs are minimized. And then inconsistent workloads. So, with Agile, the resources being the team
members, are generally more engaged and familiar with the product early in the process. That they're
not waiting until a certain part of the product or project where they're working on it for a consistent
period of time and then they're off if for another period of time.
So those are some things with Agile, that Agile can help improve and provide benefits to. So some of
the questions to ask if you've made a decision to try to give Agile a try. Some of the questions you
could ask would be who, what, and how. So who in terms of, who are the stakeholders? Who will be
the active people working the project? Do they have the capacity to participate in Agile? And who's
responsible for completing the deliverables? And then with what, you could ask things like, what
changes are going to be needed to our current software development life cycle, for example? Or are
there any organizational changes that we'll have to implement in order to achieve a successful Agile
implementation? Or maybe, are there any cultural roadblocks that might come up? And things like,
what are you asking your IT professionals to deliver versus maybe operational professionals? And
then finally, there's how. And this is probably the one with the most questions. How will you track
changes and sprints? How will you ensure that people are ready to accept the change?
How will you know that the project is on track? How do you evaluate the success of the project? And
how do you ensure that collaboration and interaction and communication remains consistent and of
high level throughout the project? So those are definitely some questions to ask when you're thinking
of implementing Agile. And then finally, as well as that, you want to make sure that when you're
implementing Agile, that it's always useful to get some outside expertise. So to bring somebody in
and to bring in an expert on the team. So generally, if you're bringing in an expert, that expert should
obviously understand Agile fundamentals. Even, if you're training up an individual to be an expert,

you have to ensure that they understand the fundamentals and have the mechanisms in place to be
able to succeed with Agile. They also want to be able to identify and mitigate risk across the whole
process, being it people or technology. As well as that, they want to be able to provide leadership in
the Agile space. So being able to make decisions, both things like the length of iterations, the
definition of work, the definition of testing, etc.
Also you want to make sure that they can enable organization-wide collaboration. So you want to
make sure that there's acceptance of Agile throughout the organization. And then you want to make
sure that they have some practical experience that you can leverage so that you can use that for your
team. So as well as that, here are some other elements that we need to think about when creating
governance or providing governance for Agile development. So basically, your team should be aware
of some of the challenges and constraints of Agile development. And on the other hand, they should
also be able to choose the most suitable Agile method for the project. So they want to understand
what the constraints and challenges are of Agile.
And then be able to dig in to the various Agile methods to be able to select one for their project based
on those challenges and constraints. And then once they should also find the best choice for Agile,
considering which methods are best for them. So they can look at different adoption styles in terms of
how Agile can be adopted into the organization and into their process. So kind of like a three phase
process of understanding your challenges and constraints. Choosing an Agile method that works for
that. And then figuring out how to adopt that into your current processes. So that was a quick
overview of how to recognize factors to consider when moving to an Agile software development
methodology.
Issues Transitioning to Agile

Learning Objective
recognize the issues organizations can face when applying Agile principles in given
scenarios
1.
[Topic title: Issues Transitioning to Agile. The presenter is Colin Calnan.] In this video, we're going to
recognize the issues organizations can face when applying Agile principles in given scenarios. So
let's look at some of the challenges that teams can face when implementing Agile. So the first one to
look at is management and organization challenges. So, for Agile transformation, all aspects of the
organization are going to change. So that fundamental change is going to cause some challenges.
As well as that, coaching and mentoring in this process can be difficult because of not only technical
problems that have to be solved. But also, the mindset of people need to be considered. You could
also have knowledge-management issues. So generally, the plan-driven methods have heavy
documentation, and rigid reports are required. However, in Agile, it requires a little less
documentation. And it's a little bit more responsive and rapid. So that can cause some problems with
people who are used to managing things with heavy documentation and rigid processes. There's also
some issues in changing to an iterative software development life cycle. Obviously, that idea, the
traditional life cycle, it can cause conflicts for people that have difficulty understanding how to move
from that traditional life cycle to a more iterative one. And then there's differing measurement
practices. Obviously, with the quicker iterations, things are measured differently. And then a lot of
obstacles are reported when this happens when you switch to Agile.
Sometimes it's difficult for people to forget their previous role. And then they can be a bit resistant to
change. And then, as well, there are some project management challenges that come up. Because
obviously, the project manager, they should be leadership instead of being a commander. So they
have a very different role than they might normally have in an Agile process that they might have in a
more traditional one. And then there are some challenges in the work environment. So for example,
the lack of face-to-face communication or different cultures and time zone may cause issues with an
Agile development process unless it's managed carefully. So as well as that, there can be some
confusion and misunderstanding about the process. It can be a cultural challenge for people who
have been used to doing things and how they spent every day. To have a new process dropped on
them can sometimes be a challenge. As well as that, this idea of estimates versus deadlines. People
have a common misunderstanding about that. Estimates and deadlines are not the same things. And
that can be difficult for people to get used to if they've come from a scenario of deadlines where
things are due, as opposed to creating estimates. And that can have some issues in terms of people
adjusting their expectations accordingly. As well as that, there can be confusion over roles.
So obviously, project management versus product ownership, scrum master versus project manager,
etc. So that can be something that is challenging. And then confusion with cross-functional team
formation. Obviously, people may be used to working within their silo team within their specific
department. And then the introduction of a cross-functional team is something that they struggle to
have to get used to. As well as that, a rapid approach to change may work best. So trying to go
slowly and do partial or gradual Agile, it does not work. You have to just jump right in and go full Agile
all at once. And then there's also this idea of an acceptance of a flat structure. Obviously, people are
used to maybe a hierarchical way of working within a team. But within the Agile methodology,
generally, things are on a flat structure where everybody's working together towards the same thing.
So that can be difficult for people to get used to as well. As well as that, there can be some
resistance to change. So for example, people might be actively resisting things, where they try to
sabotage the process, or they'll bad mouth it. Or they may be passive in that they'll go along with it.
But they'll say to themselves, well, who cares, why? I'm just going to do this, but I don't really care
about it.
You can have unconscious resistance, where people are resistant to it. They're just not aware that
they're resistant to it. So over time, they put up resistance to it in ways that it just happens
unconsciously. And that generally, others may try to block participation. So they may do things that
prevent others from participating in it. As well, as we covered, they might just pretend to go along
with it. So they're saying, well, I'm not really interested in this. It doesn't really apply to me. But I'm
just going to go along with it anyway. The resisters can cause a lot of damage to the process.
Because, for example, maybe their job is testing. They might just do enough testing to just get by.
And then assume that the other tester is just going to do the real work, and leave it at that. So
something that you might need to do in order to fix this is that you must build momentum to overcome
resistance. So you want to make sure that you start this quickly and that you build enough
momentum.
What you can do is create the feeling within the organization that this change is inevitable, that we're
doing this. It's going to happen with or without you on board. So it's like, create, you want to break
through inertia with as much momentum as possible. As well as that, there can be difficulty adapting,
so failing to adapt to new roles. People may take on a new role, and they just can't change their
existing processes to do that. Intimidation is obviously another big thing. With teams managing their
own work, members have much more responsibility for prioritizing and decision making. And this can
feel like additional pressure. Group self-organization, obviously.
If people are used to a specific hierarchical structure where they're given instructions, it can be
difficult for them to self-organize within groups. Small cross-functional teams. Again, without the
experience of working cross functionally, it can be difficult for them to get on board and become
embedded in these small cross-functional teams. And then, obviously, incomplete adaptation to Agile
methods. Where they maybe keep some of their old systems and old ways of doing things and take
on some of the new Agile ones. But if you skip it, you're basically diminishing the value of it. So the
idea is, it's all or nothing. And then training in Agile methods. Obviously, you want to make sure that
your team is trained up as much as possible. And that they have all of the supports that they need for
moving their process to Agile.
Exercise: Identify Agile Principles

Learning Objective
identify Agile software development features
1.
[Topic title: Exercise: Identify Agile Principles. The presenter is Colin Calnan.] In this exercise, you
will identify the advantages of Agile over the Waterfall approach. Identify the principles of Agile
software development. Identify the values of Agile software development. Identify Agile software
development best practices. And describe the Agile software development life cycle. So pause the
video, find your answers, and then we'll come back and walk through them. Okay, the first one we
look at was to identify the advantages of Agile over the Waterfall approach. And there's quite a few.
Just cover a few of them here. So one is that Agile is a non-linear approach. So it's iterative, it
welcomes change. It also helps create coordinated teams. It involves the customer earlier. It creates
a sense of ownership for the customer. It reduces the time to market for a product. And it also helps
with user-focused development. If we look at identifying the principles of Agile software development.
We can see things like some of the principles around that are self-organized teams, team self-
reflection. Close and frequent cooperation between team members. Face to face communication,
changing requirements in the project.
The measure of progress, rapid software delivery. Customer satisfaction, motivated people.
Sustainable pace, attention to good design, and simplicity. The next question was identify the values
of Agile software development. Okay, so some of the values we could look at here. And the four
values in particular that we'll look at would be individuals and interactions over processes and tools.
Number two would be working software over comprehensive documentation. Number three,
customer collaboration over contract negotiation. And number four, responding to change over
following a plan. The next question, to identify Agile software development best practices. Again,
there are quite a few of these. We'll cover a few of them. So some best practices would be to
establish a product backlog and ownership of the process. To create a prioritized feature list, to write
functionality descriptions or user stories. To create a product owner role and create a scrum master
role. To do sprint planning, to write sprint goals, and to manage the sprint backlog. As well as that,
you could do things like short stand up meetings. Do planning poker for estimating or planning.
Work at getting self-organized teams, maybe have an open workspace. Create burn down charts,
measure your project philosophy. Implement some coding standards, and work to have pair
programming on your team. And then finally, let's describe the Agile software development life cycle.
So this is obviously a cycle, so step one would be start the project. Step two, define what the project
is, and what its goals are. Step three would create some guidelines for the project's requirements.
Step four, develop a software function. So we're getting to development, so start developing a
software function. And then steps five and six would be integrate the function and test the function.
So develop, integrate, and test. Then seven would be if the tests succeed, then move onto the next
function. And repeat the develop, integrate, test for each function as they pass the tests. If the test
doesn't succeed, then what you need to do is record what went wrong.
And then implement the changes until that function works. Then following that, you need to reflect
and prioritize, based on client feedback and new challenges. So once you've integrated your
functions, you can reflect back and say okay, there's some feedback from the client and some new
challenges. We need to reflect and re-prioritize. And then once everything's been tested and
integrated, you then release the function to the market. Then you move on to the next function, and
then repeat the steps over again. So the develop, integrate, test. If something went wrong, reflect and
prioritize, and then test and integrate again, and then push to market. That's the description of the
software development life cycle. I hope you're able to answer those questions. As I mentioned, there
are many answers to most of those questions. And if you got some of those, then that should cover it
mostly.
© 2018 Skillsoft Ireland Limited

Introduction To Agile Software Development - 2 PDF

Uploaded by

Copyright:

Available Formats

Introduction To Agile Software Development - 2 PDF

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

Introduction To Agile Software Development - 2 PDF

Uploaded by

Copyright:

Available Formats

14/04/2019 Skillsoft Course Transcript

2. History of Agile Software Development

7. Agile Best Practices

8. Agile Software Development Life Cycle

9. Agile Information Radiator

10. Agile Methods

11. Agile Management

12. Agile Software Development Considerations

13. Issues Transitioning to Agile

Practice: Agile Principles

History of Agile Software Development

Agile Best Practices

Agile Software Development Life Cycle

Agile Information Radiator

Agile Software Development Considerations

obviously understand Agile fundamentals. Even, if you're training up an individual to be an expert,

Issues Transitioning to Agile

Exercise: Identify Agile Principles

© 2018 Skillsoft Ireland Limited

You might also like