AGILE PM

EXAM

https://www.theknowledgeacademy.com/exams/

Photographic ID ready to show invigilator

Use personal email address

Invigilated exam online- will connect to zoom – 360 degree view of work area including desk – you
cant have paper- empty desk

Enter email into the voucher bit on knowledge academy website

Click on link, choose exam –agile foundation –Its going to ask for the workbook (w multiple choice
qs) -click preferred date – will ask the invoice number (IN JOINING INSTRUCTIONS)

eve0123274

PRACTIONER

-Agile PM practioner

Go through notes

Practice Exam

Delegate pack slides

Practice questions

Gavin’s guide

Write the index numbers in book

Draw tables in book

INTRO

 Culture driven
 First called DSDM –in response to waterfall not working well in terms of productivity, scrum
was created around this time
 Only methodology in the agile family that is FULL LIFE CYCLE
 DSDM will be used in exams instead of Agile sometimes
 Prince 2 was designed as a solution to the failures of waterfall method
 Agile was also an alternative to waterfall- but it is about finding solutions to problems and
COLLABORATION- working with the customer – it is an approach
 Prince2- 26 mandatory management products
 Agile –14 management products –only 2 are mandatory (very adaptable)
o EG. Timeboxes- 2-4 weeks if you needed a timebox of 5 weeks, you can have that if
you can justify it – but if exam says the timebox is 5 weeks that wrong because
you're relying on best practice
  Agile preferred by NHS, BBC, national defence, gov organisations

DSDM AND AGILE

 WHAT is Agile?
o A generic description of a WAY OF WORKING
o Waterfall is flawed because the first three stages you don’t build anything its just
spec design and plan then its handed to the delivery plan after half the project cycle
– then the delivery team has to respond to that and the management team have to
respond to them and make it work
o Developers (suppliers) ended up reforming the system by taking out the first two
stages and instead planning by asking what the customer wants then build and test
it immediately (fail-fast-learn-quickly=quality) also implemented the final deploy
stage throughout the process so would do handovers frequently- this was called
rapid solution development (RAD)- this developed into DSDM
o AGILE BUILT QUALITY INTO RAD –the only FULL PROJECT MANAGEMENT LIFE CYCLE
o Agile IS EDUF (Enough detail up front) not BDUF (big design up front)
o Flexible –very collaborative with the customer, to make sure what is built exactly
meets their needs and expectations –detail emerges and is prioritised over time

PROJECT- need to bring around change, temporary, uncertainty, cross functional

Agile approaches

 LIGHTER agile approaches development focused (management techniques)

 SCRUM
 KANBAN
 LEAN
 Extreme Programming (EP)
 Extensive agile approaches, typically PROJECT focused
 DSDM- only approach that manages A-Z of life cycle
 SAFe

WHAT Agile approach is best for PM

Complex environments require fuller agile approach (scaled framework when people start writing
written reports)

Supporting the management and delivery of projects –FULL LIFECYCLE

Corporate culture

Rigor built in and focused on the right solution by understanding business needs through
collaboration

Customer sometimes doesn’t know what they want –this will emerge through the life cycle and we
work in close collaboration with them

WHAT AGILE APPROACH

DAILY stand-up and business ambassador makes agile work

So if with agile you don’t do reports, its not as formal and theres tonnes of colab does that eleave
room for more mistakes –not about mistakes but fail-fast and there are documents but they are not
detailed

With prince 2, when you want to make a change you need to get authorisation through various
levels –this process takes weeks.

Agile is more dynamic, no reports but direct collaboration with the customer –instead of
reporting issues, you deal with the issue (instead of reporting) and speak to the Project manager and
they will deal with the issue –PM will observe the daily stand up and will know if there are potential
issues

4 variables (like tolerances in prince)

Features

Quality

Time

Cost

You can alter each variable but you must maintain the return on the investment

Getting Quality right in Agile is essential:

 Feasibility
 Foundations-planning stage
 Evolutionary development -Delivery stage
o Within the timeboxes there are increments, each increment will produce something
potentially deployable =those increments will add up to our deliverable
o Timebox-what if we need more time to develop – drop some requirements the
customer has asked but make sure to deliver the minimum –when the less
important requirements are dropped they don’t need to ask the PM –the PM only
finds out till the next day at the stand up
o Close- out of a timebox= all business stakeholders attend and approve the next
timeboxes or any changes they want to implement- collaborative decision

