0% found this document useful (0 votes)
450 views76 pages

Agile Project Management Full Work

Uploaded by

Ben cash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
450 views76 pages

Agile Project Management Full Work

Uploaded by

Ben cash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 76

AGILE

PROJECT
MANAGEMENT

A Practical Step-by-Step Beginner's Guide to


Agile Project Management and workable
Software Development
Table of Content

INTRODUCTION 1
HISTORY OF AGILE 3
THE BASICS AND ADVANTAGES OF AGILE PROJECT
MANAGEMENT 5
ANALYZING THE KEY BUSINESS BENEFITS 4
ECONOMIC FRAMEWORK 4
PEOPLE’S PERSPECTIVE 5
HOW TO IMPLEMENT AGILE PROJECT MANAGEMENT INTO
YOUR BUSINESS 8
HOW TO APPLY THE AGILE PROJECT MANAGEMENT METHOD
EFFECTIVELY 16
THE MAIN BENEFIT OF APPLYING THE AGILE METHOD 21
HOW THE AGILE METHOD CAN COMPARE TO THE
WATERFALLMETHOD AND OTHER TRADITIONAL PROJECT
MANAGEMENT METHODS 23
WHAT IS SCUM 27
HOW TO TURN YOUR ORGANIZATION AGILE AND GET THE
MOST OUT OF AGILE SOFTWARE DEVELOPMENT 30
PRINCIPLES OF AGILE AND AGILE MANIFESTO 34
TECHNIQUES YOU CAN UTILIZE IN ORDER TO GET THE
MOST OF AGILE SOFTWARE DEVELOPMENT 40
COMMON CHALLENGES OF IMPLEMENTING AGILE METHOD 47
UNDERSTANDING MORE ABOUT THE AGILE METHODOLOGY
AND HOW TO USE IT 53
THE KEYS YOU NEED TO SUCCESSFULLY IMPLEMENT AGILE IN
YOUR BUSINESS 57
KEY METRICS TO MEASURE SUCCESS 63

CONCLUSION 69
Copyright © 2019

All rights reserved. No part of this publication may perhaps be distributed, transmitted
or reproduced in by any means or in any form, including photocopying, recording, or
other electronic or mechanical methods, without the permission of the publisher, with
the exception of in the case of brief quotations embodied in critical reviews and
specific other noncommercial uses acceptable by copyright law.
INTRODUCTION
This book is intended to benefit project managers who are basically moving
into project management. It will also be of interest to agile developers who
wish to know more about project management. And finally, it will also be of
interest to anyone else who wants to know more about the management of
agile projects. It is critical to note that agile is not a methodology but an
approach that can utilize a variety of methodologies.

Agile uses organizational models based on people, collaboration, and values.


The Agile Manifesto for the primary principles of the agile philosophy. It uses
rolling wave planning, iterative and incremental delivery, rapid and flexible
research to change, and open communication between teams, stakeholders,
and customers the Agile Method is an approach to project management that is
designed to help development teams effectively address the moving targets
and uncertainties that identify the creation of new software applications. One
of the hallmarks of Agile is that it uses incremental, iterative series of work that
is commonly referred to as “sprints.”

A sprint is a time allocated for a specific phase of a development project, and


it’s considered to be complete when the time period set for the phase expires.
Work on that phase of the project ends, even if some team members think
more effort is required. The next phase of the project begins and runs through
its designated time frame, and so on until all the phases of the project are
complete.

Many of the ideas behind Agile emerged in the 1970s as alternatives to


traditional approaches to project development. But the term “Agile” in the
context of software development was first popularized by the “Manifesto for
Agile Software Development,” created in 2001 by a set of experienced

1|Page
software developers who came to perceive that they were practicing software
development in a different manner from the classic waterfall methodology.

The manifesto documented their shared beliefs about how contemporary


software development processes should operate, and the values and principles
outlined in the manifesto were derived from and support a range of
development models, such as Scrum and Kanban.

2|Page
HISTORY OF AGILE
The frustrations of applying sequential project management methods to
software development resulted in the emergence of Agile. A group of leading
software developers met in Snowbird, Utah, the USA in 2001 to discuss their
challenges. They ultimately created the Agile Manifesto.

What the software industry needed was greater agility– new methods that
allowed for changes without significantly impacting cost and production
schedules.

By dividing production into small components (called iterations) that could be


simply and rapidly developed and tested, modifications could be made without
having to wait for the end product.

Now agile methods are used in a variety of industries beyond software


development, such as telecommunications, aerospace, and construction, as
well as being blended with more traditional, linear project management
approaches.

Agile is work a management methodology that can be implemented into most


aspects of your business processes.

Originally conceived to be used in a software development context, agile


emerged as a way to streamline operations back in the early 2000s when
previous work management philosophies weren’t making the cut. Business
leaders in the IT and software development space felt that tools conceived
previously were clunky and slow and didn’t allow the kind of responsiveness
needed to shift plan of action as priorities change for different projects quickly.

Although agile is generally used in the IT and software development industry,


it was initially devised as an alternative to Software Development Lifecycle
methodologies and offers an iterative approach to software delivery.

3|Page
Although agile was initially created to help businesses in an IT and software
development context, the basic framework is applicable across every industry.

Agile dictates that software is built incrementally from the start of the project
rather than attempting to deliver it all at the very end. Each project is broken
down into smaller, bite-sized functions and is prioritized and given to different
user types. Then those smaller mini-projects are continuously worked on and
delivered over two-week spans called iterations.

While these are the basics of agile, the methodology follows a set of principles
that dictate how businesses can become more streamlined via these
guidelines. Here are a handful of ways to integrate this philosophy into your
marketing plan.

4|Page
THE BASICS AND ADVANTAGES OF AGILE PROJECT
MANAGEMENT
Organizations who use agile principles and practices have documented the
value they see from the philosophy and techniques:

•Adaptive to changing business needs, giving the organization more influence


over adding, modifying, or removing requirements

•Early and continuous customer feedback improves communication and


empowers business owners who can receive and review critical information
necessary to make decisions to steer the project throughout the development
process

•Early measurable return on investment

•High visibility and influence over the project progress leading to early
indications of problems

•Incremental delivery rather than a single complete delivery at the end of the
project; reduce product and process waste.

Analyzing the Key Business Benefits

The Agile method of software development presents several compelling


potential benefits for companies. These benefits fall into two main categories:
Company economic framework and people's perspectives.

Economic framework

The Agile Method changes the way work is structured, and even the way
organizations think about work. It introduces a shift in the way tasks are
completed, with the aim of increasing productivity throughout the
development lifecycle and at the same time boosting productivity.

The method is designed to create more efficient and productive ways of

5|Page
working that helps teams achieve better results and higher quality products
that actually meet the needs of customers. The rise in efficiency comes
because teams work in shorter cycles and are less likely to veer off in the
wrong direction in terms of design and development.

Rather than working from development plans that are measured in months
and even years, teams are expected to produce results within weeks. That
means there is faster and regular feedback from customers, and many
opportunities to make mid-course corrections in order to deliver what the
customer wants at virtually every stage. By leveraging iterative planning and
feedback, teams can continuously enhance products to reflect the needs of
clients, and quickly adapt to changing requirements throughout the process by
accurately measuring and evaluating project status at every stage.

Team members can learn during each cycle, and gain knowledge as they move
along with a project. Because much of Agile is a collaborative process, this
knowledge can be shared among colleagues as appropriate, building up the
experience of the team as a whole.

The collaboration extends to the customers who will be using the software.
Although customer needs can and do change over time, having continuous
feedback during the development process dramatically reduces the likelihood
of delivering products that are off the mark.

From a corporate results standpoint, all of this can lead to higher revenue from
product sales, shorter time to market for new products and services, and
increased the ability to compete.

Many might argue that in today’s business environment, being agile in general
is not a nice-to-have capability – it’s a must-have. Customers expect
companies to be highly agile, and if they’re not, they will turn to competitors
that meet this need.

6|Page
PEOPLE'S PERSPECTIVE

It’s a common sentiment that people are an organization’s most valuable


assets – and it’s true.

Regardless of how much automation companies adopt as a result of advances


in artificial intelligence, machine learning, robotics, and other areas, human
workers are still the heart and soul of any business. They are the drivers of
creativity and innovation.

''The Agile method can provide benefits from a people perspective


because it can lead to happier employees and team. Better team
collaboration fosters more cohesion and cooperation among
developers.''

When workers are satisfied, there is less likelihood of conflict among team
members and less turnover, which means companies don’t need to spend
much of their time looking for new talent at a time when technology skills are
challenging to come by.

When there is a need to expand development teams, fostering a positive work


environment can make it easier to recruit people. The Agile Method can help
provide a much better environment for innovation, the empowerment of
teams, and the realization of creative potential. All these things are attractive
to prospective employees.

The Agile Method can also lead to more satisfied customers. Because of the
close collaboration between development teams and the ultimate users of the
software, customers get a chance to share in the innovation and weigh in on
what they think is essential. As a result, there is a much higher chance they will
be pleased with the finished product.

