Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Deep Dive: Agile Basics

A short sharp presentation about Scrum, Kanban and Agile Values
by

Amber *

on 5 December 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Deep Dive: Agile Basics

Stand-ups
They think in costs & benefits.
They are committed.
They work great as a team.
They practise risk management.
They learn constantly.
They are independent.
They become more predictable.
They eliminate waste.
Have a happy Product Owner.
They can estimate.
They optimize for business value.
They feel responsible.
They stick to their own practices.
They deliver continuously.
They have a shared vision and goal.
They are able and willing to commit.
They respect their Level of Done.
They practice software craftsmanship.
They are self-organized.
They make fast decisions.
They know their strengths and weaknesses.
They manage their skills.
They can handle conflicts.
They understand the roles and know how to support them.
AGILE deepdive
They foster transparency.
They provide transparency for themselves, stakeholders and management.
They know how they perform in speed and quality.
They find the Minimal Viable Product.
They think big and start small.
They recognize and take risks..
They inspect and adapt.
They have a deep understanding of agile values.
They have a feedback culture.
They do change management.
They take end-to-end responsibility for the product.
They are cross-functional.
Apply software craftsmanship
Design patterns
Reduce technical debt
Blue Red Refactor
Pair Programming
Collective Code Ownership
Test Automation
Keep testing cheap
Know when something's wrong.
Domain
knowledge
Technological
knowledge
Low
Low
High
Chaos
Complicated
Try to avoid this
Unpredictable by nature.
Agile is needed to adapt to environmental complexity, and still balance quality with end user value

Lean Product development and business methods can help here.
Planning is possible
Agile works but is not mandatory

Kanban can live here
No formal process needed
On-demand development

Methodologies:
PRINCE2
Waterfall
Agile is learning
The more you have to learn on the way the more you need Agile.

Agile is about making the right decisions in an unpredictable, complex environment.

Its also about being responsive to our customers and what brings value to the business.
Reduce Costs
Cost per change
Time and software development phases
Requirements
Design
Implementation
Test
Deploy
Cost per change over time is increasing exponentially
That makes agile teams ...
Test Pyramid
TDD
Agile Engineering
Why?
Why Agile at all?
Agile Myths
Why?
Team
Change happens
In Agile we build software incrementally in short iterations to better understand customer needs and control cost per change.

essentially we create feedback loops at every stage of development, from designing a product, to breaking down the work.

We take the traditional big Waterfall model ->
And make lots of small ones on a per feature basis. Once we finish one thing, we get feedback from our main stakeholder, and can change strategy easily.
No managers?!
No planning?!
WTF IS GOING ON?!
There are a lot of myths regarding Agile development in any flavor.
If you have any questions just talk to a Scrum Master or Agile Coach and get the answers.
They set goals and boundaries to enable self-organization.
Agile Management make agile teams successful.
They foster communication between team members.
No discipline?!
Agile is incredibly disciplined but it is bottom-up rather than imposed discipline through comand and control i.e. we tell you what to build...and when.

There is more feedback and engagement which results in greater productivity.

Agile needs disciplined people
who can handle the heavier responsibility
that comes with greater freedom.
Discipline
Planning?
I thought we were agile...
Instead of planning the whole design up-front, agile teams plan more often and on many different levels.
There are 3 main time horizons: Daily, Iteration, and Release

All methods of Agile recognize the need to understand things at an in-depth level before commencing work and therefore put all tasks into a "just in time and just enough" framework.
Why cant you just tell me how many days this will take?!?
Facts:
Estimations for software implementation have always been hard.
No easy, reliable and cost-effective way to estimate software projects has been invented yet.

In Agile:
We openly communicate this fact.
We let teams estimate their work using
relative methods, like story points and t-shirt sizes that cope with imprecision,
rather than absolute methods that rely on man hours.
Once the team stabilises, relative methods turn out to be most accurate, even if they are made with imperfect or incomplete information.

Estimations are possible but whether they are helpful depends on what you want to do with them.

Most of the time the answer is more complicated than just naming a figure (number of days).
Agile Teams strive for transparency
status reports often misused as smoke screens
empirical data churned out at any given point in a sprint.
what? - why? - how far?
Burn Down Charts
simple & noticable
information for teams AND organization
Infos can easily be wrapped up in a Management Summary
BUT
Just talk to your ScrumMaster!
-->
-->
=
meet teams half-way,
help design measures that can report
success collaboratively ,
allow teams to be able to fail (and thus learn) without assigning blame
Agile uncovers problems within an organization very quickly.
Teams need to
accurately track their work to enable Agile progress reporting
reflect true progress of continuous delivery of shippable increments
assess if value was delivered
Deliver business value
Agile is not the cause of these problems; it is the method of exposing them, and openly tackling them
BUT
What can we do?
Introduce Beginners to Scrum and Kanban concepts:
Give an overview of the two main frameworks
Have a look at why they are successful if used correctly
Look into what makes an agile team
Goal
They further personal development.
Efficiency
How
What
cross-functional
team
Product Owner
Scrum Master
Delivering value through strong teamwork
Not all agile methods use the same roles. Some - like Kanban - don't have any roles at all.
It might still be useful to have roles for the following reasons:

splitting responsibilities for different objectives/goals/topics
being able to focus on one responsibility at a time
reducing conflicts of interests in one person
stabilizing the development process
They solve organisational problems on behalf of the teams.
Engineering
Engineering
Team
Goal
What is your favorite piece of engineering? a plane? a phone?
Explain in 10 seconds
Myths
How fast are teams?
Where are my traffic lights??
Any last requests?
Whats Missing?
What do you want to find out more about?
Take 3 minutes to brainstorm on stickies..
Any last requests?
Thanks :)
BUT
What can we do?
Management / Stakeholders need to
Why?
Spend 2 mins with a partner and come up with 2 possible reasons why agile as you understand it
could be more effective for developing software.
gradually increasing velocity over time
being more accustomed to processes, team practices and epics
-->
=
the measure of the throughput of an Agile team per iteration
the rate at which a team delivers value
Teams produce velocity
Ask your ScrumMaster
get team velocity
Mature Agile teams
=
Velocity is all about speed
Velocity is all about speed
Teams produce velocity
Mature Agile teams
WE want to move fast and break things!
how?
How?
The rules teams create , and sets of practices they follow make it easy
Planning
Retrospectives
Refinement
Ready (DOR)
DONE (DOd)
your scrum master or agile pm
is here to help co-ordinate
so you don't have to....
how do we know when its time to stop?
how do we know we can start?
Done is a simple checklist.

A level of Done should be all the generic things that you need to do every time you develop something e.g.

* Acceptance tests passed and approved by P.O. or stakeholder
* All tests passed
* Documentation written
* [insert generic thing here]
Ready is a simple checklist.

A level of Ready should be all the generic things that you need to ensure you know about e.g.

* dependencies discussed
* interested parties
* system diagrams, or architechtural input gained
* role action goal filled in
* acceptance criteria written
* estimation for complexity done
45m ins - 1hr per week
Is important to:
make sure everyone understands what exactly is needed at a HIGH level.
align technical and business strategy.
actively split stories into their smallest increments using patterns
estimate efforts - usually a relative estimation technique employed which helps with velocity (more on this later).
get the next most important stories and tasks ready for..........

1.5 hrs - 4 hrs per 2 week sprint - Most effective when split into parts

Planning 1 - timebox aim 30-45 mins - dev team, PO and Scrum master
Confirm business priority and focus for the next iteration
Negotiate sprint backlog

Planning 2 - Rest of planning timebox - Dev team and Scrum master - input from architects, leads, SMEs, dependent teams
Break PBIs (product backlog items) into implementation sub-tasks
Timebox tasks and check against team capacity
1.5 - 2hrs per 2 week sprint

Whole team present - SM facilitates
4 Parts: Check in / data gathering / data analysis / action items

Talk about what worked and what didn't
Facilitate understanding that failures are opportunities to learn
Create action points to facilitate positive change
KANBAN
SCrum
A method without a Methodology...
Characterized by single piece flow
Models a current state
A way to visualize workflow
get a faster TTM! (time to market)
Kanban has NO:
sprints
teams
artifacts
estimates
roles
The goal of Kanban is to enhance business agility
The goal of Scrum is to enhance delivery based on value, and transperancy for all levels of business
Scrum has:
very clear roles and boundaries
works in short iterations or sprints
aims to prioritise based on value / ROI
has clear sets of rituals and ceremonies that make it successful
is focused on a cross fuctional team of generalising specialists
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
RULES!!!!!
NO TECHNOLOGY
LISTEN ACTIVELY
NO TAKING NOTES!!!!!
THERE ARE NO SILLY QUESTIONS
TREAT OTHER'S OPINIONS WITH THE RESPECT YOU'D EXPECT FOR YOURS. (the no arsehole rule)
They figure out the hardest or most risky part of a system AND DO IT FIRST. (strawman)
They Celebrate failure and make mistakes OFTEN.
(REvolution!)
(Evolution!)
Cloud of agile
SCrumbut
agile project management
Agifall
Modular Architecture
CI/CD
AGILE deepdive
Agile Manifesto
That makes agile teams ...
Handle Complexity
As aspiring Software Craftsmen, we are raising the bar of professional software development by practicing it, and helping others learn the craft.
Through this work we have come to value:

Not only working software,
but also
well-crafted software
.
Not only responding to change,
but also
steadily adding value
.
Not only individuals and interactions,
but also nurturing a
community of professionals
.
Not only customer collaboration,
but also
productive partnerships
.

That is, in pursuit of the
items on the left,
we have found
the
items on the
right
to be indispensable.
It was signed in 2001 by Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Robert C. Martin, Steve Mellor, Dave Thomas, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Ken Schwaber, & Jeff Sutherland
SHIFT TO MAKING VALUABLE THINGS FASTER, with
greater resilience.
planning using ideal productive hours
Simple method: add all timeboxes of tasks into total per story
# of Devs x 6hours per day x days in sprint = sprint capacity
- Training days
- Distraction time (use count from last week if applicable)
- holidays
- sick days
- other workshops outside of scrum ceremonies
= sprint capacity (with buffer for distractions)
- story timeboxes.

If your hours are in the negatives, assume are you are over capacity
If your hours are roughly adequate, assume sprint goal can be achieved
If you still have hours left over, check with am to see if there is consensus to either pull another story, or if it's good as is and to assess later in sprint.
Is this ready to work on?
lets build awesome stuff!
Looking back to go forward faster...
What the hell is going on????
15 mins everyday

Dev team present - SM PO optional
3 questions:
What did I do yesterday?
What am I doing today?
What is stoping me (impediments)
Demo!
1.5 hrs - 4 hrs per 2 week sprint

Whole Team

Team demonstrates
done*
work to stakeholders and other teams.


Done as in totally 100% done. Not 20%... Not 80%... DONE.

Check your D.O.D.
check out our awesome stuff!
Complex
Complicated
Easy
D.A.D.
XP
D.S.D.M.
Crystal
F.D.D.
LEAN
Feature Flags
Monitoring
MVP
Metric Automation
Small Batch Sizes
Full transcript