CHANGE= SCOPE CREEP – do we allow these other (CHANGE) requirements? Can we do extra
timebox, is the budget going to be extended? -if the customer is allowing this then fine –This is
Archimedes approach

Prioritisation of requirements using Moscow

The 8 Principles

 Focus on the business need-

o SOLUTION development team members –subject mater team members –they
understand the customers and priorities of what needs to be built (Moscow)
 o BUSINESS CASE should be shared through all levels
o Make sure senior level are committed and still sponsoring the project- they are
accountable for the success or failure of the project- at the end of each timebox we
show and tell what we have done –every 4 weeks
o Figure head NEEDs to attend the show and tell, there are no reports and they need
to show their commitment
 Deliver on time
o MVP- minimum viable product – need to deliver this at a minimum then extra
customer requirements
o TIMEBOXES: WE don’t extend our timeboxes
o Timebox on time= increment on time =project on time – PM will never ask for the
timebox to be extended
 Collaborate
o Solution development team: By asking the customer questions and produce
samples/prototypes - see what the customer likes/dislikes
o One-team culture
o Putting something in writing doesn’t always work –direct business involvement –
business Visionary (BENEFITS AND REQUIRMENTS/SENIOR) and business
ambassador (will work with the solution development team who will review samples
and make decisions= accurate solution)
 Never compromise quality
o Understand expectations
o Know customer qual and achive it
o We test early and see if it works early –fail fast –document appropriately –only add
doc if it ADDS VALUE
 Build incrementally from firm foundations
o 2 phases- feasibility –is this product achievable and foundations- plan our project w
just enough detail without trying to decide how to do everything but development
team will start delivering
 Develop iteratively
o Thoughts, action and conversation eg. Testing and failing and getting feedback and
knowing what to implement in second cycle
 Communicate continuously and clearly
o Work shops, modelling, timeboxing, daily sand-ups –enable rich communication
o Documentation only when it adds genuine value
o Manage stakeholder expectations at all levels
o Always aim for honesty and transparency within team and external
 Demonstrate control
o Transparency will also demonstrate control
o Sharing everything everyone needs to know
o Appropriate level of formality and openness to control what is going on –the PM will
usually just know what is going on –no need to read a report

PRINCIPLES –top TIPS

 Make principles visible so everyone understands importance

 Encourage team members to flag something up if a principle is broken
  Breaking one or more principles means behaviours being adopted pose a risk to the
project and these need to be addressed
 Ensure demonstrate control principle is not seen as ‘just a PM issue’
 Consider organising a short workshop at the

Cargo CULT- when you stop being agile- when you don’t follow all of the principles=wrong
results and returns

TEXT BOOK -Page 68/60 +roles and responsibilities p 31-35 alien diagram – write notes about the
alien diagram –accountable for bc, visionary, technical business coordinator solution – ready roles
and resp foundations and name the diagram

HOMEWORK: How principle foundations look in digging deeper – put the roles and resp on the
diagram

Factors Instrumental to Success- ISFs

 Embracing the DSDM approach

o we either are or not –accept the approach is agile
o How mature is agile- have people done this with agile before?
o No place for micro-managing in Agile
o Obtain, retain, develop –agile thinks in this way to maintain stability in team
o No need to bring in new people because it will actully cause disruption and mess up
the flow
 Effective solution development team
o Agile hates overtime- costed overtime =slippage on cost, free overtime =reduction in
quality and absentism –loss of a stable team
o Collection of skills and dicipline –individuals with depth not jack of all trade , soft
skills, good business understanding (understand the customer and what we are
building)
o Team size- 7 people +- 2 either side (best practice)
 Business engagement –active and ongoing
 Iterative development, integrated testing and incremental delivery
o Testing needs to happen throughout
 Transparency
o No covering up mistakes
o Open attitude

AGILE DOCUMENTATION: Project Approach Questionnaire

ROLES AND RESPONSIILITIES

 Alien baby (diagram)

o Orange- customer interest
 o Green- solution/technical
o Blue-management interest (except for team leader because they don’t carry
authority)
o Grey-process interests –Ad-Hoc (they come in as and when, they are bought in when
the project needs them)
 You can think of the diagram as horizontal with the smaller circle to the left and big circle to
the right
 Sharing roles- one role can be shared providing they have the time skills and knowledge and
no conflict of interest eg. PM can be a TM but they must realised what hat theyre wearing at
what time.

Project level roles

 Must be commited and available

 They must be trustworthy- able to do their job to best of ability
 Give teams the environemnt and support- tools to do their job
 Freedom to fail fast and learn from mistakes