7|Page
HOW TO IMPLEMENT AGILE PROJECT MANAGEMENT
INTO YOUR BUSINESS
Step 1: Set your vision with a strategy meeting

At the beginning of a new Agile project, you need to define a clear business
need or insight that your project is addressing. In essence, you need to answer
why you’re doing what you’re setting out to do? It’s big-picture stuff, but this
is the core belief that you’ll refer back to as you build.

For product companies, one of the best ways to define your vision is to use
what’s called the Elevator Pitch:

For: (Our Target Customer)

Who: (Statement of the Need)

The: (Product Name) is a (Product Category)

That: (Key Product Benefit, Compelling Reason to Buy and/or Use)

Unlike: (Primary Competitive Alternative)

Our Product: (Final Statement of Primary Differentiation)

If you’re not building a product, you can still probably see how you could
quickly adjust this pitch to match your project’s goals.

Who should be there?

This is where you get buy-in on your project, so as many vital stakeholders
should be present, including relevant executives, managers, and directors, as
well as all product owners.

When does it happen?

Your strategy meeting should happen before any project starts or at least

8|Page
annually to make sure your mission still is valid, with periodic meetings for
updates.

This is totally subjective, but a proper strategy meeting can take anywhere
from 4–16 hours (just not in a row!)

Step 2: Build out your product roadmap

Once your strategy has been validated, it’s time for the product owner to
translate that vision into a product roadmap. This is a high-level view of the
requirements for your project with a loose timeframe for when you will develop
each of them.

The ‘loose’ part here is essential. You’re not spending days or weeks planning
out every step, but merely identifying, prioritizing, and roughly estimating the
effort each piece of your product will take on the way to making a usable
product.

So, what does this look like for an Agile project? Product Management expert
Roman Pichler suggests working with a goal-oriented product roadmap, which
is sometimes also referred to as theme-based:

“Goal-oriented roadmaps focus on goals, objectives, and outcomes like


acquiring customers, increasing engagement, and removing technical debt.
Features still exist, but they are derived from the goals and should be used
sparingly. Use no more than three to five features per goal, as a rule of
thumb.”

For each of these goals, you want to include 5 key pieces of information: Date,
Name, Goal, Features, and Metrics

9|Page
This gives you a clear idea of what needs to be done, when, and how you’ll
measure success.

Who should be there?

The product roadmap is done by the Product Owner, but should also include
buy-in
in and input from any other stakeholders in the project
project—think
think marketing,
sales, support, and development team reps.

When does it happen?

Like all things in Agile projec


projectt management, you want to move rather than
dwell on early-stage
age planning. However, your roadmap is a literal map from
your mission to your MVP and should take as long as it does to feel confident
that you’ve covered all the applicable goals.

Step 3: Get excited with a release plan

What is it?

Now that we’ve got a strategy


trategy and a plan
plan, it’s time to set some tentative
timelines.

10 | P a g e
At this stage, the product owner creates a high-level timetable for the release
of working software. Because Agile projects will have multiple versions, you’ll
want to prioritize the features needed to get you to launch first.

For example, if your project kicked off in November, you might set your MVP
launch for early February, with a high-priority feature release the following
May. This all depends on the complexity of your project and the lengths of your
“sprints”—the periods of work dedicated to each goal (which we’ll get into
next!). A typical release includes 3–5 of these sprints.

Who should be there?

A release plan is like rallying the troops. The product owner, project managers,
and all team members should be there. You can also bring in a few key
stakeholders to add some additional oomph and get the team fired up.

At a minimum, your release plans should be created on the first day of any new
release and reviewed at least every quarter.

How long should it take? Be realistic about how long a release will take, but
don’t let that slow you down. A typical release planning session should take
around 4–8 hours.

Step 4: It’s time to plan out your sprints

What is it?

It’s time to move from the macro to the micro view as the product owner and
development team plan “sprints”—short cycles of development in which
specific tasks and goals will be carried out. A typical sprint lasts between 1–4
weeks and should remain the same length throughout the entire project as this
enables teams to plan future work more accurately based on their past
performance.

11 | P a g e
At the beginning of a sprint cycle, you and your team will create a list of
backlog items you think you can complete in that timeframe that will allow you
to develop functional software. Then, it’s as simple as using one of the Agile
methodologies to work through them (which we’ll cover more in-depth below).

Who should be there?

Sprint planning is a team effort, and therefore the product owner, project
managers, and all team members should be present to voice their thoughts
and concerns.

When does it happen?

Sprint planning takes place at the start of each sprint cycle. For example, if
you’re making weekly sprints, you’ll do a planning session every Monday (or
whatever day of the week you choose to start on).

How long should it take?

Sprint planning sets the tone for the cycle. So while you don’t want to spend
too much time at this stage, it could realistically take you 2–4 hours. But once
you’ve planned your sprint, you’re quite literally off to the races.

Step 5: Keep your team on track with daily stand-ups

Throughout every sprint, you need opportunities to make sure no roadblocks


are creeping up and getting in the way of completing your goals on time. That’s
where the daily meeting, or “Standup” in Agile-speak, comes in.

A standup is a daily, 15-minute meeting where your team comes together to


discuss three things:

What did you complete yesterday?

What are you working on today?

12 | P a g e
Are there any roadblocks getting in the way?

While this might seem like an annoyance to some of your team, these
meetings are essential for fostering the kind of communication that drives
Agile project management. Agile depends on reacting quickly to issues, and
voicing them in a public space is a powerful way to foster cross-team
collaboration.

Step 6: Sprint’s made? It’s time for a review

What is it?

If everything has gone as planned, by the end of your sprint cycle, you should
have a functioning piece of software. At this point, it’s time to review what was
done and show this off to people on your team and any key stakeholders. Think
of it as Agile show-and-tell.

The key here is to check your initial plan to make sure that all requirements
were met. As the product owner, it’s your choice to accept or refuse certain
functionalities. If something went wrong, ask why? How can you adjust the
next sprint so your team can hit their targets? Agile is all about continuous
learning and iterations, and this means on your processes as well as your
product.

Who should be there?

Your entire team, as well as any key stakeholders, should be at your sprint
review to check in on progress and voice their support.

When does it happen?

The sprint review takes place at the end of each sprint

How long should it take?

13 | P a g e
Just say no to PowerPoint’s and feature dissertations. The sprint review should
only take an hour or two max.

Step 7: What’s next? Decide what to focus on in your sprint


retrospective

What is it?

For Agile project management to work, you need to have a clear next step after
each step. This is determined during your sprint retrospective. Once a sprint
has been completed, and features have been shown off, it’s time to decide
what work gets done next. Did you learn something during the sprint that
changes your initial timeline or vision for the project?

Don’t merely plan, but also take this time to discuss how the previous sprint
went and how you could improve in your next one.

Who should be there?

The retrospective is a natural extension of the review, and so while your


stakeholders can leave, the rest of the team should be involved and giving
their insights

When does it happen?

It makes the most sense for your sprint retrospective to happen right after
your sprint review.

How long should it take?

Again, keep it short and sweet. An hour or two max is probably all you’ll need
to debrief and plan for the next brief.

What happens now?

At this point, you should have a functional piece of software you can ship, get

14 | P a g e
feedback on, and plan new features or fixes for. This continuous shipping,
learning, and building are what makes Agile so powerful. Rather than directly
working through your backlog, you’re releasing products and seeing how
people interact with them. This means rather than work on a product for
f a year
only to release it and find out some core functionality is missing, and you could
potentially figure that out after a sprint and adjust accordingly.

15 | P a g e
HOW TO APPLY THE AGILE PROJECT MANAGEMENT
METHOD EFFECTIVELY

The top three Agile methodologies explained;

At this point, you might feel ready to dive into Agile and bring it to your team.
However, there’s one more step we need to go through. As we said earlier,
Agile is more of a blanket term for a philosophy of project management and
development. To use these ideas to their fullest, some brilliant people have
developed Agile methodologies you can follow.

These methodologies are all quite similar, but from an implementation


standpoint, each has its own mix of practices, terminology, and tactics.

Let’s take a look at the top 3 and break down how they’re different: Scrum is
probably the most well-known Agile methodology, and often the two go
hand-in-hand. It’s especially popular in the software development world
thanks to its simplicity, proven productivity, and ability to act as a catch-all
framework for the various practices promoted by other Agile methodologies.

Here’s how it works:

With Scrum, the “Product Owner” works closely with their team to identify and
prioritize their goals or features and add these to what’s called a “Product
Backlog.” The backlog can consist of features, bug fixes, non-functional
requirements—pretty much anything that needs to be done in order to deliver
working software.

16 | P a g e
With this backlog in place, the Product Owner decides priorities and teams sign
up to deliver “potentially shippable increments” of software during their
Sprints, which typically last 30 days. Once the team has committed to that
Sprint’s backlog, nothing else can be added to it except by the organization. At
the end of that 30-day Sprint, the backlog is analyzed and reprioritized (if
necessary), and the whole thing starts over.

Like Scrum, Kanban is an Agile methodology built around continual delivery,


