5. Observation
The current standard management system, does not provide satisfaction to
all.
6. “Organizations can become learning networks of
diverse individuals creating value, and the role
of leaders should include the stewardship of the
living rather than the management of the
machine.”
http://www.stoosnetwork.org
7. Agile Overview
Agile Tree
Profit
Practices
Principles Values
Source: Coaching Agile Teams by Lyssa Adkins
8. Agile Overview
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.
Source: Agile Manifesto : http://www.agilemanifesto.org
9. Agile Overview
Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
Source: Agile Manifesto : http://www.agilemanifesto.org
15. Scrum Artifacts
Velocity
the amount of product backlog that a team can handle in one single sprint
Quantified in story points
Story point is an arbitrary measure to quantify the required effort to finish an
user story. Namely, how hard the story is. Loosely based on Fibonacci series.
Business Solutions
16.
17. Scrum Artifacts
Product BurnUp
Display work delivered so far in the release to predict whether the release date will
be met (extrapolation)
Business Solutions
19. Scrum Artifacts
Sprint Backlog
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.
As new work is required, the Development Team adds it to the Sprint Backlog.
As work is performed or completed, the estimated remaining work is updated.
When elements of the plan are deemed unnecessary, they are removed.
Only the Development Team can change its Sprint Backlog during a Sprint.
22. Scrum Artifacts
Definition of done
When can a story be considered as “done” and accepted?
Done defines what the Team means when it commits to “doing” a Product Backlog
item in a Sprint.
Exit criteria must be defined in advance for every individual User story at the sprint
planning. E.g.:
• Release (baseline created): label submission
• Code Review conducted
• Unit Tests successfully run and integrated with the CI system
• Code coverage and static analysis done
• Verified Business Solutions
• Tests for regression automated and successful
• Demo to the Product Owner for acceptance
• User, API and Design documents completed
Lingo term in the Agile religion for “done”: “sashismi”
25. User Stories
What is a User Story
A user story describes functionality that will be valuable to either a user or
purchaser of a system or software.
User stories are composed of three aspects:
• A written description of the story used for planning and as a reminder
• Conversations about the story that serve to flesh out the details of the story
• Test that convey and document details and that can be used to determine when a
story is complete
27. User Stories
Attributes of a good user story
Independent
Avoid introducing dependencies cause this can lead to prioritization, estimating and
planning problems
Negotiable
Stories are short descriptions of functionality, the details of which are to be negotiated
with the customer. Important details shall be annotated as they surface
Valuable to users or customers
Avoid stories that only are valuable for developers
Have the customer user or their representative write the stories
Estimable
If there are lack of knowledge, make a spike to gather further info
Small
Split stories (or combine them) into the right size
Testable
Developers must be able of determine when they are DONE
28. User Stories
The three aspect of user stories
• Stories are traditionally written on note cards
Card • Cards may be annotated with
estimates, notes, etc.
• Details behind the story come out during
Conversation conversations between stakeholders, product
owner and team
• Acceptance tests confirm that the story was
Confirmation coded correctly
30. User Stories
Examples of user stories
As a surfer, I want As a trader, I want
to ride the wave so open a position, so
that I will have I can short a
great fun. EURUSD pair.
39. The Inception Deck
And the last 5 things to remember
6. Show the solution.
7. Ask what keeps us up at night.
8. Size it up
9. Be clear on what’s going to give
10. Show what it’s going to take.
1. Ask why we are here2. Create an elevator pitch If we had 30 seconds and 2 sentences to describes our project, what would you say?3. Design a product box (write a small advertise article about the product)4. Create a NOT list5. Meet your neighbors6. Show the solution. High level blue print7. Ask what keeps us up at night. Do a Risk review8. Size it up9. Be clear on what’s going to give What’s most and less important : Time, Scope, Budget & Quality10. Show what it’s going to take.
1. Ask why we are here2. Create an elevator pitch If we had 30 seconds and 2 sentences to describes our project, what would you say?3. Design a product box (write a small advertise article about the product)4. Create a NOT list5. Meet your neighbors6. Show the solution. High level blue print7. Ask what keeps us up at night. Do a Risk review8. Size it up9. Be clear on what’s going to give What’s most and less important : Time, Scope, Budget & Quality10. Show what it’s going to take.