Waterfall vs agile approach scrum framework and best practices in software development

Tayfun Bilsel Founder & CTO, Rabbitsoft 14 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

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) or Defined?

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

Why Scrum? 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

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 DARK Desire - 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 Product Owner reads the user story and answer any questions that the estimators have All cards are simultaneously turned over and shown so that all participants can see each estimate. If estimates differ, the high and low estimators explain their estimates and do another round 3 rounds can be done until estimators converge, if not then, either majority or average points can be used as the final estimate Online version http://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 Time attend to a conference 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: Retrospective meeting. What went wrong? Stop Re-plan Wait for the iteration to end Start again

Tools Pivotal Tracker VersionOne Jira - Green Hopper ScrumWorks Pro Rally Hansoft TFS 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)

Waterfall vs agile approach scrum framework and best practices in software development

Recommended

More Related Content

What's hot (20)

Similar to Waterfall vs agile approach scrum framework and best practices in software development (20)

Recently uploaded (20)

Waterfall vs agile approach scrum framework and best practices in software development

Editor's Notes