while keeping things simple and not overburdening the development team.
Kanban is based around 3 basic principles:

Visualize your workflow on a ‘board.’

Being able to see all the items you’re working on in the context of each other
can be incredibly informative and help keep things clear and straightforward
when projects get complex. Kanban tools (like Planio!) use a ‘board’ style to
see all your items and where they fit in the flow from to-do to doing to do.

17 | P a g e
Keep your work-in-progress
progress (WIP) limited

Have clear next steps

Extreme Programming (XP)

Extreme Programming (XP) isn’t absolute


e in the Mountain Dew sense, but it is
a bit of a departure from the other methodologies we’ve discussed.

XP is a more disciplined approach to Agile project management that involves


high customer involvement, rapid feedback loops, continuous testing and
planning, and close teamwork to deliver working software quickly. To give you
an idea, a typical XP Sprint lasts only 1
1–3 weeks.

The original XP ‘recipe’ described by software engineer Kent Beck, was based
around 4 values—simplicity,
simplicity, communication, feedback, and courage—with
courage 12
supporting practices. It’s definitely more complex than other methodologies
methodologie
and looks something like this in practice:

18 | P a g e
In XP, there are tight feedback loops where the “customer” works closely with
the team to define and prioritize granular goals called “User Stories.” The team
then estimates, prioritizes, and plans the delivery of these stories, getting
more feedback from the customer until it’s ready for release.

Final thoughts on implementing Agile project management

Congratulations! You now should have a clear understanding of what Agile


project management looks like and a few of the compelling ways you can use
it on your own teams.

However, there is one last piece of the puzzle. With all of this information,
organization, and prioritization happening, you need a proper project
management tool to keep your Agile project on course. The best software
addresses 3 pain points common to the Agile project management process:

Reporting and Metrics: Things like time tracking and projection,


easy-to-understand progress reports for stakeholders, quality assurance, and
a big-picture look at the progress

Communication: The ability to keep everyone on track with updates to local


and distributed teams, shared task lists, feedback, and assignments

19 | P a g e
Project assessment: Functionality around identifying and remedying obstacles
or bottlenecks, evaluating performance, and making sure financials are under
control.

20 | P a g e
THE MAIN BENEFITS OF APPLYING THE AGILE METHOD
 Agile project teams achieve faster time-to-market and consequentially
cost savings. They start development earlier than in traditional
approaches because agile approaches minimize the exhaustive upfront
planning and documentation that is conventionally part of the early
stages of a waterfall project.

 Agile development teams are self-organizing and self-managing. The


managerial effort usually put into telling developers how to do their work
can be applied to removing impediments and organizational distractions
that slow down the development team.

 Agile development teams determine how much work they can


accomplish in an iteration and commit to achieving those goals.
Ownership is fundamentally different because the development team is
establishing the commitment, not complying with an externally
developed obligation.

 An agile approach asks, “What is the minimum we can do to achieve the


goal?” instead of focusing on including all the features and extra
refinements that could possibly be needed. An agile approach usually
means streamlining: barely sufficient documentation, removal of
unnecessary meetings, avoidance of inefficient communication (such as
email), and less coding (just enough to make it work).

 By encapsulating development into short sprints that last one to four


weeks or less, you can adhere to the goals of the current iteration while
accommodating a change in subsequent iterations. The period of sprint
remains the same throughout the project to provide a predictable
rhythm of development for the team long-term.
21 | P a g e
 Planning, elaborating on requirements, developing, testing, and
demonstrating functionality occur within an iteration, lowering the risk of
heading in the wrong direction for extended periods of time or promoting
something that the customer doesn’t want.

 Agile practices inspire a steady pace of development that is productive


and healthy. For example, in the popular Agile development set of
practices called extreme programming (XP), the maximum workweek is
40 hours, and the preferred workweek is 35 hours. Agile projects are
sustainable and more productive, especially long term.

Check out the presentation on the adverse effects of “Racing in Reverse.”

 Priorities, experience on the existing project, and, eventually, the speed


at which development will likely happen within each sprint is precise,
making for the right decisions about how much can or should be
achieved in a period of time.

If you’ve ever worked on a project before, you might have a basic


understanding of project management activities.

HOW THE AGILE METHOD CAN COMPARE TO THE


WATERFALL METHOD AND OTHER TRADITIONAL
PROJECT MANAGEMENT METHODS
The waterfall method is a traditional project management approach that
uses sequential phases to define, build, test, and release project deliverables.
Each level is completed and approved before the team moves on to the next
stage. The project can't move back to previous phases.

22 | P a g e
Agile is an umbrella term covering several newer project management
approaches that use iterative work cycles, called sprints. Each sprint uses
'mini-phases'
phases' to define, build, test, and release the project deliverables.

You show the audience


ce a visual comparing the two methods, which shows how
the waterfall method is a sequential process while agile methods are iterative
cycles from the beginning to the end of the project.

What Are the Differences?

It looks like your audience gets the dif


different
ferent methods, but diving deeper will be
helpful. The main difference between waterfall and agile methods is in the
goals; the waterfall method wants to get everything right the first time, and
agile methods wish to get things freed quickly. Differences in
n adaptability,
documentation, testing, and collaboration support different goals. Let's look at
each a little closer.

Adaptability

Adaptability is how responsive a project approach is. Can the project method
quickly react to changes throughout the project
project?

23 | P a g e
If we're talking about changing requirements, the waterfall is not adaptable. In
fact, the waterfall will force the project team to start the project over if a
requirement change is discovered late.

Agile methods are incredibly adaptable to changing requirements because of


the project reviews and validate the requirements at every sprint throughout
the project. So, any change in conditions is simply addressed in the next
sprint.

If we're talking about changes to project team members, the waterfall method
is very adaptable. Waterfall requires detailed documentation at each step, so
getting a new team member up to speed is a matter of reading the documents.

Agile methods are more focused on quickly releasing the deliverables, so


documentation tends to be done after. New project team members would have
little information in the project's documentation, so it would be harder to get a
handle on the project.

Testing

Testing, as you probably know, is verifying the deliverable you've provided


actually does what it's supposed to. Testing is a crucial part of any project.
After all, it doesn't matter how well the project goes if the deliverables don't
work.

In a waterfall project, testing is done towards the end of the project. You don't
know if the deliverable works until you're nearly done with the project. A
failure in any part of the testing can send the project back to the start to figure
out why the test failed, dramatically impacting the cost and time needed to
complete the project.

Agile projects, however, test pieces of the deliverable throughout the project.
So, if one functional test fails, it can be more easily resolved because you're

24 | P a g e
only testing one function of the deliverable. Fixing a small piece takes less time
and money, so the overall project is impacted less.

Collaboration

Collaboration, working with others, is where projects succeed or fail.


Through the partnership, the project team knows the customer is happy with
the deliverables, and the project objectives have been met. You present a
graph that shows how collaboration is front-loaded in waterfall projects and
consistent in agile projects.

 Supporting the development team

 Producing barely sufficient documents

 Streamlining status reporting so that information is pushed out by the


development team in seconds rather than pulled out by a project
manager over a more extended period of time

 Minimizing non-development tasks

 Setting expectations that change is reasonable and beneficial, not


something to be feared or evaded

 Adopting a just-in-time requirements refinement to minimize change


disruption and wasted effort

 Collaborating with the development team to create realistic schedules,


targets, and goals

25 | P a g e
 Protecting the development team from organizational disruptions that
could undermine project goals by introducing work not relevant to the
project objectives

 Understanding that an appropriate balance between work and life is a


component of efficient development.

26 | P a g e
WHAT IS SCRUM
Scrum is the most popular approach to implement agile. It helps to
manage software development with an iterative approach. There are
fixed-length iterations known as a sprint that allows shipping
software frequently. A race lasts one to two weeks, and at the end of
each sprint, the stakeholders and team members conduct a meeting
to plan the next steps.
The roles, responsibilities, and meetings are fixed in a Scrum. In
each sprint, there is sprint planning, daily stand-up, sprint demo,
and sprint retrospective. There are task boards and burndown charts
to follow up on the progress of the sprint as well as to receive
incremental feedback.

Roles in a scrum:

Product Owner

The vision for the software to be built is communicated by the


Product Owner. Product Owner not only focuses on the work to be
completed but also focuses on business and market requirements.
The PO interacts with the team as well as other stakeholders to build
and manage the backlog. The role of a PO is to motivate the team to
align them with the goal and vision of the project.

Scrum Master

Scrum Master is responsible for organizing meetings, dealing with


challenges, and bottlenecks. The Scrum Master interacts with the
Product Owner to ensure that the product backlog is ready for the
next sprint. He or she is also responsible for ensuring that the group
follows the Scrum process.

27 | P a g e
Scrum Team

The Scrum Team can be comprised of 5 to 7 members. In a Scrum


team, there are no distinct roles as a programmer, designer or tester
rather everyone has a set of tasks that they complete together

Steps in the Scrum flow:

Product backlog

The product backlog comprises a list of all the desired features of the
product. The Product Owner and Scrum Master prioritize the items on
the basis of user stories and requirements. The development team
refers to the product backlog to complete the task during each
sprint.

