1. Agile Fundamentals
Course

2. Practical arrangements

3. Times Time Event 9.00 Arrive 9.30 Start 11.00 – 11.15 Tea break
12.30 – 13.30
Lunch
15.00 – 15.15
16.00
Done
17.00
Done-Done

4. Agenda Why Agile Manifesto Principles & values Culture & Mindset
Shared Understanding
Shift in Roles
Incremental Development
WIP
Including Customers & Users
Product Adaption
Planning & Adapting
Process & Product Adaption

5. Use PowerPoint as development environment!
Case study exercise
Throughout this course we will work on Amazon South Africa product
Introduce online bookstore in South Africa based on Amazon US
Key capabilities of the system include
Book library
Book ratings
Customer account
Profile
Address detail
Billing detail
Preferences
Cross-selling/ up-selling
Checkout, payment gateway
Reporting
Advanced book/author/topic search
Drone delivery
Use PowerPoint as development environment!

6. Why Agile? Project failures Heavy processes Disconnect Overspending
Little success

7. Standish Group Chaos Report, 2012

8. Evolution of Agile

9. We are uncovering better ways of developing software 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 documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile Manifesto

10. Agile principles 1-6
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Welcome changing requirements, even late in development. Agile processes harness change for  the customer's competitive advantage
Deliver working software frequently, from a couple of weeks to a couple of months, with a  preference to the shorter timescale
Business people and developers must work together daily throughout the project
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

11. Agile principles 7-12
Working software is the primary measure of progress
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
Continuous attention to technical excellence and good design enhances agility
Simplicity--the art of maximizing the amount of work not done--is essential
The best architectures, requirements, and designs emerge from self-organizing teams
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

12. Benefits of Agile

13. Stacey Matrix
Stacey Matrix

14. Culture and mindset

15. Agile as a mindset

16. Schneider cultural model

17. Creating shared understanding

18. The agile mindset nurtures a collaborative culture
Effective collaboration is a critical success factor in Agile product development efforts
Mastering skill to collaborate effectively is critical in
▪ Highly interactive
▪ Non-hierarchical
▪ Rapidly changing environment
The agile mindset nurtures a collaborative culture

19. The Agile team

20. More about the Agile team
Agile teams are self-organising. Everyone in the team:
Is responsible for the outcome
Evolves the solution collaboratively
Participates in most or all decisions
Contributes to stories, testing, planning, estimating, spikes, sweeping floors,
etc.
“A complex problem, like discovering ways to delight clients, is best solved by a cognitively diverse group of people that is given responsibility for solving the problem, self-organizes, and works together to solve it.”
Stephen Denning, The Leader’s Guide to Radical Management

21. Physical work environments

22. Collaboration techniques
Limiting Work in Progress (WIP)
Pairing
Collaborative development
Reviews
Information radiators
Collaboration techniques

23. Shift in roles Roles in Agile are not necessarily job titles
Team member
Scrum Master
Product Owner

24. Incremental development

26. Value driven vs. plan driven
Focus on Minimum viable product (MVP)
Learn from customer feedback
Adapt plan
Iterate & increment
Progressive elaboration
Focus on project completion
No value increments of product
Big bang value at the end
No feedback cycles

27. WIP Any work currently being worked on
Uncontrolled WIP = waste = money being spent on 100’s of projects running concurrently
At any point prior to being done, no value is derived
Controlling WIP results
Greater focus and quality
Bottlenecks being illuminated
Focusing all resources on one project gets the project done much faster

28. Cycle time & lead time

