1. Agnius Paradnikas
IT PROJECT MANAGEMENT
AND SCRUM, PART II
Page 1 IT project management and Scrum, Agnius Paradnikas
2. Table of Contents
PART I, IT PROJECT MANAGEMENT
• Complexity of software development projects
• Classic mistakes
• What is Agile?
PART II, SCRUM
• Traditional projects vs. Scrum projects
• Scrum
• Scrum history
• Basics
• Definition of Done
• My experience
Page 2 IT project management and Scrum, Agnius Paradnikas
3. Traditional projects
Assumptions:
• Customer knows what he wants
• Developers know how to build it
• Nothing will change along the way
Pictures from Vaidas Adomauskas slides | http://www.slideshare.net/vaidasa/agile-and-
agile-methods-what-is-the-most-important-to-understand-to-succeed
Page 3 IT project management and Scrum, Agnius Paradnikas
4. Traditional projects
We don’t know where we are
and how much work left to be done.
Effort
level
We won’t Deadline Time
finish!
Picture from Vaidas Adomauskas slides | http://www.slideshare.net/vaidasa/agile-and-
agile-methods-what-is-the-most-important-to-understand-to-succeed
Page 4 IT project management and Scrum, Agnius Paradnikas
5. Traditional projects
• We imagine that software development can be planned, estimated, and
successfully completed.
This has proven incorrect in practice.
• Software development process is an unpredictable, complicated process
that can only be roughly described as an overall progression.
Page 5 IT project management and Scrum, Agnius Paradnikas
6. Scrum projects
• While it is often said that Scrum is not a silver
bullet, Scrum can be like a heat seeking missile when
pointed in the right direction.
Source: “The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework” -
Jeff Sutherland - Somerville, MA USA, 2010
Picture from Vaidas Adomauskas slides | http://www.slideshare.net/vaidasa/agile-and-
agile-methods-what-is-the-most-important-to-understand-to-succeed
Page 6 IT project management and Scrum, Agnius Paradnikas
7. Scrum projects
Assumptions:
• Customer discovers what he wants
• Developers discover how to build it
• Things change along the way
Pictures from Vaidas Adomauskas slides | http://www.slideshare.net/vaidasa/agile-and-
agile-methods-what-is-the-most-important-to-understand-to-succeed
Page 7 IT project management and Scrum, Agnius Paradnikas
8. SCRUM
Picture by Softhouse | http://softhouseeducation.com/
Page 8 IT project management and Scrum, Agnius Paradnikas
9. Scrum history
www.agilemanifesto.org
We are uncovering better ways of developing
software by doing it and helping others do it.
Feb 11-13, 2001
Snowbird ski resort, Utah
Kent Beck Ron Jeffries
Mike Beedle Jon Kern
Arie van Bennekum Brian Marick
Alistair Cockburn Robert C. Martin
Ward Cunningham Steve Mellor
Martin Fowler Ken Schwaber
James Grenning Jeff Sutherland
Jim Highsmith Dave Thomas
Andrew Hunt
Picture from Vaidas Adomauskas slides | http://www.slideshare.net/vaidasa/agile-and-
agile-methods-what-is-the-most-important-to-understand-to-succeed
Page 9 IT project management and Scrum, Agnius Paradnikas
10. Scrum history
• Jeff Sutherland created the first Scrum team in 1993 at Easel Corporation
• In 1995, Jeff introduced the Scrum to Ken Schwaber
• First formalized the Scrum at OOPSLA’95
• In 2011 Scrum is used in over 75% of Agile implementations worldwide [1]
Jeff Sutherland Ken Schwaber
[1] “The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework”, Jeff Sutherland
Pictures by www.scrum-events.de
Page 10 IT project management and Scrum, Agnius Paradnikas
12. SCRUM
ROLES
Page 12 IT project management and Scrum, Agnius Paradnikas
13. Product Owner
• Sees big picture, vision responsible for Return of Investment.
• Prioritizes.
• Plans releases.
• Final arbiter of requirements questions.
• Presents interest of stakeholders.
• Defines scope.
• Negotiates goals and requirements with the Team.
• Accepts or rejects each product increment.
• Owns the Product Backlog.
• Available for questions.
Picture by Softhouse | http://softhouseeducation.com/
Page 13 IT project management and Scrum, Agnius Paradnikas
14. Scrum Master
• Manages process.
• Removes impediments.
• Firewall.
• Doesn’t command the Team, but helps Team to be self-
organized.
• Helps Team to be efficient.
• Keeps Scrum artifacts visible.
• Helps Product Owner to transform requirements to
product backlog items.
Picture by Softhouse | http://softhouseeducation.com/
Page 14 IT project management and Scrum, Agnius Paradnikas
15. Team
• Delivers DONE piece of software each Sprint.
• Responsible for quality.
• Cross-functional.
• Has autonomy regarding how to reach commitments.
• Self-organizing.
• Intensely collaborative.
• Co-located (ideally in Team room).
• Owns Sprint Backlog.
• 7 +- 2 full-time members.
Picture by Softhouse | http://softhouseeducation.com/
Page 15 IT project management and Scrum, Agnius Paradnikas
16. SCRUM
SPRINT
Page 16 IT project management and Scrum, Agnius Paradnikas
17. Sprint
• Sprint fixed-length iteration.
• 2-4 weeks length.
• Team attempts to build a potentially
shippable (properly tested)
application increment every Sprint.
Pictures by Softhouse | http://softhouseeducation.com/
Page 17 IT project management and Scrum, Agnius Paradnikas
18. Sprint
Effort
level
Sprint Sprint Deadline Time
Picture from Vaidas Adomauskas slides | http://www.slideshare.net/vaidasa/agile-and-
agile-methods-what-is-the-most-important-to-understand-to-succeed
Page 18 IT project management and Scrum, Agnius Paradnikas
19. SCRUM
ARTIFACTS
Page 19 IT project management and Scrum, Agnius Paradnikas
20. Product Backlog
• Prioritized results - oriented list of things that need to be done to
get application ready.
• Anyone can add items.
• Product Owner prioritizes.
• Items at top has biggest priority than items at bottom.
• Often contains requirements, Use Cases, User Stories, features, bugs
and change requests.
Page 20 IT project management and Scrum, Agnius Paradnikas
23. Product Backlog: TFS 2010
Page 23 IT project management and Scrum, Agnius Paradnikas
24. Sprint Backlog
• Prioritized list of Product Backlog Items (PBI) selected to the Sprint.
• Scope is fixed during Sprint Execution.
• Tasks are created by the Team during Sprint Planning Meeting.
• Team member has only ONE task in progress.
• Each task is 1 - 32 hours, for one person.
• Daily update of task progress.
• Team members sign up for tasks.
• Maintained by the team.
Page 24 IT project management and Scrum, Agnius Paradnikas
27. Burndown Chart
• Represents progress: tasks resolved per day
• Updated daily
• Automated
• Sprint Burndown chart
• Remaining effort
• Product Burndown chart
• Velocity
• Trendlines
Page 27 IT project management and Scrum, Agnius Paradnikas
28. Burndown Chart
Picture by Jez Nicholson | http://www.flickr.com/photos/jnicho02/2636053874/
Page 28 IT project management and Scrum, Agnius Paradnikas
30. SCRUM
MEETINGS
Page 30 IT project management and Scrum, Agnius Paradnikas
31. Daily Scrum
• Everyone reports:
• Things I have done since the last Daily Scrum
• Things I will do today
• Impediments
• 15 minutes, same time & place every day.
• Be on time!
• No problem solving!
• Anyone may attend.
• Only Team and ScrumMaster may speak.
Page 31 IT project management and Scrum, Agnius Paradnikas
32. Daily Scrum
Picture by Tom Natt | http://www.flickr.com/photos/tomnatt/3389066169/
Page 32 IT project management and Scrum, Agnius Paradnikas
33. Sprint Planning Meeting
• Product Owner, ScrumMaster and the Team participate.
• Product Backlog must be prepared.
• Part 1: The Product Owner presents what the end user wants.
• Work out all unclear issues regarding the top priority Backlog Items.
• Revised estimations of Backlog Items.
• Product owner defines ”done” characterisitcs for each item.
• Product owner answer all questions.
• Determines a Sprint Goal together with the Team.
• Max 4 hours (all Scrum meetings are timeboxed).
Page 33 IT project management and Scrum, Agnius Paradnikas
34. Sprint Planning Meeting
• Part 2: The Team prepares a Sprint Backlog
• Count the number of resource hours available.
• Break down Product Backlog Items into concrete tasks and estimate them.
• Estimates all Team.
• Poker planning.
• After the meeting every member of the team knows where to start.
• Max 4 hours.
Picture by IT-Zynergy ApS| http://www.it-zynergy.com/scrum-planning-poker
Page 34 IT project management and Scrum, Agnius Paradnikas
35. Sprint Review Meeting
• All stakeholders and otherwise interested should take part
• 2 hours max
• Product Owner reminds the Sprint goals
• Team demonstrates only working software to stakeholders
• What have we achieved
• Should show only finished functionality, no slides
• Plan your demo beforehand!
• Direct feedback from stakeholders (the End User also)
• Feedback incorporated into Product Backlog
• Open discussion as a base for the planning of the next Sprint
Page 35 IT project management and Scrum, Agnius Paradnikas
36. Sprint Retrospective
• The goal is to improve the Team’s work.
• Participates only ScrumMaster and Team.
• Takes part after each Sprint Review.
• Max 2 hours.
• Team reflects on the sprint.
• What went well (keep doing)?
• What could be improved?
• Agree on action points and who will be responsible for that.
Page 36 IT project management and Scrum, Agnius Paradnikas
37. SCRUM
DEFINITION OF DONE
Page 37 IT project management and Scrum, Agnius Paradnikas
38. Definition of Done
• Team should have common understanding what ”Done” means for
core elements of the project: Release, Sprint, Task, etc.
• As close to ”live” as possible.
• Define DoD in a workshop.
• Document it.
• Share it.
• Follow it.
• Essential for reliable estimates!
Picture by Robo Android | http://www.flickr.com/photos/49140926@N07/5734182633/
Page 38 IT project management and Scrum, Agnius Paradnikas
39. SCRUM
SUMMARY
Page 39 IT project management and Scrum, Agnius Paradnikas
41. SCRUM
MY EXPERIENCE
Page 41 IT project management and Scrum, Agnius Paradnikas
42. My experience
Project problems and issues before Scrum
• Unclear and changing requirements.
• Unclear responsibilities.
• No priorities – no focus.
• Bad team spirit.
• Meetings, meetings, meetings…
Page 42 IT project management and Scrum, Agnius Paradnikas
43. My experience
Project problems and issues before Scrum
• No near future goals.
• Iterative process, but no purpose to use iterations.
• Estimating == guess.
• Result doesn’t meet customer expectations.
• Multitasking.
• Developer implement one thing, testers try to test the other.
Page 43 IT project management and Scrum, Agnius Paradnikas
44. My experience
… then we tried to use Scrum…
… and it didn’t work…
Page 44 IT project management and Scrum, Agnius Paradnikas
45. My experience
Why it didn’t work?
• We all had a different understanding about Scrum.
• Team spirit became even worse – in addition we started arguing what
is Scrum and what is not.
• We didn’t use key principles of the Scrum – “OK, it’s agile so we take
only what is suitable for our case”.
• Product owner was not the right person.
Page 45 IT project management and Scrum, Agnius Paradnikas
46. My experience
We took the second shot
• We had Scrum trainings and several meetings to come up with one
understanding about Scrum.
• We agreed to use all Scrum rules and principles, not just part of it.
• We have appointed different person to run Product owner role.
• Our team was too big for Scrum, so some had to leave.
… and then the Scrum slowly started to work!
Page 46 IT project management and Scrum, Agnius Paradnikas
47. My experience
Feedback before using Scrum
“We don't have requirements or understanding what customer needs.
But since it is decided something, it almost impossible to change and make
system better, maybe partially because of leak of trust for offsite team.”
“Work load is estimated before even knowing what exactly is needed to be
done.”
“The main problem is that this project is not product, but jira oriented. It
seems it is not so important what product we are doing, just to have good
jira reports.”
Page 47 IT project management and Scrum, Agnius Paradnikas
48. My experience
Feedback after Scrum was implemented (after 4 months)
“Good team spirit, good cooperation with Onsite, scrum usage, everyone see
the project status, discuss tasks and after sprint thinks what could be
improved.”
“Sprint specific workloads have been estimated better and better during the
project.”
“Good team spirits and a lot of communications. To see our customer
being happy with the developed product.”
Page 48 IT project management and Scrum, Agnius Paradnikas
49. Further reading
• Scrum and XP from the Trenches - Henrik
Kniberg
• Free download:
http://www.infoq.com/minibooks/scrum-xp-from-
the-trenches
Page 49 IT project management and Scrum, Agnius Paradnikas