Sprint planning

In the sprint planning meeting, the Product Owner provides a list of


high priority items on the backlog. The team chooses the task they
can complete during the sprint and transfer the tasks from the
product backlog to the sprint backlog.

Backlog refinement

The team and Product Owner meet at the end of each sprint to
prepare the backlog for the next sprint. The team splits the user
stories into a smaller chunk of tasks and removes any user stories
that are irrelevant. The team also accesses the priority of stories to
reprioritize tasks.

28 | P a g e
Daily Scrum

A 15-minute stand-up meeting known as Daily Scrum is conducted


daily. The team member discusses the goals and issues related to
development. The Daily Scrum is held every day during the sprint to
keep the team on track.

Sprint review meeting

A live demonstration is given at the end of each sprint to showcase


the work the team has completed during the sprint in the sprint
review meeting.

Sprint retrospective meeting

This meeting is held to reflect on the success of the Scrum process


and is there any changes required to be made in the next sprint. The
team discusses the highs and lows of the earlier sprint and all the
improvements for the next sprint.

HOW SCUM RELATES TO AGILE

Agile is the software development methodology that focuses on


customer satisfaction by delivering shippable software frequently.
Scrum is one of the many approaches to implement Agile. Scrum is
suitable for certain types of projects where there are rapidly
changing requirements.

29 | P a g e
HOW TO TURN YOUR ORGANIZATION AGILE AND GET
ALL THE BENEFITS OUT OF AGILE SOFTWARE
DEVELOPMENT
Over the years, the software development process has seen various
enhancements. From the traditional waterfall model to Agile development
methodology, companies have upgraded their software development practices
to ensure that the final product meets the requirements of the clients and
includes the best-in-class features.
Organizations realize many benefits by adopting Agile as the methodology for
software development. Different types of Agile methodologies like Scrum,
Lean, Kanban, Feature Driven Development, etc., are being favored by
companies across the world to deliver better and more efficient services.
Before digging into the benefits, let us briefly understand what exactly Agile is.

Agile is a set of principles that apply iterative techniques in developing


software and allow teams to change their mindset towards building a better
product. Getting feedback from the customers throughout the cycle helps in
fixing defects and avoids the cost of rework.

Benefits of Agile Methodology

Let us deal with the various benefits which Agile has to offer for the
organizations:

Encourages Adaptability
Companies get a competitive advantage if their teams are capable of
responding to changes quickly and adapt to new processes as required. The
Agile methodology encourages flexibility over the plans and processes so that
any change does not disturb the project cycle. It helps team members to
become creative and learn how to deliver effective solutions in a changing
environment.

30 | P a g e
Key to Great Customer Experience
Agile methodologies like Scrum involve customers throughout the project and
address their changing needs by adopting an iterative approach. Gathering
feedback constantly from the client helps in aligning the processes with
their business goals. This is in contrast to the Waterfall method wherein the
customer doesn’t have any idea about the progress until the final product is
developed.
Increased Transparency Among Teams
Agile methodologies encourage communication between teams so that they
have a common goal to achieve. There is increased transparency among
product owner, development team, and scrum master as they hold discussions
through daily scrum meetings. Regular sprint reviews allow members of the
project team to understand how the work progress is at any given time.

Early Identification of Problems


One of the benefits of Agile methodology is that problems are identified at an
early stage. As regular testing is integrated during the cycle, testers can
identify bugs, and the developers can address them right away without this
affecting the planned work. This way, problems will decrease in subsequent
sprints.

The Final Product Contains the Most Useful Features


Better team collaboration, daily testing of the code, discussing possible issues
during sprint meetings, having clarity on business goals, and incorporating the
changing business needs leads to an efficient final product. The final product
evolves after addressing all of the needs and brings in all the useful features
that lead to a happy customer.

31 | P a g e
Low Probability of Project Failure
There are hardly any chances of complete project failure when organizations
adopt Agile methodologies for software development. As the project work is
reviewed after each sprint, the teams can understand if their approach is
bringing the desired results. Regular communication between the
development team, scrum master, and the product owner ensures that
feedbacks are taken into account to improve the functionality.

Final Words

The benefits discussed above are the primary reasons why organizations have
adopted Agile methodologies for their projects. This has led to an increase in
demand for professionals who have an in-depth understanding of Agile
principles and how can they be applied.

One of the best ways in which individuals validate their knowledge in Agile is by
pursuing Agile and Scrum certifications that are industry-wide recognized.
Many prestigious institutions offer certifications in Agile like EXIN, Scrum
Alliance, Scrum.org, Project Management Institute (PMI), International
Consortium for Agile, Scaled Agile Academy, etc., to name a few.

Achieving a Scrum Master Certification London can prove to be highly


beneficial as their demand is rising rapidly all over the world. Some of the most
sought after Agile certifications are:
 Agile Scrum Master (ASM®)

 Certified ScrumMaster® (CSM)

 PMI-ACP® (Agile Certified Practitioner)

 CSPO Certification

 SAFe® Agilist

32 | P a g e
Every Agile certification comes with a set of prerequisites that individuals need
to fulfill before becoming eligible to achieve them. For some certifications, it is
mandatory to attend training and then pass the associated exam apart from
having a certain level of experience.

For example, candidates need to attend 16 hours of scrum master training if


they wish to pursue a CSM certification. Undergoing Agile training can help
professionals gain a thorough knowledge of all the essential concepts and
prepare them for achieving such certification. So, begin your Agile journey
today and pave the way for a promising career ahead.

33 | P a g e
PRINCIPLES OF AGILE AND MORE ABOUT AGILE
MANIFESTO
The Four Values of the Agile Manifesto

The Agile Manifesto is comprised of four foundational values and 12 supporting


principles that lead the Agile approach to software development. Each Agile
methodology applies the four values in different ways, but all of them rely on
them to guide the development and delivery of high-quality, working software.

1. Individuals and Interactions Over Processes and Tools


The first value in the Agile Manifesto is “Individuals and interactions over
processes and tools.” Valuing people more highly than processes or tools is
easy to understand because it is the people who respond to business needs
and drive the development process. If the process or the tools drive
development, the team is less responsive to change and less likely to meet
customer needs. Communication is an example of the difference between
valuing individuals versus process. In the case of individuals, communication is
fluid and happens when a need arises. In the case of a process, communication
is scheduled and requires specific content.

2. Working Software Over Comprehensive Documentation


Historically, enormous amounts of time were spent on documenting the
product for development and final delivery. Technical specifications, technical
requirements, technical prospectus, interface design documents, test plans,
documentation plans, and approvals required for each. The list was extensive
and was a cause for the long delays in development. Agile does not eliminate
documentation, but it streamlines it in a form that gives the developer what is
needed to do the work without getting bogged down in minutiae. The Agile
Manifesto values documentation, but it values working software more.

34 | P a g e
3. Customer Collaboration Over Contract Negotiation
Negotiation is the period when the customer and the product manager work
out the details of delivery, with points along the way where the circumstances
may be renegotiated. Collaboration is a different creature entirely. With
development models such as Waterfall, customers negotiate the requirements
for the product, often in great detail, before any work starts. This meant the
customer was involved in the process of development before development
began and after it was completed, but not during the process. The Agile
Manifesto describes a customer who is engaged and collaborates throughout
the development process, making. This makes it far easier for developers to
meet the needs of the customer. Agile methods may include the customer at
intervals for periodic demos, but a project could just as quickly have an
end-user as a daily part of the team and attending all meetings, ensuring the
product meets the business needs of the customer.

4. Responding to Change Over Following a Plan


Traditional software development regarded change as an expense, so it was to
be avoided. The intention was to develop detailed, elaborate plans, with a
defined set of features and with everything, generally, having as high a priority
as everything else, and with a large number of many dependencies on
delivering in a particular order so that the team can work on the next piece of
the puzzle.

With Agile, the shortness of an iteration means priorities can be shifted from
repetition to iteration, and new features can be added into the next iteration.
Agile’s view is that changes always improve a project; changes provide
additional value.

Perhaps nothing illustrates Agile’s positive approach to change better than the
concept of Method Tailoring, defined in An Agile Information Systems
Development Method in use as: “A process or capability in which human
35 | P a g e
agents determine a system development approach for a specific project
situation through responsive changes in, and dynamic interplays between
contexts, intentions, and method fragments.” Agile methodologies allow the
Agile team to modify the process and make it fit the group rather than the
other way around.

The Twelve Agile Manifesto Principles

The Twelve Principles are the guiding principles for the methodologies that are
included under the title “The Agile Movement.” They describe a culture in which
change is welcome, and the customer is the focus of the work. They also
demonstrate the movement’s intent, as expressed by Alistair Cockburn, one of
the signatories to the Agile Manifesto, which is to align development with
business needs.

The twelve principles of agile development include:

Customer satisfaction through early and continuous software


delivery – Customers are happier when they receive working software
at regular intervals, rather than waiting extended periods between
releases.

Accommodate changing requirements throughout the


development process – The ability to avoid delays when a
requirement or feature request changes.

