Date post: | 06-Sep-2014 |
Category: |
Technology |
Upload: | bilsel |
View: | 20,543 times |
Download: | 2 times |
Tayfun BilselFounder & CTO, Rabbitsoft14 April 2011
Waterfall vs Agile approach, Scrum Framework and best practices in software development
www.rabbitsoft.com
www.clinked.net
Agenda
• Common Problems in Tradition Project Management• Waterfall vs Agile approach• Where does your project fit?• Agile Manifesto• Agilebut syndrome and common problems• Scrum Framework• Best practices?
Common Problems in Traditional Project Management
• Late Delivery• Over budget• Wrong thing is
delivered
Waterfall Approach
- Requirements are known
- Each stage signed off before the next one commences
- Need extensive documentation as this is the primary communication medium
Perfect approach if requirements are fully understood and not complex
Agile Approach
Waterfall vs Agile
Be Agile
Outline requirement rather than detailed requirements/solution/plan
Baseline Plan (3-9 months) vs Commitment Plan
Where does your project fit?
Source: http://www.noop.nl/2008/08/simple-vs-complicated-vs-complex-vs-chaotic.html
Empirical (based on observation)orDefined?
Agile Manifesto
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://www.agilemanifesto.org/
Agilebut and Scrumbut syndrome
We use Agile but.....
- our roadmap is fixed and a year old - we don't have release plan - we create detailed plan or architecture - we manage team tightly - we don't prioritize features - we know our requirements, no need to talk to customers - we don't do planning meetings
but but but...
Common Problem1
No Product Owner or Multiple Product Owners
case1: There is no one in the organisation to prioritize features or no prioritization methods
case2: The priority set of one Product Owner not match with the priority set of another Product Owner, as they have different understanding of what is important.
Common Problem2
Sales/Marketing or Management often make promises to customers about features or make assumptions that features will be delivered in a certain time
and this never happens!
and..... they start to blame the development!
Common Problem3
We can do agile without customer feedback!
You may end up building a perfect technical product, with no value to the customer
Customer is the most valuable team member
Common Problem4
Stick with the plan and you will be successful!
- Iterative development is well planned but planned in a different way to waterfall
• Wrapper for existing engineering practices and does not strictly define principles or how to guidelines
• Scalable from single team to entire organisation• Scrum is the lightest of all Agile methods (AUP, Lean,
XP...) with 5 values (Commitment, Focus, Openness, Respect, Courage), 3 roles
• Role to detect and remove anything that gets in the way of developing and delivering products
Why Scrum?
Multi-level Planning
Release Plan -> Typically every 3 to 6 months
Sprint Plan -> Typically every 2 to 4 weeks
Daily Plan -> Daily
Scrum Roles
Scrum Team (Size 7 +-2) How - Who - How long - Deliver• Self Organising, cross functional with no pre determined roles• Responsible for self-organising tasks and committing to work
(no one assigns stories or tasks to team members, team must self-organise)• Authority to whatever is needed to meet commitment
Product Owner What - When - Signoff - Vision• Defines the features, writes user stories• Responsible for development schedule and prioritizing Product Backlog• Accepts or rejects stories• DARK - Desire, Authority, Responsibility, Knowledge (Business and Technical)
ScrumMaster (Coach)• Coaches the development team and responsible for productivity• Facilitates Scrum ceremonies• Establishes and enforces Scrum rules and responsible for the success of the process• Shields the team from noise and removes obstacles• Enables close cooperation across all roles
Self Organising Team
Team must• take initiative• focus on solutions and co-operate• self directed, motivated, multi-skilled
DARKDesire - Authority - Responsibility - Knowledge
Scrum Artefacts
Product Backlog• Continuously evolving queue of stories created by the Product Owner with input from
other stakeholders• Owned and prioritised by Product Owner
Sprint Backlog• The list of tasks required to get the agreed Stories done• ccepts or rejects stories
Burndown Chart• Shows estimated effort remaining• Actual vs ideal progress• Should be publicly visible
Pigs and Chickens
Team, Product Owner and ScrumMaster are knowns as pigs because they are committed to Sprint
Other stakeholders are known as Chickens as they are not committed to Sprint Goal
Ceremonies
Daily Scrum Meeting (Everyday @ 9:00) - 15min
Sprint Planning (Last day of Sprint in the afternoon) - 8hours max (4+4)
Sprint Review (Last day of Sprint @10:00-11:00)&Sprint Retrospective (Look back) - 1hour max
Daily Scrums - Syncing pigs
1. What did you do yesterday?2. What will you do today?3. What is blocking your work?
• Timeboxed to 15 minutes• Problems are solved outside the meeting• Not a reporting session!
Sprint Planning
• Timeboxed to 4 hours + 4 hours• Priority items are explained by the product owner• Overall Sprint Goal is agreed• Team estimates and commits to what it can get "done"• The result is an agreed Sprint Backlog
• The second part of the meeting, the team decomposes the sprint backlog items into tasks
• Tasks are estimated by the team. They need to be complete enough for the team to make commitment
Sprint Goal
Collectively, the Scrum team and the product owner define a sprint goal in the planning meeting
It is usually one sentence descriptive text
The success of the sprint will later be assessed during the Sprint Review Meeting against the sprint goal.
Planning Poker
1. Product Owner reads the user story and answer any questions that the estimators have2. All cards are simultaneously turned over and shown so that all participants can see each
estimate.3. If estimates differ, the high and low estimators explain their estimates and do another
round4. 3 rounds can be done until estimators converge, if not then, either majority or average
points can be used as the final estimate
Online versionhttp://www.planningpoker.com/
Sprint Review
• Acknowledge achievements• Chickens are invited• Demo of everything that's been done in the Sprint• Product Owner signs off Sprint if tests are ok
Sprint Retrospective
• Takes place at the end of the Sprint before the planning meeting/poker
• Short workshop session for team to review lessons learned and discuss actions for the next Sprint
• No chickens involved (except end of release retrospective)
Action Plan
At the end of retrospective meeting
Information Radiator
Source: Henrik Kniberg: Scrum and XP from the trenches
Sprint finished early?
• Put more stories in (if not risky)
or
• Gold Timeo attend to a conferenceo celebrate - go out
If this happens regularly - your estimates are wrong!
What's "Done" mean?
met Sprint Goal?passed acceptance test?met policies and procedures?
Then it is done!
What is Spike?
Spike is a learning activity
Spike something that you don't understand in advance - when you don't know what exactly it is or how to implement
It is timeboxed - you need to limit how much time you are going to spend researching
User Stories
Explains Who, What, Why (including functional, non-functional and non-software features)
Sprint stories should be doable in 1-5 days. If it takes more than 5 days (compound story), decompose it. For Complex stories (if no way to split up) - spike it as not enough is known
Product Owner can decompose it with stakeholders
Back of the card- high level acceptance test posed in the form of questions (not detailed tests) - testers should come up with these
Cancelling Sprint
Actions required:
1. Retrospective meeting. What went wrong?2. Stop3. Re-plan4. Wait for the iteration to end5. Start again
Tools
Pivotal TrackerVersionOneJira - Green HopperScrumWorks ProRallyHansoftTFS version 2010 (Team Foundation Server)
Best Practices?
Combining approaches:
Agile Management Practices with Scrum Framework +merging with XP and Lean engineering practices
Scrum can customize up rather than customize down
What does it mean?
Scrum+XP• Coding Standards• Pair progamming where possible?• Test Driven Development• Continuous integration• Collective ownership
+Lean• Eliminate waste (bureaucracy, unclear reqs., unnecessary code, delay, comms)• Amplify Learning (improve process through learning)• Empower the team (Allow team to make decisions) • Build integrity in (System should work the way what the customer expects it
to)• Decide as late as possible (make decisions based on the facts not assumptions)• Deliver as fast as possible (Deliver early - Deliver Often)• See the whole - See the software as a whole not just parts->“Think big, act small,
fail fast; learn rapidly”
We all succeed or We all fail!
"Go the distance as a unit passing the ball back and forth" (Takeuchi, Hirotaka, 1986)