1 of 49

Agile Training

2 of 49

3 of 49

4 of 49

COIN FLIP GAME

SET UP

5 people per team

3 ppl are doers, 2 are managers

Managers keep record of time

Crispin is the Client

THE RULEs

You can only flip coins with one hand
You must flip the coins one by one
You can use both hands to pass the pile (batch)
You have to flip all the coins (in a batch) and pile them nice before you pass

5 of 49

So…

What did we learn?

6 of 49

What are we going to cover?

Day 1

What is Agile? �Theory, principles and how it works for web development
Iterative development�What it means and how it works
Burndown & Retrospective�Finding the team ‘velocity’ and learning as-we-go

Day 2

Estimation & Planning�How difficult/worthwhile is this feature going to be?
Scrum & Kanban �Who does what and what’s next?
User Stories�How we talk about what we are going to do / are doing�

7 of 49

Goals

Understand agile principles and how we use them
Build a shared vocabulary about agile development
Understand how SCRUM and Kanban work
Be able to create user stories to describe development work

8 of 49

What do you do right now?

Do you use agile at work?

Have you heard the term used?

What do you know about it?

How does your project process work?

9 of 49

Agency web dev in general

Sell Plan Build Sign-off Bugfix

10 of 49

SDLC - Software Development life Cycle

Identify the current problems
Plan
Design
Build
Test
Deploy
Maintain

https://stackify.com/what-is-sdlc/

Identify the current problems. “What don’t we want?” This stage of SDLC means getting input from all stakeholders, including customers, salespeople, industry experts, and programmers. Learn the strengths and weaknesses of the current system with improvement as the goal.
Plan. “What do we want?” In this stage of SDLC, the team defines the requirements of the new software and determines the cost and resources required. It also details the risks involved and provides sub-plans for softening those risks. In this stage, a Software Requirement Specification document is created.
Design. “How will we get what we want?” This phase of SDLC starts by turning the software specifications into a design plan called the Design Specification. All stakeholders then review this plan and offer feedback and suggestions. It’s crucial to have a plan for collecting and incorporating stakeholder input into this document. Failure at this stage will almost certainly result in cost overruns at best and total collapse of the project at worst.
Build. “Let’s create what we want.” This SDLC stage develops the software by generating all the actual code. If the previous steps have been followed with attention to detail, this is actually the least complicated step.
Test. “Did we get what we want?” In this stage, we test for defects and deficiencies. We fix those issues until the product meets the original specifications.
Deploy. “Let’s start using what we got.” Often, this part of the SDLC process happens in a limited way at first. Depending on feedback from end users, more adjustments can be made.
Maintain. “Let’s get this closer to what we want.” The plan almost never turns out perfect when it meets reality. Further, as conditions in the real world change, we need to update and advance the software to match.

11 of 49

12 of 49

13 of 49

14 of 49

What is Agile?

15 of 49

16 of 49

Game Time

17 of 49

So…

What did we learn?

18 of 49

What is Agile again?

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight interactions throughout the development cycle.

19 of 49

Agile Manifesto:

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

http://agilemanifesto.org/principles.html

20 of 49

21 of 49

Iterative Working

Step 1: Solve the problem as quickly and easily as possible.

Step 2: Make your solution better and better and better and better

22 of 49

23 of 49

24 of 49

25 of 49

26 of 49

27 of 49

The Squiggle

28 of 49

29 of 49

Practical agility

How does this work with clients?

Discovery and planning
Prototype
Alpha
Beta
Release
Ongoing

30 of 49

31 of 49

Sprints

In the Scrum method of Agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration.

Scrum sprints used to be 30 days long, but today many teams prefer shorter sprints, such as one-week or two-week sprints.

32 of 49

GAME TIME

33 of 49

What did we learn?

34 of 49

35 of 49

36 of 49

37 of 49

38 of 49

Scrum

39 of 49

Scrum project team roles

Product Owner – (a role probably performed by the Service manager) responsible for delivering return on investment, usually by creating products that users love
Delivery Manager (aka Scrum master or project manager) – the agile expert responsible for removing blockers (things slowing a team down), they also act as a facilitator at team meetings
Team Members – self-organising and multi-disciplinary, they produce user stories, carry out the product manager’s vision and are responsible for estimating their output and speed

40 of 49

Scrum Activities

Product Planning
Sprint
Sprint Planning Meeting
Daily Scrum
Sprint Review
Sprint Retrospective

41 of 49

Scrum Artifacts

Product Backlog
Sprint Backlog
Increment
Burn Down Chart

Scrum’s artifacts represent work or value in various ways that are useful in providing transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information needed to ensure Scrum Teams are successful in delivering a “Done” Increment.[23]

Product Backlog:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Backlog is never complete, it only lays out the known and best understood requirements. Product Backlog is dynamic, it consistently changes to identify what the product needs to be useful.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in the future releases. As product is used and gains value, feedback is provided and the Backlog becomes larger. Requirements never stop changing. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Monitoring Progress Toward a Goal:

At any time, the total work remaining to reach the goal can be summed. Various projection practices have been used to forecast progress, but whats will happen is unknown. Only what has happened can be use for forward-looking decision-making.

Sprint Backlog:

The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality. The Sprint Backlog defines the work the Development Team will perform to turn Product Backlog items into a “Done” Increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. [23]

Monitoring Sprint Progress:

Development team tracks total work remaining at least for every Daily Scrum. Development team tracks these sums daily and projects likelihood of achieving the Sprint Goals.

Increment:

The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in usable condition and meet the Scrum Team’s Definition of “Done.” It must be in usable condition regardless of whether the Product Owner decides to actually release it.

42 of 49

43 of 49

Scrum at a Glance

44 of 49

Kanban

45 of 49

46 of 49

Kanban Practices

Visualise the workflow
Limit WIP (Work in Progress)
Measure the lead time

47 of 49

My Favourite Things About Agile

Personalised adaptable process
Embraces inevitable change
People-centric rather than doc centric
Shorter feedback loops

Customer focus and involvement
Continuous value
Forces better programming styles
Reduces risk

48 of 49

Iterative Working

Step 1: Solve the problem as quickly and easily as possible.

Step 2: Make your solution better and better and better and better

49 of 49

What’s Next?

Estimation
Lego Scrum
User Stories