36 | P a g e
Frequent delivery of working software – Scrum accommodates this
principle since the team operates in software sprints or iterations that
ensure regular delivery of working software.

Collaboration between the business stakeholders and


developers throughout the project– Better decisions are made when
the business and technical team are aligned.

Support, trust, and motivate the people involved – Motivated


teams are more likely to deliver their best work than unhappy groups.

Enable face-to-face interactions – Communication is more


successful when development teams are co-located.

Working software is the primary measure of progress –


Delivering functional software to the customer is the ultimate factor that
measures progress.

Agile processes to support a consistent development


pace – Teams establish a repeatable and maintainable speed at which
they can deliver working software, and they repeat it with each release.

Attention to technical detail and design enhances agility – The


right skills and functional design ensures the team can maintain the
pace, continually improve the product, and sustain change.

Simplicity – Develop just enough to get the job done for right now.

Self-organizing teams encourage great architectures,


requirements, and designs – Skilled and motivated team members
who have decision-making power, take ownership, communicate

37 | P a g e
regularly with other team members, and share ideas that deliver quality
products.

Regular reflections on how to become more productive –


Self-improvement, process improvement, advancing skills, and
techniques help team members work more efficiently.

Agile intends to align development with business needs, and the success of
Agile is apparent. Agile projects are customer-focused and encourage
customer guidance and participation. As a result, Agile has grown to be an
overarching view of software development throughout the software industry
and an industry all by itself.

38 | P a g e
HOW TO APPLY AGILE PRINCIPLES OF PROJECT
MANAGEMENT
Agile principles are explicitly designed to increase the success of your projects.
Agility in project management encompasses three key areas:

 Making sure the development team can be productive and can


sustainably increase productivity over long periods.

 Ensuring that information about the project’s progress is available to


stakeholders without interrupting the flow of development activities by
asking the development team for updates.

 Handling requests for new features as they occur and integrating them
into the product development cycle.

An Agile approach focuses on planning and executing the work to produce the
best product that can be released. The approach is supported by
communicating openly, avoiding distractions and wasteful activities, and
ensuring that the progress of the project is clear to everyone.

All 12 principles support project management, but principles 2, 8, and 10


stands out:

(2) Welcome changing requirements, even late in development. Agile


processes harness change for the customer’s competitive advantage.

(8) Agile processes promote sustainable development. The sponsors,


developers, and users should be able to maintain a constant pace indefinitely.

(10) Simplicity — the art of maximizing the amount of work not done — is
essential.

39 | P a g e
TECHNIQUES YOU CAN USE TO UTILIZE IN ORDER TO
GET THE HOST OF AGILE SOFTWARE DEVELOPMENT
Here are seven elements of agile you can apply to your projects - along with
advice on how to tailor these to suit your specific requirements - to ensure you
remain ahead of the curve and extract the maximum value from the
methodology.

1. Iterative planning

The key to agile’s increased flexibility is an iterative approach to planning.


Essentially, this means that instead of creating a comprehensive blueprint at
the outset of a project (when understanding is at its lowest), planning happens
continuously, through a process of on-going inspection and adaptation. This
enables the direction of the project to change and evolve as understanding
grows, and further details of requirements emerge, as well as in response to
current market conditions, stakeholder input, and user feedback.

In a marketing context, some initiatives benefit from iterative planning. By


incorporating regular reviews into an on-going promotional campaign, for
example, you’ll be able to quickly drop activities that aren’t yielding results and
instead re-invest in more productive areas. You could also apply an agile
approach to an upcoming product launch, reviewing the priority of associated
tasks as new requirements come to light.

For a practical demonstration of iterative planning, check out this version of


the popular game of battleships, which shows how the approach works and the
benefits it offers.

40 | P a g e
2. Iterative delivery

As with planning, the Agile approach to delivery is also iterative and focuses on
the completion of individual features and tasks so that projects can go live at
virtually any point as a lightweight deliverable or Minimum Viable Product
(MVP). Different agile frameworks manage iterative delivery in different ways,
though, and the one that best suits you will depend on the specific
requirements of your organization and industry.

You may, for example, want to adopt a Scrum approach, where work is
completed in short and contained stages known as ‘sprints.’ Typically lasting
two weeks, working features are delivered and demonstrated to stakeholders
at the end of every sprint, to speed up feedback loops, minimize wasted
investment, and provide greater control over budgets.

In the Kanban framework, by contrast, a prioritized list of tasks (or ‘backlog’)


is used to manage activity, with limits placed on work in progress to ensure
that the most valuable items are delivered first and that bottlenecks are
identified and resolved at an early stage.

Of course, you could also adopt a hybrid model that combines these two
approaches - choosing specific aspects from each to create something that’s
uniquely tailored to your needs.

3. User stories

41 | P a g e
While not exclusive to the approach, user stories do align closely with agile’s
core principles and can help maximize the value being delivered through your
projects.

User stories take the form “As [user], I want to [task], so that [motivation]”,
which ensures that requirements are expressed with direct reference to the
user needs that are being fulfilled, and also makes them ideal for
communicating these requirements to all relevant project stakeholders in a
format that’s clear and easy-to-understand.

If this specific format doesn’t work for you, though, what matters is that you
communicate requirements in a way that maintains the qualities of a good user
story. The INVEST mnemonic can prove useful here:

 Independent

 Negotiable

 Valuable

 Estimable

 Small

 Testable

Tasks may, therefore, be “draft a blog post,” “identify valuable PPC terms,” or
“present the business case for a new strategic investment” - but there’s no
limit to their potential diversity.

42 | P a g e
4. Estimation and prioritization

Breaking your requirements down into clear, contained user stories (or similar
tasks) will make it much easier to assess the effort needed to complete each
unit of work, supporting and streamlining any subsequent estimation
activities. Additionally, agile promotes a range of techniques to help safeguard
the accuracy of estimates, such as planning poker and affinity estimation.

Once estimated, you’ll also want to prioritize your stories according to business
value, although, of course, exactly how this value is defined will depend on
your specific goals and objectives. However, you choose to prioritize, though;
it’s essential that - in line with agile’s iterative process - you regularly review
your prioritized list as your project progresses.

This will deliver you a backlog of tasks that are always up-to-date so that you
can be confident the most valuable features are being worked on at all times.
It also enables you to amend your backlog in response to any feedback
received - which leads me nicely on to.

5. Demonstrations, retrospectives, and stand-ups

Providing team members and the full stakeholder group with the chance to
regularly assess project progress, presentations, retrospectives, and
stand-ups are all critical features of the Scrum framework. Let’s look at each of
these in turn:

 These occur at the end of every sprint and involve both the core project
team and those stakeholders that may not be directly involved in the
day-to-day running of the project. As such, they offer the chance to capture

43 | P a g e
feedback that can then be used to inform subsequent prioritization and
delivery activities, as well as acting as a valuable project check-point.

 These also take place following the completion of each sprint, but rather
than focusing on the project deliverables instead allow the project team to
reflect on their performance - identifying what is working well alongside any
areas for improvement.

 Stand-ups. Stand-ups occur daily throughout the sprint and allow team
members to share what they achieved the previous day, what they’re going
to work on next, and any blockers they may be facing, to help maintain
project momentum and foster high levels of visibility.

6. Communication and collaboration

While the techniques listed so far all undoubtedly offer value to organizations
both within and beyond the software development industry, genuinely
unlocking the power of agile requires a cultural shift right across your team or
teams. Fostering effective collaboration, in particular, is vital, as this will
provide you with the insight needed to keep activity aligned with your strategic
goals and ensure you’re addressing real-world requirements and use contexts.

It’s essential, therefore, to look at how well your team communicates and
works together currently and put in place any training activities to ensure they
have both the understanding and skills needed to manage these activities.
Additionally, tools such as instant messaging systems and project
management solutions can also support productive communication (although
face-to-face will always be one of the most effective channels!), and you may
wish to consider introducing testing activities into your processes, to give you
end-user feedback at an early stage.

44 | P a g e
7. Team structures and roles

To ensure projects are delivered as efficiently as possible, many agile


frameworks recommend limiting core team size to between three and six, a
model that can help numerous industries to maintain focus and velocity.
Traditionally, of course, this ‘core team’ referred to developers producing web
and software solutions, but can be applied to anything from salespeople
making calls through to content strategists defining and providing the copy.

There are also typically several additional functions surrounding this core team
that it may be beneficial to introduce (you can even assign these roles to
existing team members, provided they’re informed of the scope of and reasons
behind their responsibilities):

 Product Owner. The Product Owner is responsible for making sure that
the work being completed delivers the most significant possible value to the
end-users, and maintaining this user focus throughout the project.

 Scrum Master. This is a particularly important role for sprint-based


approaches, as Scrum Masters help optimize team performance by
removing those blockers identified in the daily stand-up, alongside working
with other stakeholders to ensure the core team is adequately supported.

The presence of these two roles does not mean, however, that the team should
be micro-managed. Indeed, the goal should be to build teams that are
empowered to take ownership of tasks and make decisions while maintaining
on-going communication and collaboration to keep the project aligned with
your strategic goals.