29. Excercise Lean Star Game Form teams of 5
Create the product : set of 10 stars
Each person is responsible for a line on the star
Round 1 WIP = 10
Round 2 WIP = 5
Round 3 WIP = 1
Record cycle time and lead time
Discuss outcome
Timing: 15 minutes
Overview:
This is a short game to explain why WIP is bad. It has so many variants, one of which is the lean simulation game with paper airplanes by Jeff Patton. Instead of building airplanes, we connect five dots of a star.
Resources:
Print 10 copies per team from this Star-Connect pdf file.
Steps:
Form teams of 5′s. Each team member is responsible to connect one leg of the star. So, the first team member will connect 1-2, the second will connect 2-3 and so forth.
The product is a set of 10 stars. Start with WIP = 10. That is, a batch of 10 stars. Each team member will do his assigned work for 10 stars before it moves to the next team member.
Let every team record the following numbers for experiment 1: Time to Customer and Total cycle time. For this round, both numbers should be equal.
Re-do the experiment with WIP =5. That is, 2 batches of 5′s, and record the two numbers: Time to customer, and the total cycle time
Re-do the experiment with the WIP=1, and record the two numbers.
At this point, the number that every team has recorded will explain clearly the effect of larger WIP.
Learning Points:
WIP is bad, and the more you reduce it, the more efficient and productive you become
Teams feel the effect of delay on the overall process. Working on big chunks of work introduces huge delay in the process.
First time to customer is reduced tremendously with smaller WIP, which gives the team better opportunity to get feedback as fast as possible.

30. Continuous integration

31. Continuous integration
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

32. Continuous delivery
Continuous Delivery is the ability to get changes of all types into production, or into the hands of users, safely and quickly in a sustainable way
Our goal is to make deployments predictable, routine affairs that can be performed on demand
We achieve all this by ensuring our code is always in a deployable state

33. Benefits of continuous delivery
Low risk releases
Faster time to market
Higher quality
Lower cost
Better products
Happier teams

34. Including customers and users

35. Defining the customer
Agile advocates customer and developers work together, daily
Customer provides direction for product
Customer heavily involved
Making known requirements
Quantifying when requirements are met
Sponsor
In Scrum we have Product Owner that is customer/ represents customer
In XP we have customer as member of the team

36. Closing the IT / business chasm
Closing the chasm between business and IT creates one effective team
The Product Owner plays a key role in bridging the gap

37. Planning and adapting

38. By Johannes Vietze - Own work, CC BY-SA 3. 0, https://commons

39. Planning Massive upfront planning Little to no re-plan Plan driven
Traditional
Agile
Massive upfront planning
Little to no re-plan
Plan driven
Non-adaptive planning
Small upfront planning
Continuous planning
Value driven
Adaptive planning

40. Estimation

41. Agile release planning
Avg. velocity = 11 3 2 5 5
56 / 11 = 5.09 Sprints 8
Rolling average velocity is taken for the last 3-5 sprints.
Divide backlog sum of story point estimates by average velocity. 13 20 56

42. Burndown
A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed.

43. Process- & project adaption

44. Process adaption
Agile Value: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
It doesn’t matter the framework used, the system must accommodate retrospection time
Part of Deming's Cycle: PDCA
Retrospect > Learn where to optimize > Action the optimization

45. Project adaption
Agile Value: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
Our chosen framework must accommodate time to showcase our complete functionality/product
Build feedback cycles into the system
Short feedback cycles = quicker learning and adaption

46. An Agile Framework
Scrum

47. Scrum Download the official Scrum guide here:
Scrum

48. Scrum definition
Scrum is an agile way to manage a project, usually software development. Agile software development with Scrum is often perceived as a methodology; but rather than viewing Scrum as methodology, think of it as a framework for managing a process.

49. 3 Scrum Roles Product Owner Scrum Master Team Member Developer BA
Tester
UX designer
DBA
3 Scrum Roles

50. Product Owner Customer advocate Sets product vision, direction
Accountable for ROI on product
Responsible to work with team to get user stories ready for next sprint
Prioritizes backlog based on business value
Has final say in any priority quibbles

51. Scrum Master Keeper of the Scrum process Removes impediments
Coaches team members to become more effective
Guards/protects the team from interruptions
Continuously looking for ways to improve self and team
The glue between project stakeholders

52. Team member Anyone on the team doing work
BA, developer, UX designer, tester etc.
T-Shaped people
Cross functional people
Learning mindset as opposed to fixed mindset

