Using Scrum to Streamline Web Applications Development and Improve Transparency. Michelle Frisque

Transcription

1 Using Scrum to Streamline Web Applications Development and Improve Transparency Michelle Frisque September 2010

2 OVERVIEW! Background! The problem! The proposed solutions:! Creation of Web Committee! Implementing SCRUM! Implementing User Stories! Lessons Learned! Questions! Resources

3 The Galter Health Sciences Library The Galter Health Sciences Library

4 Information Systems Department

5

6

7

8 OUR SOLUTION! Web Committee! SCRUM! User Stories

9 WEB COMMITTEE Charge:! Plan, design, test and implement ongoing enhancements to the library's web presence! Coordinate and prioritize web projects for both the public-facing and the administrative functions of the website Membership Total: 10 +

10 Search Patron Services Home Page/ Design/ Navigation GalterLists Web Committee Gadgets (retired)

11 Insert Screenshot of Trac Here Trac screenshot

12 The perfect is the enemy of the good. Voltaire

13 SCRUM

14 SCRUM WORKFLOW

15 THE RULES When rules are not stated, the users of Scrum are expected to figure out what to do. Don t try and figure out a perfect solution, because the problem usually changes quickly. Instead, try something and see how it works. The inspect-and adapt mechanism of Scrum s empirical nature will guide you. Scrum Guide by Ken Schwaber, May 2009

16 SCRUM TEAM! Optimal size is seven people, plus or minus 2.! Team composition may change at the end of each Sprint however productivity will decrease after the change occurs while the team adjusts to the change and new members get up to speed.! Our Team:! Programmers! Web Committee Subcommittee Chairs! Total: 6 people

17 SCRUM TEAMS: ROLES! Team Member! ScrumMaster! Product Owner

18 TEAM! Team determines how to turn the Product Backlog into increments of shippable functionality.! Team members must have the skills necessary to create an increment of work, i.e. programming, content, quality control, business analysis, architecture, user interface design, database design, testing, etc.! Diversity of skill and expertise leads to a synergy that improves the entire Team s overall efficiency and effectiveness.

19 SCRUMMASTER! Ensures the Scrum Team adheres to Scrum values, practices and rules.! Helps the Scrum Team and the organization adopt Scrum.! Teaches the Scrum Team so it can be more productive and produce higher quality projects.! The ScrumMaster should never be the Product Owner.

20 PRODUCT OWNER! Responsible for managing the Product Backlog! Maintains the Product Backlog and makes sure it is visible to everyone. [We use Trac to maintain our Product Backlog.]! Is one person, it should not be a committee.! Committees can advise and influence the Product Owner to change an item s priority; however the Product Owner has final say as to an item s priority.! Should be a person that is respected.

21 Function of Web Committee Subcommittees Preparing for Sprint:! Assign priorities to their projects (Product Backlog)! Work with project requester to gather project requirements During the Sprint: If their project is selected for a sprint the Subcommittee:! Tests the project! Signals project is ready for production

22 SPRINT Time Box Identify the projects for the Sprint from the Product Backlog. Products created Tested Revised All products are reviewed Products are accepted or rejected Team reviews the Sprint process and makes adjustments accordingly 2 to 4 weeks

23 SPRINT LOGISTICS! If Team discovers it has overcommitted, it meets with the Product Owner to remove or reduce the scope of the Product Backlog selected for the Sprint.! If time is still available in the Sprint but all Products are completed, the Product Owner can add a Product from the Product Backlog to the current Sprint.! Sprints can be cancelled before the specified end date.! Multiple Scrum Teams can be going at the same time.

24 SPRINT PLANNING! When the Team plans the iteration (Sprint).! Planning for a 1 month sprint should take 8 hours (allocate approximately 5% of the total Sprint length to the meeting).! First half of meeting: determine what will be done in the upcoming Sprint.! Second half of the meeting: determine how each project will be accomplished.

25 DEVELOPMENT WORK! The team works on each Product assigned for the month s Sprint.! Daily Scrum: Team meets daily for 5-10 minutes to update members on what was accomplished, how long it took and what will be done today.! Daily Scrum is designed to improve communication, identity and remove impediments to development, highlight and promote quick decision-making and improve everyone's level of project knowledge.! We track the progress on a whiteboard that is in the hallway of the Information Systems Department.

26 DEVELOPMENT WORK Jeremy Not Started In Progress Done Tested Live Steve Team

27 SPRINT REVIEW! Held at the end of the Sprint.! A 4 week Sprint = 4 hour meeting; meeting must not take more than 5% of the total sprint.! Product Owner identifies what has been done and not done.! Scrum Team and Stakeholders review what was done, how well it was done and discuss possible next steps.! Products are demonstrated.

28 SPRINT RETROSPECTIVE! Performed after the Sprint Review and before the next Sprint Planning Meeting! Identify what processes worked and did not work during the last Sprint! Identify solutions on how to improve what did not work during the last Sprint.

29 SAMPLE SPRINT Review Product Backlog Before the Meeting

30 SAMPLE SPRINT Sprint Planning Meeting: Identify Projects

31 SAMPLE SPRINT Setup the Sprint (aka Sprint Planning)

32 Jeremy Not Started In Progress Done Tested Live Steve Team SAMPLE SPRINT Daily Update (aka Daily Scrum)

33 SPRINT Tracking Progress of each Sprint can be followed on the whiteboard outside of the Information System Department offices.

34 SAMPLE SPRINT Sprint Review/Sprint Retrospective

35 Web Development Architecture Staff Computer Development Web Server Production Web Server

36 Lessons Learned! Assign a Project/Product Lead who is responsible for final approval of each Product.! Clearly define the Project and parts that will make up the Project.! Make sure to leave enough time in the Sprint to test the Product.! Major Projects (that we know will span across several Sprints) should be put in their branch in Subversion and broken into Sprint-sized goals.

37 Transparency

38

39 USER STORIES! Template: As a <<user - specify which user>> I want to <<description of feature here>> so that <<value -- why do you want to do it>>.! Example: As a user (that started as an NU Undergrad and is now an FSM affiliate), I would like the website to re-check my affiliation against Voyager (or equivalent) so I can avoid being blocked from resources I should be allowed to use. (ticket 794)

40 Conclusion! Stakeholders have a say in which web projects go forward! More information is shared! Products are making it to the user faster! Allows us to gather user feedback faster! Projects are more defined before they are undertaken

41 Questions?

42 Resources! New New Product Development Game by Hirotaka Takeuchi, Ikujiro Nonaka. Harvard Business Review. Publication date: Jan 01, 1986! Scrum Guide by Ken Schwaber, May Scrum.org ScrumAlliance