45 | P a g e
Next steps

Hopefully, I’ve convinced you to explore further some of the agile techniques
introduced in this post. Before you begin your agile transformation journey,
however, it’s vital that you underpin it with a clearly-defined strategy, and the
following tasks can help you to achieve this:

 Conduct an ‘as-is’ audit

 Identify the most appropriate approach for you

 Create a training plan

 Implement a trial project/period

 Roll out across your organization

46 | P a g e
COMMON CHALLENGES OF IMPLEMENTING AGILE
METHOD
Challenges of Agile Development

Although there are many benefits of Agile software development, there


are also several common challenges that prevent many teams from
successfully scaling Agile processes out to the enterprise level.
In Forrester’s State of Agile 2017: Agile at Scale development study,
both large and small firms cited the following as the top 3 barriers to Agile
adoption:

1. People’s behavioral change:

Changing the way people work is difficult — the habits and culture of a
large development organization are typically profoundly ingrained.
People naturally resist change, and when confronted with an Agile
transformation, you may often hear people say things like, “that’s the
way we’ve always done it around here,” or “that won’t work here.”
Accepting change means accepting the possibility that you might not
currently be doing things the best way, or even worse, it may challenge a
person’s long-held values. It’s easy for people to keep their old behaviors
and processes—unless there is an excellent reason to make a change.

2. Lack of skilled product owners from the business side:

The Business Requirements Document (BRD) has been used for decades.
Yes, it has its shortcomings, but it’s familiar. Most of the people involved
in requirements – primarily business stakeholders and Business Analysts
(BAs) – are new to Agile. They don’t understand user stories and hesitate
to give up the BRD for something different because they view it as a

47 | P a g e
contract between them and IT. How will they be able to control the
direction of development without that contract?

Additionally, most Agile software development teams use an ALM tool,


which is where user stories need to end up for decomposition into
development tasks. Most business stakeholders and BAs, on the other
hand, still use Microsoft Word and Excel to author requirements. This tool
mismatch stifles the cross-departmental collaboration teams need to
realize the full benefits of Agile.

3. Lack of dedicated cross-functional teams:

The language used in the principles behind the Agile Manifesto—which


refer to the technical members of the Agile team as “developers”—has led
many to think that only developers, or what many people think of as
‘coders,’ are needed within an Agile team. However, the Manifesto’s
guidelines use the word developer to mean “product developer”—any
cross-functional role that helps the team deliver the product.

According to the Scrum Guide, a cross-functional team is a team that is


organized around customer value stream mapping and must include all
competencies needed to accomplish their work without depending on
others that are not part of the team. These teams deliver products
iteratively and incrementally, maximizing opportunities for feedback, and
ensuring a potentially useful version of working product is always
available.

Looking for a Tool to Support your Agile Software Development


Efforts?

Storyteller helps you easily plan and track your Agile software projects,
releases, and iterations with drag-and-drop simplicity using an intuitive

48 | P a g e
user interface. Storyteller synchronizes with downstream ALM and test
management tools to enable enterprise-scale Agile by automating and
orchestrating business-driven goals and measures into the software
development lifecycle.

Backlog items can be planned for the next iteration, providing the
opportunity to introduce changes within a few weeks.

49 | P a g e
UNDERSTANDING THE AGILE METHODOLOGY AND HOW
TO USE IT
Agile Methodology is a people-focused, results-focused approach to software
development that respects our rapidly changing world. It’s centered around
adaptive planning, self-organization, and short delivery times. It’s flexible,
fast, and aims for continuous improvements in quality, using tools
like Scrum and eXtreme Programming

How It Works

It works by first admitting that the old “waterfall” method of software


development leaves a lot to be desired. The process of “plan, design, build,
test, deliver,” works okay for making cars or buildings but not as well for
creating software systems. In a business environment where hardware,
demand, and competition are all swiftly-changing variables, agile works by
walking the fine line between too much process and not enough.

Agile Methodology Overview

It abandons the risk of spending months or years on a process that ultimately


fails because of some small mistake in an early phase. It relies instead on
trusting employees and teams to work directly with customers to understand
the goals and provide solutions in a fast and incremental way.

 Faster, smaller. Traditional software development relied on phases like


outlining the requirements, planning, design, building, testing, and
delivery. Agile methodology, by contrast, looks to deploy the first
increment in a couple of weeks and the entire piece of software in a couple
of months.
 Communication. Agile teams within the business work together daily at
every stage of the project through face-to-face meetings. This
50 | P a g e
collaboration and communication ensure the process stays on track even as
conditions change.
 Feedback. Rather than waiting until the delivery phase to gauge success,
teams leveraging Agile methodology track the progress and speed of the
development process regularly. Velocity is measured after the delivery of
each increment.
 Trust. Agile teams and employees are self-organizing. Rather than
following a manifesto of rules from management intended to produce the
desired result, they understand the goals and create their path to reach
them.
 Adjust. Participants tune and adjust the process continually, following the
KIS or Keep It Simple principle.

For training purposes, there’s a comprehensive, downloadable overview here.

Examples of Agile Methodology

The most popular and typical examples are Scrum, eXtreme Programming
(XP), Feature Driven Development (FDD), Dynamic Systems Development
Method (DSDM), Adaptive Software Development (ASD), Crystal, and Lean
Software Development (LSD). Teams generally pick one or two methods. The
most widely used methodologies are Scrum and XP, which dovetail nicely.

Scrum is a hands-on system consisting of simple interlocking steps and


components:

 A product owner makes a prioritized wish list known as a product backlog.


 The scrum team takes one small piece of the top of the wish list called
a sprint backlog and plans to implement it.
 The team completes their sprint backlog task in a sprint (2 weeks). They
assess progress in a meeting called a daily scrum.

51 | P a g e
 The ScrumMaster keeps the team focused on the goal.
 At the sprint’s end, the work is ready to ship or show. The team closes the
sprint with a review, then starts newsprint.

Here’s an example of how Scrum works: Bill meets with a customer to discuss
her company’s needs. Those needs are the product backlog. Bill chooses the
most important tasks to work on in the next two weeks. His team meets in a
daily scrum to target work for the day ahead and address roadblocks. At the
end of the sprint, Bill delivers the work, reviews the backlog, and sets the goal
for the next sprint. The cycle repeats until the software is complete.

eXtreme Programming. Often used with scrum, XP is an example of how


Agile can heighten customer satisfaction. Rather than deliver everything the

52 | P a g e
customer could ever want far in the future, it gives them what they need now,
fast. XP is centered on frequent releases and short development cycles. It uses
a code review, pair programming, unit testing, and regular communication
with the customer.

Here’s an example of how XP works: Bill builds a list of customer requirements


by having the customer tell “user stories” that outline the features. From
there, he creates a software release plan. The software will be delivered in
iterations, with one delivered every couple of weeks. The team works in
programmer pairs, using daily meetings to smooth roadblocks. The customer
provides feedback in the form of more user stories. The cycle repeats until the
software is delivered.

53 | P a g e
Benefits of Agile Methodology

The benefits of Agile are tied directly to its faster, lighter, more engaged
mindset. The process, in a nutshell, delivers what the customer wants when
the customer wants it. There’s much less wasted time spent developing in the
wrong direction, and the entire system is quicker to respond to changes. For a
more comprehensive list of benefits,

 Faster. Speed is one of the most significant benefits of Agile Methodology.


A faster software development life cycle means less time between paying
and getting paid. That, in turn, means a more profitable business.
 It increases customer satisfaction. With Agile, customers don’t wait for
months or years, only to get what they didn’t want. Instead, they get
iterations of something very close to what they want, very fast. The system
adjusts quickly to refine the successful customer solution, adapting as it
goes to changes in the overall environment.
 Values employees. Employees whose ideas are valued are vastly more
productive than those who are ordered to follow a set of rules. The Agile
Methodology respects employees by giving them the goal, then trusting
them to reach it. Since they’re the ones with their hands on the controls and
the ones who see the obstacles that crop up every day, employees are in
the best position to respond to challenges and meet the goals at hand.
 System eliminates work. By involving the customer at more than just
the phases of requirements and delivery, the project remains on-task and
in-tune with customer needs at every step. This means less backtracking
and less “out on a limb” time between the time we do the work and the time
the customer suggests revisions.

54 | P a g e
Best Practices

The list of best practices is long and involved, with dozens of tools to pick and
choose.

 Set priorities. A product backlog is a list of prioritized tasks maintained by


a product owner.
 Maintain small release cycles. The product should be released in
increments every 2-4 weeks, with stakeholders giving feedback before
proceeding.
 Use pair programming. Two programmers work side-by-side at a single
computer. This technique results in an identical degree of productivity to
separate programming but delivers higher quality.
 Refractor. Rework code regularly to achieve the same result with greater
efficiency and clarity.
 Use test-driven development. Code the unit test first to keep the
project on task throughout. Test-driven development as an Agile best
practice also produces greater employee engagement, since it transforms
testing from a tedious grind to a coding challenge.

Agile Methodology Tools