Business Sponsor

 Responsible/accountable for Budget and business accountability/business case = SPONSOR

 Most senior level
 Must be committed and proposed solution
 Make financial decision
 Committed to agile approach for delivering the project
 PM ensures the sponsor always remains aware of what is happening on the project –ideally
they agree on a common position on any issues in advance (this wont be issues they would
be risks)

Business Visionary (voice of the customer)

 Single person activly involved to provide a clear vision

 They will be take control of business case and explain the vision to everyone else
 Interperates business needs of sponsor and ensure everyone clearly understands the
strategic direction
 Lots of communication to know what the customer wants and explain that to everyone
 BV will tell us requirements and BENEFIITS
o Benefits realised through project build because we are working collaborativly
o BV can see benefits coming to fruition during the build but sometimes you only see
them post-project (eg when the success can only be measured when they go live)
 PM ensures visionary continuously communicates through project life cycle as well as
creates and promotes the business vision during feasibility and foundation stage and during
the evolutionary development, the PM ensures the visionary participates in end of timebox
reviews and project level re-prioritisation and re-planning

Technical coordinator

 Ability to answer tech qs or they know who do to and ask

 Involved in tech direction, do tech solution team know their direction
  Provides the glue that holds the technical aspects
 Good relationship with the BV –the TC needs to say realistically weather the benefits can acc
be achieved
 PM Ensures TC continuously communicates through project life cycle as well as drives
activities to ensure firm foundation, sensible agile development approach that is agreed with
all members of SDT and participates in end of timebox reviews and project level re-
prioritisation and re-planning

Project Manager

 Management style
o Are we good for the kick off
o Do you need help with a room for show and tell
o Hgih level agile-style leadership
o Removing barriers
 Collaborates with SDT and other stakeholders to agree delivery plan
 Monitros progress against delivery plan
 Manages risks and issues as they arrise (immediately)
 Handles problems escalated from SDT
 Attends daily stand-up meetings as an observer

Eg. Dan keeps coming late to the stand up –who will sort this issue out – solution development team
–solution eg. Team manager will Push it back 5mins but if it’s a performance issue then it will go to
PM

Business Analyst

 Walking oracle/spreadsheet
 Involved in all aspects of the project
 Analyst will write business case –approved by visionary
 Ensures businesses needs are properly analysed and correctly reflected in evolution of
solution
 FULLY INTEGRATED WITH Solution development team- support w forecasting or data
 Facilitates relationship between business and technical roles
 Capturing info discussed in collaborative meetings
 Not a manager, does not carry authority
 PM will work together with BA to ensure the right solution effectively evolves and dealing w
issues, PM will also encourage BA to have just enough analysis, design and documentation in
early phases

Business Ambassador -REVISE

 Key business representative within solution development team

 The more the solution dev team works w the business ambassador, the more they will
understand the details of the wants and needs of the customer
 During foundations- provides significant input into the creation and prioritisation of
requirements
 During evolutionary development