53. Exercise: Team formation & prioritizing the backlog
Divide into groups with
1 PO
1 SM
3 Team Members
Time: 2 minutes

54. Scrum Artefacts
Product Backlog
Sprint Backlog
Burndown chart

55. Product Backlog The list of work pertaining to a product
May or may not get done
Prioritized by PO
Top priority items on top (priority descending)
Enough work for 2-3 iterations must be groomed
PO’s responsibility
Product Backlog

56. Agile requirements = user stories
Defining a user story:
Reminders
CARDS to have CONVERSATION
JIT analysis
Slim high level requirement artefacts
Confirmation
3C’s

57. User Stories A card expressing the voice of the customer
Plain English
States an actor, feature, benefit
User Stories

58. INVEST in great user stories

59. Acceptance criteria
Written in Given-When-Then format (Behavior driven development practice)
Given a precondition
When I perform XYZ function
Then I expect ABC result
Given that the user is on the reports menu, when clicking on Audit Report, then the Audit Report is displayed in PDF.

60. Exercise: User Stories
In your groups, write 5 user stories that expand on the priority user stories as defined by your Product Owner
Write simple acceptance criteria for these (on back of cards)
20 minutes

61. Exercise: PO prioritize User Stories
PO prioritize all the user stories in the backlog
Identify first release stories
Write simple acceptance criteria for these identified release 1 stories (on back of cards)
20 minutes

62. Sprint Backlog The work committed to by the team
Work that must get done in the iteration
Sprint backlog should not be changed – causes WIP to be parked = waste
Estimated in story points
Team owns the sprint backlog
Sprint Backlog

63. Scrum ceremonies Backlog grooming Sprint planning Daily Scrum
Product demo
Retrospective

64. Backlog grooming
It is advised teams spend 5% of time grooming the Backlog. - Ken Schwaber (co-founder of Scrum)
Engage the Team
Grooming:
Adding, removing stories
Sizing, Breaking down stories
Reprioritizing stories
Adding info to stories

65. Product Owners sets sprint goal
Product Owner presents the dev team with candidate user stories
Team asks questions about the work that has not been covered in backlog grooming
Team commits to work until velocity threshold reached
Product owner responsible for the ‘What’ and Scrum team for ‘How’
Scrum Master facilitates ceremony
Sprint Planning

66. Exercise: Backlog Grooming
With your Product Owners, discuss and understand the user stories better
Use whiteboards to brainstorm ideas if required
Note implementation decisions on stories
15 minutes

67. Exercise: Sprint Planning
As a team, decide which stories you can accommodate in a 10 minute sprint
Break stories down into tasks on your Scrum boards
Remember to plan for integration with the other team
15 minutes

68. Exercise: Sprint Execution
As a team, self organize and divide into ‘developer, BA, tester’
Break stories down into tasks on your Scrum boards
Remember to plan for integration with the other team
Scrum of Scrums
Now its time to do the work as well
1 minute planning, 6 minutes sprinting, 2 minutes Retrospective
Repeat for 4-6 sprints

69. Daily Scrum ceremony A quick check-in with team mates Max 15 minutes
What did I do yesterday to help us reach our goal?
What do I plan on doing today to help the team reach it’s goal?
Do I have impediments that blocks me from being productive?
Max 15 minutes
Scrum Master facilitates
Only allowed to talk about work on the board
Only members doing the work can participate

70. Product demo
Goal: Get approval from PO & feedback from as many possible
Demo fully integrated end-to-end product
Team takes PO and interested parties through the sprint’s product increment
Successes, impediments and future goals are shared

71. Exercise: Product Demo
Take your Product Owner and Sponsor through the new functionality
Do this as a single team activity
10 minutes

72. Retrospective Continuous improvement opportunity What worked well?
Where can we improve?
Make plans to improve, assign a driver and check in regularly
PDCA mechanism
What worked well?
Celebrate good behavior
Recognize simple yet effective things
Focus on the team, not the product

73. Twitter @joeloost / @Agilocity_ZA
Done!
Thank you