The list below shows some of the best tools on offer.

 ActiveCollab. An affordable tool for small businesses, ActiveCollab is easy


to use. This software development aid requires little training and provides
excellent support.
 Agilo for Scrum. Stakeholders get updated automatically on the project’s
progress with Agilo for Scrum. Features sprint reports and burn down
charts for better data mining.

55 | P a g e
 Atlassian Jira + Agile. This powerful project management tool facilitates
development by incorporating Scrum, Kanban, and customizable
workflows.
 Pivotal Tracker. This methodology tool is geared specifically for mobile
projects. It’s user-friendly after a brief orientation period.
 Prefix. This free tool from Stackify provides an instant feedback loop to
catch and fix bugs before they can deploy.
 Retrace. For a more robust solution complete with monitoring, errors,
logs, and more, Stackify’s Retrace provides app performance insights from
integration to QA to production, at the code level.

56 | P a g e
Benefits of Agile Development

Agile is a powerful tool for software development. It provides process and


efficiency benefits to not only the development team but also many
significant business benefits to the organization as a whole. Agile helps
product 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.

Here are the eight primary benefits of an Agile methodology:

1. Improved Quality

One of the most significant benefits of an Agile framework is improved


product 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.

By adopting Agile software development practices, organizations


can deliver solutions on time and with a higher degree of client and
customer satisfaction. By incorporating the ability to change, they are
better able to integrate feedback from demos, usability testing, and
customers into the product.

2. Focus on Business Value

Another one of the primary benefits of Agile is an increased focus on


delivering strategic business value by involving business stakeholders in

57 | P a g e
the development process. By doing so, the team understands what’s most
famous and can provide the features that give the most business value to
their organization.

3. Focus on Users

Agile development uses user stories with business-focused acceptance


criteria to define product features. By focusing features on the needs of
real users, each element 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.

4. Stakeholder Engagement

An Agile process offers multiple opportunities for stakeholder and team


engagement – before, during, and after each Sprint. By involving the
different types of stakeholders in every step of the project, there is a high
degree of collaboration between teams. This provides more opportunities
for the team to truly understand the business’ vision, deliver working
software early, and frequently increases stakeholders’ trust.
Stakeholders are encouraged to be more deeply engaged in a project
since trust has been established in the team’s ability to deliver
high-quality working software.

5. Transparency

Another benefit of Agile software development is that it provides a unique


opportunity for clients or customers to be involved throughout the
project. This can include prioritizing features, iteration planning, and
review sessions, or frequent software builds containing new features.

58 | P a g e
However, this also requires customers to understand that they see a work
in progress in exchange for this added benefit of transparency.

6. 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.

7. 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 before
each Sprint, the company 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.

8. Allows for Change

Lastly, a vital benefit of an Agile methodology is that, unlike a Waterfall


model, it 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 refine and reprioritize the overall
product backlog constantly.

59 | P a g e
KEYS YOU NEED TO SUCCESSFULLY IMPLEMENT AGILE IN
YOUR BUSINESS
Implementing agile methodologies (Scrum, Kanban, or any of their variations)
is a challenge faced by all kinds of organizations, project offices, and
managers. The advantages of being gained from this type of method for a
significant number of projects are clear, but implementing them is no simple
task. At many organizations, their implementation is often met with fear,
rejection, and obstacles. Here are a few keys to successfully implementing an
agile methodology.

1. Start with the Right Project


It is possible to apply the agile methodologies to almost any type of project,
but the successful implementation of these methods does indeed require
selecting the right projects, to begin with, to achieve the maximum benefit in
the shortest time.
Trying to apply agile methodologies to predictive or classic projects does not
usually lead to good results, as there is a considerable sense of losing control,
with teams (and management) tending to revert to methods they already
know. In contrast, experimental projects: presenting a lesser defined or highly
changeable scope with multidisciplinary teams and needing fast results:
provide an excellent opportunity for applying agile methodologies.

2. Clearly define the Team’s Role


The role played by a team in classic or predictive projects is significantly
different from their role in agile projects. The Project Manager plays a leading
role in the former, with control over all aspects of the project, whereas the
team has a much more critical role in the latter, and the Project Manager
becomes a facilitator of the methodology. It is essential to clearly define the
team’s role to implement the method correctly.

60 | P a g e
An agile project requires a multidisciplinary, self-organized, and self-managed
team, which is a confidence challenge for many organizations that tend to
apply managed and controlled methods. Understanding and building this type
of team is fundamental. If you can build a team that consists of relationships
between equals and a shared goal, a large portion of your future success will
be guaranteed.
3. Estimation of Effort is still Key
One of the most common problems when implementing agile methodologies
believes that estimates no longer need to be made. Even though it is no longer
necessary to make an estimate of the whole project, and we can focus on the
tasks for the next sprint or those with a higher priority in the product backlog,
it is essential to realistically estimate the efforts required for the jobs and
ensure they are equal or that the size difference between them is clear.
If a task has not been completed at the end of a sprint or a job is continuously
shown as “ongoing” in a Kanban project, we have likely made a mistake in our
estimation that should be corrected, the task should be broken down into more
manageable parts, and our commitments should often be revised. Flexible
management will ensure that the estimate focuses on the functions providing
the highest value or that we need to tackle most quickly. However, the
estimation itself is still relevant.

4. Know and control Limitations


Agile methodologies have limitations, and they must be taken into
consideration. There are scope, deadline, cost, and quality factors that need to
be met. Priorities might indeed be inverted, or the scope might be more
negotiable, but the limitations on deadline, cost, and quality remain and must
be managed.
These methods state that tasks should not exceed an absolute effort, define a
maximum Work in Progress (WIP) we can manage or establish a time-box by

61 | P a g e
using sprints. Limitations must be strictly maintained and not changed lightly,
as they are an essential part of their model. If we make changes or
adjustments and accept all types of changes, we are losing control.

5. Manage tension
Although it might seem contradictory, agile methodologies are more like a
long-distance race than a sprint. Some organizations approach these methods
as a way of moving more quickly – getting more done in less time – taking
advantage of the fact that teams are more deeply involved. This is true, but if
we want the implementation of these methods to last, we must manage team
tension.
Having a motivated, results-focused, self-managed, and efficient team is
possible with agile methodology. For these characteristics to last over time, we
need to ensure that the team also perceives an improvement to productivity
and not only a constant increase in effort and workload.

6. Metrics: “power without control is useless.”


These methods are compelling. They are capable of producing motivated
teams that obtain impressive results in genuinely short spaces of time.
Nonetheless, all this power does not come at odds with control. Agile
methodologies encourage us to measure, analyze, and continuously improve.
Metrics are the way to explicit project management based on real data rather
than intuition, opinions, or occasional emergencies. Speed, flow, and
commitment compliance are all key metrics that we should gather and analyze
to streamline our processes and improve our teams.

7. Quality
Quality means repeat business. Increasing delivery speeds, managing
estimates incrementally, or having a self-managed team does not mean

62 | P a g e
setting quality aside. It is imperative to deliver products quickly in agile
methodologies, but those products should also work; they need to do what is
required of them efficiently.
That is why it’s important not to leave quality until the end and incorporate
aspects of quality validation, revision, and measurement of all the items,
deliverables and products we generate during the project from the outset.

8. Remain to the methodology rigorously


Agile methodologies have few rules, standards, or products. It is essential to
follow the method precisely, especially at the start. It is better to change
nothing (or almost nothing) before gaining experience. If something seems
strange, have a little patience and give it a chance.
Scrum methods establish a series of roles, meetings, and stages that should be
preserved, experienced, and maintained for these methods to work as we
expect truly. It is possible to go from less to more in these methods but follow
their instructions precisely until you are comfortable with their use.

9. Revise and adjust the method


As soon as we have advanced significantly in the use of agile methodologies,
we can consider making adjustments to them.
It is essential to conduct reviews or retrospective exercises that allow you to
see what does and doesn’t work within your organization and make the
necessary changes to adapt the method to your culture style and
requirements. However, this should always be done after having tried the
standard models.
Agile methodologies are indeed flexible, very flexible, and that is why they can
be adapted to almost any type of project, organization, or team. With a little
experience, possible imbalances can be identified and changes, adaptations or

63 | P a g e
additions can be made to these methods to ensure they perfectly suit our
needs and circumstances.

10. Maximize visibility


One of the most important keys to the success of agile methodologies is
visibility. Implementing these methods is done “behind the scenes” at some
organizations, almost invisibly or as if applying this type of tool were
embarrassing in some way.

It is vital for this type of implementation to be made visible, open and public
so that the entire organization can see what is being done, how it is being done
and what has been achieved by doing it.
Avoid using private “Kanban” methods or hiding them when the project client
or sponsor appears. Be brave and show, explain, and harness the most
obvious advantages. There is no better ally than a project client or sponsor
that is involved in management, added to which agile methodologies enable
maximum visibility and maximum participation from all stakeholders. An agile
methodology is not an exception or an extravagance from an isolated team but
something that can be applied throughout the organization.

11. Manage expectations