o Will approve if the initial 1 is ok or if there's a need for a 1.2...1.3 etc
  Responsible for day-today basis between project and business
 Knows the intricate details of the product in question eg. Checkout places (store manager
 The BV will be informed every day by the BA
 Authority to make decisions on behalf of visionary

Team Leader

 Part of the Solution development team, also chosen by the team (maybe for technical
knowledge)
 Very rare a team leader is just management -they’ll be a developer or a tester, specialist but
they will help the team coordinate and move forward
 Facilitate daily standard
 Don’t carry authority, not a manager
 PM and TM will focus on diff levels of detail and day-to-day interactions w different project
level roles and stakeholders, will work with SDT and business and technical advisors
 Relationship works best when PM participates activley in timebox review points and
observes the daily stand ups –continual coms and in a supportive manner peer to peer

Solution developer

 Interoperates business requirements and makes a solution

Solution tester

 Fully integrated with SDT

 Performs testing in accordance with agreed strategy

Business advisor

 Peer of business Ambassador

 Supports BA on ad-hoc basis, they provide specialist input to development or testing
solution

Technical advisor (contractor)

 Provides specific technical input to the project but we don’t need them all the time
 Advising from the perspective of those responsible for
o Operational management
o Operational support
o Ongoing maintenance of the solution
 Contractors/part time staff should come in when daily stand up happens +vice versa

Supporting Roles

 Workshop facilitator
o Planning organising and managing workshop process
 DSDM Coach
o Helps team w limited experience to get most benefit from DSDM
o Needs to have real practical experience
o Certified and qualified

PM +SDT
  PM engages with SDT
o Informally
o As an observier
o Facilitator
o Empowerment with control
 Ensures sdt understands objectives agreed at the beginning and importance of meeting
these, esp timebox objectives (if not PM can manage by exception and exert control )
 PM is only proactive in sdt internal issues when they’re not being solved

TOP TIPS

 Get a good business ambassafor

 Have only one sponsor
 Have one visionary –multiple causes confusion
 Use DSDM modle
 Consider discussing the responsibilities for each role with the role owners
 Make every effort to embed solution testers within SDT- fail fast learn fast

3 Variables that are fixed

 Time, Cost and Quality,

 Features are variable

Fundamentals of Agile

Common sense/pragmatism

Three parts of an iterative cycle

 TAC- thoughts, action conversation

Name of document that tests INSTRUMENTAL success factors

 PROJECT APPROACH QUESTIONNAIRE

o This happens in Phases
 Feasibility
 Foundation

What is the length of a time box (

Min- 2 weeks

Max- 4weeks

IF ITs 5 weeks in the exam that is wrong because it is not best practice
EXAM: ASSOCIATE BUSINESS AMBASSADOR WITH BENEFITS AND SDT

MUS-minimum usable subset

 Minimum viable product that can be tested

 Lean start up

Ready fire aim –when the customer tests your product after the project ends and it goes live –
companies lie apple and microsoft use this

DAY 2:

PHASES OF AGILE PM

GDPR-General data Policies and regulations –need to do it to avoid a consequence or bring a change-
this could be a trigger for an agile project

PHASES

TOR- terms of reference (mandate) (scope summary)

Feasibility

 Is this project VAD (viable, achievable, desirable)

 Does project warrant further investment (sponsor decision at the end of feasibility phase
through go/no go gate -determines if we go into the next phase
 Is it a no/go or is it something we can achieve?
 A project approach questionnaire is also created
 Sponsor, visionary, ambassador, business analyst, PM involved
 Committing moving into the next phase (not whole project)
 Terms of reference will morph into BUSINESS CASE –Terms of reference are broken down
 High level??????????????

Foundations

 Plan it (VAD)
 PM+SDT
 SDT are asked for expetise when making a plan –making them feel empowered
o WHY ARE SDT INVOLVED
 Already thinking of solutions
 They can approve the plan in this stage and see if its actually plauisble
 They start to develop as a team together and become cohesive before
actually getting into the development stage in the timeboxes
 They can identify the complexities and prioritise what is most difficult
 But for example the customer might say no the component that is most
important is xyz because that’s what his bosses are interested in
=COLLABORATION

Evolutionary Development

 Delivery plan not set in stone in an Agile world

 Split up in Increments A,B,C
  Increment A: We think we are going to take 3 time boxes to create a screen
o We need to have a plan for the first time box
o What comes out of timebox 1 might affect time box 2
o End of each time box =show and tell to customer
o Inside the timebox is ITERATIVE DEVELOPMENT
o We don’t plan for the next time box because its so uncertain it can change last min
o First time box is planned in foundations
o PM might link up with SDT for a workshop and get their opinions
 Increment B: Payment system is straightforward only 2 time boxes
 By end of increment B: we will have a potentially working system
 End of increment C –deployable product
 Nothing more than 100 requirements, more than that and we are dealing with big design up
front
 After final increment, DEPLOYMENT will happen
o This can be a handover to the customer and they sign for it
o Can also be training (how to use it)
o Installing product
o Shipping product
o Has to be in live operational use from day 1
o End-to-end test before handover (dress rehearsal)
o Post-product –problem w product, there needs to be another timebox to fix (this
should be in the scope of the project)
o Must inform the visionary in order to understand if they still want the product –
workshop
 DETAIL WILL EMERGE OVER TIME

DEPLOY

POST PROJECT

Increment

Timebox- will come up with a solution

 Each timebox is bulding up a COMPONENT –you are getting budget for one timebox of
10,000 by the end of that incremnt you need to hand over a tangible component (something
meaningful to the customer –could be a proof of concept or theory –can this even be done
 End of each timebox –should we carry on, are we happy? -informal go/no go gate
 Lowest level of detail
 Abmassador monitors whats going on in the timeboxes and communicates w the visionary
to understand the customer better
 Timebox on time=increment on time =project on time
 You will know how the project is going through daily stand up –PM will know

TWOSTYLES OF TIMEBOX

o Structured
 INVESTIGATION
  Discussed the requirements
 SMART principles, specific, measurable, agreeable, realistic, time
 Acceptance criteria from BUSINESS AMBASSADOR –if we don’t get
this we will end up with scope creep!!!
 Understand detail and priorities to be done
 Review dependencies
 FIRST Timebox plan and risks
 REFINEMENT
 Iterative development
 Work on solution in agreement with moscow priorities

CONSOLIDATION

 Sign off
 Assess impact of what has been delivered
 Build on good experience
 Avoid repeating same mistakes
 Complete final testing and complete actions from refinement
 Last TIMEBOX in increment will come with a show and tell which will
also be a handover
 Any products not meeting acceptance critera (specified by
ambassador) deemed as ‘not delivered’
o Free-format
 No such thing as unstructured time box
 Don’t want too few requirements because the SDT will be too lax laise au
faire
 Refelects styles used by other agile approaches eg. Scrum sprint
 Used when DSDM structured timebox is not helpful or possible
 Know show and tell is straight forward because they don’t need to invent
anything, they just build the solution
 But when something is very complex and imperical- this is when stuff is just
built and test (trial and error)- straight into iterative development thought
action conversation
 Daily stand up all the way through but because its very complex and
unknown, they need business ambasador very close –consistently available
for review and feedback
 Timebox review record –where money is being spent on
o Kick off and closeout in BOTH styles
o Kick off- beginning
o ATTENDED by BV, technical coordinator, PM, Business Analyst, appropriate
members of SDT including the Visionary

Pg.54-55 or p.123

Management Products

 Document that’s used to define monitor or control a product

 We use these products to explain to people and make them know what to do in the event of
 Prince2 =26 management products
  Agile=14 (2 mandatory)
 Your business case can be an email -that’s how informal it can be

Product roles and responsibilities

RACI –

 RESPONSIBLE (PRODUCE)
 ACCOUNTABLE (SIGN OFF)
 CONSULTED (OPINION/IMPUT)
 INFORMED (FYI)

PRODUCTS (DOCUMENTS- ISH) (phases in red)

Pre Project and the Agile PM

 Sponsor and visionary only at this stage (they can also be a combined person)
 No PM involved in the Pre-project
 Ensures the right projects are started
 Ensures projects

TERMS OF REFERENCE GOVERNANCE DOCUMENT

 auditable (evidence) -high level explaining any drivers and change and prioritisation

Feasibility and the Agile PM

 PM, BA, BV, TC, BS

 Is the project feasible
 VAD, Doable?
 Plan and resource foundations phase
 By the end, the sponsor should have enough info to make a decision

FEASABILITY ASSESSEMENT

 Provides a snapshot of evolving business solution and management products

 Sponsor uses the feasibility assessment to give the go-ahead in the form of an email, a
document, a text it doesn’t matter, they just have to agree on the commencement of the
project.

Business case-evolutionary

 Provides a vision and justification

 Describes incremental changes to the business

Prioritised requirements list (PRL) -evolutionary

 Describes, at high level, the requirements the business needs to address

 Indicates priorities with respect to meeting project objectives
  Considered in feasibility
 Baselined at end foundation to define scope –full detail emerges during evolutionary
development – where it gets broken down from bolder into rocks into stones
 SDT will help on this in order to explain specialist terms
 This will take place in the form of a conversation

Feasibility :10max and not moscow-that would be going into detail

Foundation- 100 max and moscow

Project management through the life cycle-95-95 (highlight feasability) on this page (94) and
foundations on the margin of 95 and 96

Take any management product of 94/95 then turn over to foundation(p.96) and read the same one –
TAB

130-TAB 113-TAB

DELIVERY PLAN- can be story map, white board, post it notes, PM software(jeera) –people need to
see the state of play within 3 metres –team needs to know whats happening

For foundation you don’t need detailed knowledge of each management product –for practitioner
you do need to kknow – tab the sections you need so its easy to find

Culture of agile vs prince w –p115 -TAB

SOLUTION ARCHITECTURE DEFINITON (SAD)-evolutionary

 The what
 High level design framework for solution
 Level of detail makes solution scope clear without constraining evolutionary development
 Talk about operating systems, process etc
 Eg. Have the sdl been to the supermarker? They’re developers but we cant assume they
know the environement of where the product will function in
 But we cant tell them how to do their job –advice on regulations, floor plan etc

DEVELOPMENT APPROACH DEFINITION (DAD)- evolutionary

 The How
 High level definition of tools, techniques, customs, practices and standards
Delivery Plan –evolutionary P.103

 High level schedule of increment for project

 Schedule of timeboxes for the next increment
 Can be gant chart, excel, white board etc...
 Delivery plan will need to be updated at the end of every timebox

MANAGEMENT APPROACH DEFINITION (MAD)

 Management of the project

 Considers Communication, directory of roles, what to do in event of escalation from PM
perspective

Foundations and the Agile

By end of foundations: Prioritised requirements list- moscowed +requirements for first increment
and timebox

SAD AND DAD + MAD- updated

FOUNDATION SUMMARY

 Snapshot of evolving business solution and managament products

 Products must be mature enough to contribute to decision on whethere the project is viable

Evolutionary Development and the Agile PM

 The pm participates in timebox kick off and close out

 Ensures people are committed
 Manages engagement of ambassador
 Manage by exception –what authority people have

EVOLVING SOLUTION

 SDT
 Scrapbook of what took place during the project

TIMEBOX PLAN

 Delivery team will use to plan their day

 So they know what they're doing each day
 PM software-whiteboard
 Self organising
 Not mandatory

TIMEBOX REVIEW RECORD

 Can be completed during timebox

 Describes what has been achived up to that point
 Each timebox is a section –look at timebox structure
Deployment and the Agile PM

 To bring a baseline of evolving solution into operational use

PROJECT REVIEW REPORT

 What went well etc, differently, issues, lessons learnt etc

 But it can be 12 months you're covering –agile makes it easy, it says write project review
report at the end of each increment. Use timebox review records for proj review report -
don’t wait till end of project, write it as you go

Post Project and the Agile PM

BENEFITS ASSESSMENT

 Governance document- with evidence of success or faliure

 How benefits have been accrued and fed back to project sponsor
 There could be another phase to that project

Msp software for Prince2

Jeera/jira software- agile

The daily stand-up

 People stand up to do this

 Allow 2mins per person +2mins optional
 What they’ve achieved and are planning to do
 Issues, blockers, barriers
 Idealy done w a white board
 SDT participants in the daily stand up -

Deliver on time –Combining MoSCoW Prioritisation and Timeboxing

MOSCOW
Must have

 minimum usable subset (guaranteed)

 Can't take up more than 60% of timebox effort

Should have

 Important but not vital

 May be painful to leave but solution is still viable
 May need work around
 20% timebox effort

Could have

 Wanted or desirable
 Less impact if left out
 20% timebox effort

Wont have this time

Will not be delivered in this timeframe

RUNNING OUT OF TIME= Descoping: from timebox turn a could have into a wont have (we’re not
never doing it butnot in this timebox) -customer might be fine without it after they see what is
built, they might decide to do that in the post project, they might see that it is really important

Sdt- authorised to change could haves-wont have but not should haves (they may be empowered
in some occassions)

it is ESSENTIAL that Visionary and sponsor understand Moscow –has to be explained

You need to know if they will cancel the project if you leave this for a later stage or give it lower
prioritisation –you need to know if its ok to move something to post project – you need to
understand if they have changed their view to seeing something as a must –if the team thinks this
must is tough –that expectation needs to be MANAGED –through transparency

Making MoSCoW work

 Agree up front how priorities will work

o Should haves are non-negotiable
o Should haves and could havs are subjective
o Discussion facilitated by the PM and BA
 Majority of prioritisation starts at foundations but priorities continually reviewed
o They change over time
 When new requirements added, check impact
o On project and on Moscow
 At end of increment, all requirements not met are re-prioritised according to the need of
the next increment
  Use Moscow to manage business expectations
o High % of should haves and could haaves provide optimum contingency
o If its must have heavy –its going to compromise the project
 PM responsible for ensuring Delivery plan is realistic and achievable
o Challenge the visionary if they keep coming up with too many must haves- has to
be escalated to the sponsor

Prioritisation- who decides?

 Are all must haves non negotiable

 -must have= deliver this or we cancel the project
 OM or BA may change less obvious must haves
 BV and BA have the final say
 The business sponsor POV
o Expects must haves
o Typically also expects mmost of should haves to be delivered
o Dsdm recommends 20% contingency for could haves –10% is the normal

Empowered teams & change

SDT being empowered –REMEMBER THIS INCLUDES BUSINESS AMBASSADOR

VISIONARY –can change these prioritisations and PM must check the % of efforts –the SDT doesn’t
have authority but they are empowered to give their opinion

Ensure close-out performs a retrospective to feed learnings into next Timebox –SDT (good vibes)

OTHER DSDM PRACTICES

Facilitated workshops

Success factors

 Trained workshop facilitator who knows what the Right venue, right environemnt will be
 Flexibility in format within clearly defined objectives
 Through preparation (by facilitator + participants)
 Ability to build in outputs from previous workshops
 Decisions and agreements not forced
 Workship report distributed to participants soon afterwards

Benefits

 Rapid, high qual team decisions

 Greater buy in and ownshiio from stakeholders
 Clarification of issues and enhanced coms
 Building team spirit and consensus
 Bruce Tuckmans’ Team Roles (In agile the forming should start in foundations phase and by the
evolutionary development it should be norming to ensure success)

 Forming- normal vibe when people who don’t know each other are-reserved not talking
 Storming –alphas betas self preservation societies –these all form in this stage
 Norming- beginning to understand each other, form better relations, work together – still
not at space where they can work with minimum supervision
 Adjourning-disbanded -either mourning (negative end) or celebrating (positive finish)

MODELLING

 Visual representation of the problem or solution

 Description or analogy to help visualise something that cannot be directly observed
 Small but exact copy of something
 A pattern or figure of something to be made
 Often used to describe set of diagrams

Iterative development –

 1-2 days
 TAC- thoughts action convo
 Action needs to include build and test then we find out if it passed or failed –
 we need to keep a record to see what happened at each iteration weather they failed or
passed v1 (iteration failed) v1.2 (failed) v1.3 (passed) - configuration management
 Iterations designed to find solution
 Build, test, discuss the results, pass or fail, do we need to move on to another iteration
 ALWAYS STARTS WITH CONVERSATION AND ENDS WITH A CONVERSATION
 Planning for iterative development (in FOUNDATIONS)
 CONTROLLING iterative developments
o Needs good configuration management
 Ensuring quality by continuous verification
 Reviews- varying formality
 Testing –3 broad classes of tests:
o Positive
o Negative
o Unhappy path –check the behaviour of the deliverable for any unual or undefined
events

WE NEED TO KNOW HOW MUCH ID we do in foundation because we need to plan for it –how much
time needs to be bought into timebox

We need to consider velocity (idea at the rate which they can work)–affected by people, complexity
environemnts, collaboration

More complex=more velocity

Never gnna know true velocity until we’ve done a minimum of 2 timeboxes –when the team acc
knows what they’ve achived- getting idea of the rate of what the team works
3 stages of structured timebox

 Investigation
 Refinement
 Consolidate

Don’t get iterative dev mized up w 3 parts of structured timebox

People, teams and Interactions

Face-to-face communication

Albert Mehrabian –circle of communication

 We use tone (38%) non verbal (55%), words (7%) –but not in equal amounts – only applies
when we don’t know each other

Deciding how we communicate

Co-location collaboraton- avoid large groups dialling in from their desks

Requirements (TECH)
Functional requirement

 WHAT the solution does (functionality, features)

Non-functional requirements

 HOW it performs
 Describe solution atributes

User stories

 What the user wants something to do and where they are using it (context)
 User stories have the same type of format
 Built into IT helpdesk tickets

REMEMBER

Functional req –the what non fucnc= the how

The three Cs- card convo confirmation

User story-who what n why

Invest
Estimating
 Agile estimating requires a different style
 Styles of estimating –effort is estimated against each component and accumulated
 We dont have the detail up front so we have to estimate
 Agile istimating technique
o Dsdm contingency provided by applying moscow to scope of features to be
delivered
o Estimates only as precise and accurate as nessesary
o Estimates need to be re validated throughout the project as the understanding of
the requirements deepends

Funnel diagram

ESTIMATING FORMULA

 range of number -if difference between 2 is 100% its feasibility

 difference less than 100%= foundations
 no range single figure= evolutionary development

When you get 4 people 8 days different measurements of days and people –it will always be
Evolutionary development phase

Top down estimating (during feasability)

 What we think each component will involve

 Can we do this in house, contracters etc
 Cant go into details
 5 tier cake iced choc –this is not detail, just break down of what it will look like –40-
80pounds
 Achivable/not achievable
 Story point estimating
o Consensus based technique using group discussions
 T shirt estimating
o T shirt syle sizing to requirments –50 requirements =work out avarage requirement
to fulfil (SMALL/MEDIUM/LARGE/XL)
 Estimating by velocity
o Uses teams previous performance to project forward and predict what can be
expected
 Estimating by example

FOUNDATION: Bottom up =more accurate estimating

 What kind of chocolate in design,

 visionary technical coordinator, PM
Estimating through lifecycle

Foundations- 100requirements and we will start to moscow +bottom up

Delivery plan-high level-PM

Daily standup will update the delivery plan EVERY DAY

Timebox plan –sdt

Testing concept –IT/Tech

 Collab testing –developer and test is done with stakeholder eg. Ambassador testing the
product or users
 Repeatable testing- finding method of testing that is reliable that we can use again
 Prioritised testing (moscow)
 Independent testing by someone other than creator
 Test driven development

QUALITY –FINISH THE NOTES ON THIS SECTION

Why is quality important in agile –because it’s a non variable feature

We need to understand the customers quality expectations in feasibility stage

 Quality + VAD linked- if we understand customers expectations we can assess VAD

 Why is understanding quality expectations so important?
o What if they need a temporary soultion first then the second project/solution is
more sustainable ie. More quality
o Own corporate quality standards?
o Regulatory standards- adhering to data protection? Financial conduct authority?
o Health and saftey?
o THIS WOULD BE INCLUDED THE SAD (ENVIRONEMENT) and the DAD
 Process quality
o Quality processes during agile
o We need quality stand ups
o Quality working enviornment
o Do as I do NOT do as I say –quality in management –have to get them thinking in an
agile way from feasabiility stage
 Quality Across the lifecycle
o Feasibility
 High level acceptance criteria
 Consider maintanance –cost and how this will be done opperationaly
o Foundations
 Expand high level acceptance criteria
 Appropriate strategy for review and testing
o Evolutionary development
DSDM as a quality process

Say what you do (at foundation)

 Agree how project will be goverend and managed

 Appropriate management approach definition

RISK MANAGMENT

Issue and risk – issue has happened risk hasn’t happened yet

Managing risk

Risks to achiving project objectives

-adress these with existing risk management best practices

To reduce risks associated to the DSDM process focus on these key areas

 instrumental success factors (isfs)

 Project approach questionnaire (PAQ)
 adherence to principles

Areas of risk

 Level of business involvement and commitment

 Team skills, ability and availability
 Clarity of vision without defining detail too early
 Focus on delivering on time by varying features

Also talks about risk to agile – the risk of working becoming UN-AGILE

 Descoping ‘could haves’ to should haves with no permission

 Must haves can only be altered or changed by visionary

Assess risk to dsdm process

-accept there are risks involved –deal with it

Biggest risk is that the project doesn’t deliver

 -asessement in feasability phase –collaborativly complete in initial PAQ –QUESTIONNAIRE

 End of foundations phases-reassess PAQ
 Run risk analysis workshops
 Tailoring driven by PAQ should be definition

 Identify risk
 Assess severity
 Put contingency in place –deal with it
BURN Charts: Examples

Representative idea of how we are doing against a plan

Burn DOWN chart- Tell us the amount of work remaining

Burn UP chart- What's been completed

Archemedies principle-agreed requirements in timebox- if you want to put something in we need to

take something out of equal value

Kanban boards, team boards- COLUMNS: backlog, to do, doing, testing, done, under these you have
post it notes

PRACTIONER

You will get an email from knowledge academy with a link to zoom where invigilator will be

Called –Agile Practioner

HAVE apmg website open

Have everything else closed

Register –on the day of exam

You will share your screen, face, and ID

Then you go to APMG website, click on the button and you will start exam

EXAM TECHNIQUE

PRACTITONER Scenario

Read two times

Identify what is project objective?

Look at the timeboxes that have objectives that will lead to the overall objectives!!!

Don’t use additional information until the question tells you read the additional info

Exam is 4 sections

Question 1-techniques

Question 2-people and roles

Question 3- planning and control

Question 4-lifecycle and products

TRUE OR FALSE QUESTION

Cover up the left side

Take notes -Write out in the book 1-6 – write weather they are false or true

The right hand side is everything from the book –foundation

Now do the same with the left- phrased as per the scenario – do trues and false

Then match up the trues an false and bridge it with ‘which means that’ or ‘therefore’ -if it makes
sense then its ‘true true’ - A

If the statements are saying the same thing... - B- don’t make sense together –no rationale

If they don’t make sense