Agile Methodology explained simply, for those unfamiliar. Great to change organisations from waterfall to agile ways of working. Step by Step. Agile Project Delivery simplified. Stakeholders will understand clearly what their role is in implementation. Answers common questions, what is a Scrum Master etc
What is Agile?
The Agile approach
In More Detail
What is Agile?
• A description
• Agile v Waterfall
• Why choose Agile
• Time Cost and Quality
Agile systems development is a group of systems
development methods based on ‘iterative’ and
‘incremental’ delivery of small chunks of work, where
‘features’ evolve through collaboration between IT and
It promotes adaptive planning, evolutionary
development and delivery, a ‘time-boxed’ iterative
approach, and encourages rapid and flexible responses
to business change.
It is a conceptual framework that promotes foreseen
small manageable stages throughout the delivery cycle.
"We are uncovering better ways of developing systems to
support business change, by doing it, and helping others do it.
Through this work we have come to value”:
Individuals and interactions over Processes and Tools
Working software over Comprehensive
Customer collaboration over Contract Negotiation
Responding to change over Following a Plan
That is, while there is value in the items on the right, we value
the items on the left more."
Agile Principles (manifesto)
Agile doesn’t work for fixed deadline projects – Quite the contrary, it works best in fixed
deadline projects, as this will focus collaboration.
Agile delivery only requires new tools – To be successful, Agile delivery requires cultural,
process, and tool changes to be made
Agile means no documentation – Wrong!.. Agile promotes ‘smart documentation’ used for
collaboration and delivering small efficiencies often. Its all about working smarter, not
Agile means no planning – Some upfront planning is required for Agile projects and should
include details such as development principles, an estimate of the work and tasks involved,
priorities, and overall budget to act as a guide for decisions during delivery.
Agile “out of the box” is good for every project – No.. When applying Agile to large
projects and distributed delivery teams or very large teams, some modifications and care
need to be taken to provide for their unique needs and requirements. Combinations of
methodology can be used to support governance structures.
Agile v Waterfall.. A comparison
Agile v Waterfall.. A comparison
** Documentation becomes part of the build process
Deploy Deploy Deploy Deploy
Why choose Agile?
Time, Quality and Cost
Features fixed therefore:
Time Quality and cost vary.
Time, Quality and cost fixed:
Controlled by varying the features, and
delivering ‘High Value’ features first
The Agile approach
• Scrum Roles
• Who is the Scrum Master
• Agile relationships
Scrum Master – Responsible for coaching and guiding the team, creating a trustful and
inclusive environment, facilitating team meetings and negotiations with the product
owner and removing team and organisational impediments. They keep the process
moving forward ensuring that the values and principals of scrum along with its
framework are followed. They socialise scrum and agile to the wider organisation.
Product Owner – Is the final authority on the requirements for the product. Responsible
for the product vision and improving return on investment. They manage the end user
and stake holder expectations, prioritizing the product backlog, release planning and
providing clear and testable requirements to the team. They collaborate with the team,
end users and stake holders ensuring that the goals are met and they accept the
software at the end of each sprint.
The Team – The team are cross-functional, autonomous and self organising. They are
responsible for estimating the size of requirements driving from a tactical perspective
making their own design and implementation decisions. They track the progress of
their own work with the guidance of the scrum master and the team commit to
delivering increments of software being accountable to the product owner for delivering
‘Scrum’ term that refers to a collaborative agile team management structure
used during agile delivery.
Traditionally, the project manager is a leader, a decision maker, a planner,
someone who manages the project and the team and is the person
accountable to the business for accomplishing the project objectives.
The ScrumMaster's role is more that of coach and facilitator, a role that sits
between the project and the customer. The ScrumMaster doesn't manage
the team that produces the work; instead, he/she supports the product
owner, coaches the team, and makes sure that Scrum processes are adhered
The ScrumMaster is responsible for the Scrum process, its correct and
continuous implementation, and the maximization of its benefits
Who is the Scrum Master? SM?
• Core Concepts
• Identifying the Requirements (Product Backlog)
• Epic Stories
• User Stories
• Prioritising the Backlog
• Delivery Cycle
‘Product Backlog’ – A list of items (requirements) that deliver
capability to the business. These are product based i.e. ‘Managing
clients’, ‘Creating legal cases’.
‘Sprint’ – Length of time agreed to deliver Items in the backlog to
the business. Usually 1-2 weeks.
‘Daily Stand-up’ - Daily meeting with all team members
(Business/IT) to discuss current tasks. Usually 15-20 Mins.
‘Epic Story’ – Narrative that describes an operational goal
needed to satisfy a strategic objective i.e.
“As an education lawyer I want to be able to create, amend,
delete and search for clients so that I can create and
education legal case, by attaching a clients information to a legal
‘User Story’ – Detailed breakdown of an Epic Story, based upon
a role, a task and a reason i.e.
“As an education administrator, I want to be able to search
for a client, so that if they already exist I will not be able to
create a duplicate client”
Identify Key project success factors.
Identify the processes in scope.
De-compose the processes into mapped
Logically group those tasks into Epic
Add the Epic Stories to the Product backlog.
Prioritise the Epic Stories using MoSCoW
De-compose the Epic Stories into User
Identifying the Requirements (The Product Backlog)
Identify the Processes
Define Epic Stories
ES : Assess Client
ES : Money
ES : Resolve Conflict
ES : Risk Assessment
Name of the story.. NOT a number.
Description and acceptance criteria (BDD)
Define any ‘Business’ rules i.e. Client Number
Break Epic Stories into User Stories
“As a ‘Role’, I want to be able to, So that I can”
“Given a Condition, When I do this, Then It should”
TaskRole Reason (Benefit)
EventInitial Context Outcome
User Stories example…
• User Story – :Adding a Client email address
“As a User I want to add a client email address, so
that I can automatically email the client”
“Given the Client has a valid email address, when
I click the email address, then my default email
client should open and their email address should
be populated in the recipient field”
User Story Register
ES: Assess Client :
(Epic User Story)
Story Name As a I would like to… So that…
“As a CRM user, I want to be able
to assess whether a client has a
conflict so that I can pass them to
a manager if necessary for
US: Client type Fee
Establish the correct client
I can assess the client in the
US: Data Level Fee
Collect the correct level of data I can proceed to a conflict
US: Check Data Fee
Check the collected data
against current data
I can establish if there is a
need for a conflict check
US: Send Data Fee
Send the data to the correct
They can resolve the conflict
Prioritising the Backlog & Sprint Allocation
User story Description Priority
ES: Assess Client Assess Client M 5 1
Money Laundering M 5 1
ES: Resolve Conflict Resolve Conflict S 7 2
ES: Risk Assessment Risk Assessment S 2 2
ES: Cancel Client Cancel Client S 1 2
• Size the stories
• Group User Stories into same size Sprints
• Deliver on Prioritisation
Developed in the 1940’s by Toyota.. To align inventory levels by consumption – “Pull’ environment..
Rate of demand controls production, and task based.
Define the tasks needed to deliver the user stories
Sprint 1: Assess Client
To Do In Progress Completed User Story
US : Client Type
US : Data
In More Detail..
In More Detail
• CDLC (Change Delivery Lifecycle)
• ITIL Structured
• Service Strategy
• Service Design
• Service Transition
The CDLC (Change Delivery Lifecycle)
Transition Methodology Agile DeliveryJADJRPBusiness Architecture
Product DeliveryProduct Definition
RFC Business case
Define Sprint Backlogs
JRP – Joint Requirements Planning
JAD – Joint Application Development
4. ‘Lean’ to ‘Agile’ delivery
Build and Test
Business/BRM Business and BA Business, BA and Team Business
5. Agile values to take away…
‘Agile’ is also a group of processes - ensure ‘Lean’ is also applied
• Time boxed sprints - “Divide and conquer”
• Collaboration – “Lets Keep talking”
• Deliver rapidly – “Small things often”
• Flexible – “Adapt to your environment”
• Manage Change – “Adapt to the business need”
• Joint Ownership – “Everyone has their part to play”
• Empowerment – “Everyone is a decision maker”
“Everyone together from the start !”