Many teams and organizations that embark down this path believe that all
their problems will be solved as if by magic, that the client will never change
their mind, that products will no longer have defects or that nothing
“unpleasant” will ever happen during the project again.
Agile methodologies adapt very well to changing and stressful environments,
but they are not the solution to every problem. Managing expectations from
teams, clients, and management is essential to successful implementation.

64 | P a g e
The method may well not be perfect the first time around, that teams will feel
uncomfortable with certain aspects of the processor that the project will
encounter specific problems. This is completely normal. You will quickly see
that progress is being achieved, that progress is significant, and that the
results are very positive.

12. Select the right tools


Using a support tool when applying agile methodologies facilitates their
implementation at organizations. Having centralized support for sharing
information, measuring progress, and maintaining project control is highly
essential. With the right tool, teams will be able to work independently while
the organization can maintain control over project progress, costs, and
revenue, efforts.
Do not be fooled by tools that are free but wholly disconnected from the rest of
your organization. Agile methodologies are not an anecdotal or exceptional
process implemented by teams with highly unprofessional tools; it is an
important decision by the organization to adapt and improve. We are facing a
project management revolution that is allowing us – with the right tools – to
improve our performance, deliver high-value products very quickly, and
achieve great success.

65 | P a g e
KEY METRICS TO MEASURING AGILE SUCCESS
Choosing the right agile metric to measure rapid success is simple, right? I wish
that were the case, but in reality, selecting the correct agile metric can be a little
tricky.

So, how do you get the most out of your agile metrics? The 9th annual State of
Agile survey was reviewed, which compiles insights from nearly 4,000
respondents to find out how agile practitioners measure the success of their agile
initiatives.

1. On-Time Delivery

According to the State of Agile survey, 58% of the respondents* said they
measured the success of their agile efforts by on-time delivery.

With agile, our schedule is fixed, and our scope is flexed. What does that mean for
on-time? Well, time happens, so theoretically, we are always on time. But,
on-time is generally measured in context with the expectations about what will be
delivered. To measure and have visibility of what is being achieved, we may look
to the out-of-the-box metrics of the burndown or the burnup.

2. Product Quality

A total of 48% of the respondents to the survey said they measured the success of
their agile initiatives through product quality.

Quality is often measured in multiple ways, including looking at customer


satisfaction, revenue growth, and the technical aspects of testing conducted
throughout the development life cycle. With agile software development teams,
we’ll look at our velocity of completing working software with quality built-in. We
tightly couple continuous testing and inspection throughout the lifecycle of the

66 | P a g e
development, so we’ll continuously be monitoring testing trends as well as
continually inspecting build and code health.

For instance, in this testing trend chart, you can see the cumulative progress
around testing activities. Ultimately you want to see all green, but a large amount
of red along the line might reflect some issues in the codebase or process.

3. Customer/User Satisfaction

The survey found that 44% of respondents measured the success of their agile
initiatives by customer or user satisfaction.

As with all these benefits, there are multiple ways to measure the outcomes. In
the case of customer/user satisfaction, these include looking at the Net Promoter
score, sales figures, several support calls vs. several features delivered in a
period, or usage statistics of product or site capabilities.

4. Business Value

Approximately 44% of the respondents to the State of Agile survey stated that
they measured the success of their agile initiatives by business value.

And several of the principles of the Agile Manifesto recognize the importance of
delivering business value. Measuring business value is very explicit when we
know that there’s a contract for work to complete or a compliance need and fines
if we don’t finish the task. On the other hand, sometimes measuring value is

67 | P a g e
prospective or speculative in the sense that the market inputs drive decisions, and
the cost is often the best guess. Having a business value score applied to the
features to be delivered can measure value.

Here’s a sample epic cumulative flow chart based on value. The image helps you
see the delivery of anticipated business value as features and other significant
stories are complete.

5. Product Scope (Features, Requirements)

Another 39% of the respondents answered that they measured the success of
their agile initiatives with product scope.

Setting a goal around what to get done over the next three months, then tracking
status, and getting it completed is hugely rewarding. Having real-time feedback
as to the progress of work is valuable to everyone on the team, from the
engineers to the program managers. With agile software development projects,
you can always rely on the burndown charts, or visualize the progress of the cards
moving from left-to-right on the project kanban board.

68 | P a g e
6. Project Visibility

Project visibility was the measure of choice for 30% of respondents to the survey.

One of the best ways to build trust is transparency. That means having the plans
out in the open and making progress visible to all. Sharing progress at multiple
dimensions provides the different stakeholders with information that makes sense
from their point of view. Metrics that show features or overall progress against a
targeted plan can provide great insights.

The other reason visibility is essential is because we need to have alignment


among internal teams so they can best manage their work concerning component
or service dependencies.

Understanding the impact of one team’s work on another team is critical. By


looking at the dependency chart below, it’s easy to identify the stories at risk.

7. Productivity

According to the State of Agile survey, 29% of the respondents said they
measured the success of their agile initiatives through productivity.

The concept of productivity in an agile world is a measure of outcomes, not


output. So looking at burnup for a product or based on value is hugely impactful.
Merely looking at a burnup of the count of stories or features over time is a great
way to understand how much the team is delivering.

8. Predictability

Approximately 25% of the respondents from the survey said they measured the
success of their agile initiatives by predictability.

69 | P a g e
A predominant metric used to assess predictability is the velocity trend. For a
three- to four-month period, this shows how much work is at a sustainable
pace on average. A velocity that wildly fluctuates might reflect a team that is
changing, unpredictable work, or only a team that is still getting used to defining
work small enough to complete in an iteration.

A velocity trend chart like the one below not only helps you see the performance
but also gives you visibility into whether or not the team’s output is at a
predictable state – as this one shows.

You can always try to assess velocity based merely on the count of story cards
completed every week. This is usually the best indicator of predictability.

9. Process Improvement

Another 23% of the respondents said they measured the success of their agile
initiatives by process improvement.

A core tenet of all lean and agile mindsets is continuous improvement –


continually getting better. But how do you know you are getting better unless you

70 | P a g e
measure the outcomes? There are all the metrics above that help, but there’s also
the constructive cumulative flow chart, which shows how well work is flowing
through the lifecycle.

With this team level cumulative flow chart, you can see where bottlenecks or
slowdowns may exist.

Also, there’s cycle time – which helps us with planning and predictability. Cycle
time is a great metric to view over time to see if process tweaks and adjustments
are having an impact on productivity.

For instance, in this cycle time report, you can see the level of variability and
performance across the various estimated pieces of work.

10. Don’t Know

Just 11% of the State of Agile survey respondents said they didn’t know! Well, if
you don’t know the benefits, try to start looking at the metrics above. You’ll see
improvements in delivered value, better quality around what produces, a more
predictable cadence, and ultimately happier customers.

71 | P a g e
CONCLUSION
The Agile Method of software development does not guarantee success.
Problems can still arise in the development process. Communication among
team members can be faulty. Technology tools can fail. Customers can end up
being unsatisfied with products.

It’s also important to remember that with Agile, it’s not a one-size-fits-all
proposition. Different organizations have unique needs and challenges, both
internally and externally. What works well for one enterprise might not work
well for another.

But the potential benefits of Agile would seem to make the method worth
considering for any company that produces software. As noted in a report on
the Agile market by Transparency Market Research, “considering the rapid
technological development taking place, businesses today need to be dynamic,
be able to achieve faster-time-to market and at the same time reduce costs.
Technology is a critical factor in which the success of a business depends. This
calls for IT to be innovative, reliable, and adapt to changing requirements.”

Agile development “promotes a disciplined approach to processes and involves


checks and adaptations at various stages of software development,” the report
says. “This calls for accountability and results in encouraging the use of best
engineering practices, resulting in the rapid delivery of quality software and
business approaches aligned with customer needs.”

With the proliferation of technology, devices, and applications, the services


behind them have great importance, Transparency Market says, resulting in
the IT industry needs to manage the services it provides increasingly. This,
combined with the requirement to deliver more value, is likely to drive the
growth of Agile development services.

As more organizations move toward digital transformation and attempt to

72 | P a g e
enhance their data management capabilities, Agile will likely play an even
more prominent role. A report by consulting firm McKinsey & Company, “Using
Agile to Accelerate Your Data Transformation,” notes that an Agile approach to
data migration and management conveys some essential benefits, not the
least of which is to declutter the business-information landscape.

“Data from multiple databases, functions, and business units can be combined
and accessed more easily,” the report says. “Companies can realize immediate
value from the frequent release of minimally viable data-management
solutions. Through the data mining made possible by the development of a
comprehensive data lake, companies can also identify new business
opportunities. And if business units are involved in data migration from the
outset, they can seize these emerging opportunities more quickly or otherwise
help the IT organization prioritize data- and digital transformation initiatives.”

Agile is no longer just a methodology for software development or operations


management; the firm says: “It is becoming a critical capability for those
companies that want to manage their data more strategically and deliver
seamless multichannel customer experiences.

Technology and business leaders would be wise to familiarize themselves with


the Agile Method if they haven’t already. For many organizations, it represents
the way the work is in the age of digital transformation.

73 | P a g e

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy