Agile Project Management with SCRUM
Jump to navigation
Jump to search
Waterfall ⌘
- Published in 1970 by Winston W. Royce
- Ironically, Royce was presenting this model as an example of a flawed, non-working model
- Ideal in construction or engineering projects
- Usually preceded by prototyping
- Requires Central Control System
- As complexity increases, central control breaks down
Waterfall Stages ⌘
Waterfall Model Problems ⌘
- Market Dynamics/Changing Requirements
- Blaming other people (Analysts blaming designers, designers developers, etc..)
- Lack of understanding business by lower ranks
- Long feedback
- Hit-by-a-spaceship effect (Abducted by aliens)
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."
Principles behind Agile ⌘
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Waterfall vs Agile ⌘
- Requirements for the whole project vs. requirements for the iteration, overview of the bigger picture
- Clearly defined roles vs Cross-functional teams
- Long time estimation vs short time estimation
- Long-time budgeting vs short time budgeting
- Abandoning project in the middle leaves useless artifacts vs each iteration delivers business value
- Extensive out-of-synch documentation vs lean general and in-line code documentation
- Changes are expensive vs changes are expected and cheap
- Long feedback loop between customer and developer vs almost immediate feedback
Agile Inverted Triangle ⌘
Successful Project ⌘
- Successful project is not necessarily a project that goes exactly as expected, yielding results identical to those that were predicted.
- Scrum controls the process of software development to guide work toward the most valuable outcome possible.
Building your house in an agile way ⌘
Agile Frameworks/Methodologies ⌘
Copyright 2012 VersionOne Inc. All Rights Reserved
Scrum - A bit of History ⌘
- Scrum was first defined as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach" in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the "New New Product Development Game".
- The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier and printer industries. They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team "tries to go the distance as a unit, passing the ball back and forth".
- In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum methodology at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) in Austin, Texas, its first public presentation. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum.
The Bible ⌘
Scrum Current Affairs ⌘
- http://www.scrumalliance.org/
- http://www.scruminc.com/
- http://www.scrum.org/
- http://www.mountaingoatsoftware.com
- http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
- http://www.scrumalliance.org/pages/scrum_certification
Scrum Process⌘
Scrum Roles ⌘
- Product Owner: The customer itself or the proxy between the customer and the team
- Scrum Master: Typically not a project manager
- Development Team
All management responsibilities in a project are divided among these three roles!!!
Project Manager ⌘
THERE IS NO PROJECT MANAGER ROLE!
What does the project manager do in SCRUM?
Potential role of "Traditional Project Manager" in SCRUM ⌘
It depends upon!
- Organizational Set-up
- Size of Project
- Competency of Project Manager
Project Manager can either be:
- Scrum Master
- Product Owner
- Project Manager owning multiple Scrum teams
- Choosing Teams
- Budgeting
- Client Interaction
- Manage Contract
- Interface with PMO
Pigs and Chickens ⌘
- The people who fill the three Scrum roles are those who have committed to the project (Pigs)
- Others might be interested in the project, but they aren’t on the hook (Chickens)
Scrum Team ⌘
- The Team is responsible for developing functionality
- Self-managing and self-organizing
- Up to 10 people (7 optimal)
- Cross functional (db admin, web designer, tester, etc...)
- Bigger project = more Scrum teams
- Responsible for managing itself and has full authority to do anything to meet the Sprint goal within the guidelines, standards, and conventions of the organization and of Scrum
| Self-management | On-site client (or proxy) |
|---|---|
|
|
Scrum Master ⌘
- Responsible for the Scrum process
- Teaching Scrum to everyone involved in the project
- Implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits
- Ensuring that everyone follows Scrum rules and practices
- Manager drives the team vs Scrum Master serves the team
- Scrum Master is a facilitator
Product Owner ⌘
- Responsible for representing the interests of everyone with a stake in the project and its resulting system
- Achieves initial and ongoing funding for the project by creating:
- project’s initial overall requirements
- return on investment (ROI) objectives
- release plans
- The list of requirements is called the Product Backlog
- The most valuable functionality is produced first
- Prioritize the Product Backlog to queue up the most valuable requirements for the next iteration
Quiz ⌘
- How many different roles are in SCRUM?
- How may people can be in a team?
- How long usually does a sprint last?
Exercise ⌘
Lets get up from our seats
Backlogs ⌘
| Product backlog | Iteration backlog |
|---|---|
|
|
Product Backlog⌘
- The requirements for the system or product
- Product Owner is responsible for the contents, prioritization, and availability of the Product Backlog
- It is never complete
- Is merely an initial estimate of the requirements
- Span to foreseeable future
- Made of pieces of functionality or wishlist
- Epics
- Stories
- Proven business value
- Testable
- Examples
- User can browse on-line catalogue
- Client can buy a product using a credit card
Sprint Backlogs⌘
- A subset of Product Backlog
- Specified and discussed with all the team members especially with the product owner
- Estimated by more than one person (ideally, entire team)
- If it takes longer than a couple of days, they should be split
User Story Example⌘
As a dog owner, I want to sign-up for a kennel reservation over Christmas so that I get a confirmed spot Acceptance Criteria:
- Verify individual as a registered pet owner
- Verify that preferred members get 15% discount on basic service
- Verify that preferred members get 25% discount on extended services and reservation priority over other
- members
- Verify that past Christmas customers get reservation priority
- Verify that declines get email with discount coupon for future services
Definition of 'DONE'⌘
- Definition of Done can differ
- Clarify what does it mean
- Entire Scrum Team contributes to Definition of Done
- For example:
- functional and unit tested
- documented
- committed into repository
- deployed on staging environment
- accepted by the client (thumbs up)
Scrum Process ⌘
Prioritization Techniques⌘
- MoSCoW Prioritization Scheme
- Monopoly Money
- 100-point method
- Kano analysis
- Value based prioritization (most important)
Agile Planning ⌘
Agile Estimation Technique⌘
- User stories
- Business value
- How to test it (acceptance criteria)
- Different schools about complexity
- Abstract size (0,1,2,3,5,8)
- Number of IDEAL days - A day in life of developer where he has everything he needs to complete the job with no disturbance.
- Planning poker
- Splitting User stories into task
- Task duration from 1 hour up to 1 day. If its gets longer, it is advisable to break it further.
Planning Poker⌘
- Everyone selects complexity from Planning Poker Card
- Two extreme people explain why they thought this way
- Discussion
- Optional re-vote
- You can play poker for estimated time and estimated business value
Precision vs Accuracy⌘
- Precise but not accurate PI number: 3.12134352343435
- Accurate but not precise number PI number: 3.14
- Try to be accurate not precise
- Precision gives false confidence about estimation
Estimation⌘
- What is the height of the highest mountain
- What is the longitude of Reykjavik
- What is the latitude of Reykjavik
Estimation Exercises⌘
- Choose couple of user stories
- Each person in a group should write down their estimations without communicating with each other
- Then, each person tells their estimates and quickly explain why (the components)
- If there are discrepancies, take another round for the same story
Iteration (Sprint)⌘
- Estimating and Planning (4+1)
- Define clear goals
- Everyone (not only the person who are going to develop it) MUST understand the task
- Everyone can contribute their way they see is the best
- Daily Scrums (15min every day)
- Demonstration (1h)
- Retrospection – post-mortem (1h)
Exercise⌘
Put the proper names in the boxes above using words: Scrum, Retrospective, Demo, Planning, Estimating
Advert⌘
More about User Stories, Epics, Use Cases and prioritization can be found in Product Owner Course available at http://www.nobleprog.com/scrum-product-owner/training-course
Information Radiators⌘
SCRUM WALL
Product Burn-down Chart⌘
Sprint Burn-down Chart⌘
Tools⌘
Post-it vs tools⌘
- Tools can confine your choices
- Post-its are simple and always visible
- Tools are recommended when you work with an outsourced teams’ members
Iteration Duration and Team Velocity⌘
- Do not change the duration of an iteration!
- What if we discovered new tasks to do in order to complete user story?
- Measurement – hours or finished tasks
- What does it mean done
- Overtime
- Adjusting next iteration
Team Responsibility⌘
- All team members are responsible
- Hit-by-the-bus factor
- Openness
- Support and knowledge exchange
- Pair programming (one keyboard)
- Master-lamma pair programming
Daily Scrums⌘
- The questions must be asked:
- What have I done since the last Daily Scrum?
- What am I going to do between now and the next Daily Scrum?
- What is preventing me from doing my work?
- People MUST stand
- Up to 15 min regardless of the team size
- Everyone invited, only pigs are talking
Scrum guidelines⌘
- Product Backlog Planning (PO, Managers, Application Users)
- Sprint Planning Meeting (Team, PO, SM)
- Estimation
- Iteration (Sprint) from 2 to 4 weeks - Daily Scrum (stand-up meeting)
- Demonstration
- Iteration review (retrospective meeting)
Scrum Pros and Cons⌘
| Pros | Cons |
|---|---|
|
|
Agile Risk Management⌘
Risk Adjusted Backlog ⌘
©Agile Risk Management, a blog post by Mike Griffiths, http://leadinganswers.typepad.com/leading_answers/2007/09/agile-risk-mana.html Relates PMBOK risk management to Agile methods, contains several great ideas and graphics, including the “ risk burn down graph.”
Risk Burndown Graph ⌘
©Agile Risk Management, a blog post by Mike Griffiths, http://leadinganswers.typepad.com/leading_answers/2007/09/agile-risk-mana.html Relates PMBOK risk management to Agile methods, contains several great ideas and graphics, including the “ risk burn down graph.”
Scrum and...⌘
- documentation - You still need some sort of documentation
- budgeting
- outsourcing
- bigger projects
Where not to use SCRUM⌘
- If you know requirements upfront and model must be proven - Life critical projects (medical, army, etc...)
- Cannot change the way clients or your management thinks
- Old ways work fine ; -)
Painful Transition⌘
- What happened to Gantt?
- Time reporting?
- Documentation?
- Responsibility
- Clients involved all the times
Beware of these PITFALLS ⌘
TOP 10 REASONS AGILE PROJECTS FAIL
- Tansistioning without proper Training/Coaching
- Resistance To change
- Seating Arrangement
- Poor Communication/Collaboration
- Lack of Transparency
- Fear
- Process without Principles
- Not empowering the teams
- No proper Retrospection
- Still no cross-functional team
Scrum of Scrums ⌘
©Mike Cohn (http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting)
Frequency:
- As needed
Agenda:
- What has your team done since we last met?
- What will your team do before we meet again?
- Is anything slowing your team down or getting in their way?
- Are you about to put something in another team’s way?
Tools⌘
- JIRA (Greenhopper)
- Redmine
- Xplanner (deprecated)
- Google Calc (be careful)
- Agilo
- Scrumy
- Spreedsheet (deprecated)
- Wiki
Books⌘
Other Agile Methodologies⌘
- Extreme Programming (XP)
- Feature Driven Development (FDD)
- Dynamic Systems Development Method (DSDM)
- Crystal
- Lean Software Development
- Kanban
XP Practices⌘
XP consists of number of powerful core practices which help in succeeding with scrum. They are:
- Small Releases
- Collective Code Ownership
- Coding Standards
- Continuous Integration
- Test Driven Development (TDD)
- Continuous Refactoring
- Simple Design
- Pair Programming
Exercise⌘
- Choose roles
- Create backlog
- Start Release Planning
- Estimate the Stories (cards)
- Come up with Release Plan based on velocity
- Conduct Sprint Planning meeting
- Assign the stories/tasks to people
- Develop the product in iteration
- Conduct the DEMO
- Conduct Retrospective
Scrum - Lets Summarize⌘
- Accepting uncertainty
- Welcome technology changes
- Delivering early and often
- Constant estimating and planning
- Sustainable work pace
- Early feedback and learning
- Self managing work environment
- Self controlling environment
- Delegating the responsibility
- Have fun at work
