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

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Deep Dive: Agile Basics

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

Amber *

on 16 November 2016

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.
scrum 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
Refactor early and OFTEN
Pair Programming
Collective Code Ownership
Code Review
Keep testing cheap
Know when something's wrong.
Handle Complexity
Domain
knowledge
Technological
knowledge
poor
poor
good
Chaos
Complex
Complicated
Complicated
Easy
Try to avoid this
Unpredictable by nature
Agile is needed to keep "control" and succeed
Planning is possible
Agile works but is not mandatory
No formal process needed
On-demand development
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.
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 ...
CLD / CI
Automation
Use Test Pyramid
Test first
TDD
ADD
BDD
Agile Testing
Cheap &
and
Flexible
Agile Engineering Practices
Why?
Which?
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.
No managers?!
No planning?!
Black Box?!
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.
Good managers make agile teams successful.
They foster communication between team members.
No discipline?!
Agile is in fact disciplined but it is bottom-up rather than imposed discipline.

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
Instead of planning the whole design up-front, agile teams plan more often and on many different levels.

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.
How fast are teams?
Project Reporting?!
Why is estimation difficult?
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 scales rather than absolute scales.
This method is at least cheaper and usually more precise.

In General:
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) and the teams are usually better at getting to the bottom of the underlying question themselves.
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 exposes problems within an organization very quickly.
Management & Stakeholder need to
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 values
Agile is not the cause of these problems; it is the method of exposing them.
BUT
Pay off the initial investment through testing, automation, continuous delivery and the infrastructure to support these practices.
What can we do?
No reporting?
Introduce Beginners to Scrum and Kanban concepts
To pass on some of the value of why Agile Frameworks are THE way to develop and deliver software, and things of high quality and value!
Goal
Reasons for using Agile Engineering Practices
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 corporate problems on behalf of the teams.
a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
Engineering
Engineering
Team
Aha! Throw the ball around: What makes a good team? Why do we need them?
Goal
What is your favorite piece of engineering? a plane? a phone?
Explain in 10 seconds
Myths
How fast are teams?
Project Reporting?!
No reporting?
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 & Stakeholder need to
Teams need to
Why?
Spend 2 mins with a partner and come up with 2 possible reasons why agile could be more effective for 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
Reasons for using Agile Engineering Practices
Cheap &
and
Flexible
how?
How?
The rules teams create make, and practices they follow it easy
Planning
Retrospectives
Grooming
Ready (LOR)
DONE (LOd)
your scrummaster 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
Is important to:

make sure everyone understands what exactly is needed at a HIGH level.
Is important to:
discuss technical approach
ID all tasks in detail
timebox tasks
uncover any misunderstandings
Are important to:
talk about what worked and what didn't
learn from the last set of work to get faster

understand that failure is the best thing possible
KANBAN
SCrum
A method without a Methodolgy...
Characterised by Single piece flow
Models a current state
A way to visiualise 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
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!)
< everything in between >
SCrumbut
SCrumban
agile project management
Agifall
Agile Design
Modular Architecture
Testing
Driver/Navigator
$$
Minimize employee churn factor by fostering learning and knowledge transfer.
Let coding standards and designs evolve gradually instead of doing standardization meetings.
Don't pay people for things that can be automated.
Waste as little time as possible trying to understand other people's code.
Know when you are done.
Build new things without constantly breaking old things.
Keep changes cheap.
Deliver often.
scrum deepdive
We have heard about new ways of developing software by
paying consultants and skim reading "the state of Agile" surveys. Through this we have been told 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 the items on the left sound nice in theory,
we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.
Agile Manifesto
half-arsed

(and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact)



(as long as that software is comprehensively documented)




(within the boundaries of strict contracts, of course, and subject to rigorous change control)



(provided a detailed plan is in place to respond to the change, and it is followed precisely)

That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.
Agile Manifesto
Agile Manifesto
That makes agile teams ...
Full transcript