Introduction to Agile & Scrum

Editor's Notes

• #4: ICE BREAKER
• #8: Sequential = Waterfall, V-model
• #11: Try to inject some humour… for example the red logo with the hat is his professional logo on his web site, would you trust that? Maybe share an anecdotal story about one of the people. Say who they are. From top left, anti clock wise Jim Highsmith – Adaptive Systems Development Kent Beck – TDD, extreme Programming Ward Cunningham – Wiki, Fitnesse Ken Shwaber – Scrum Martin Fowler – extreme Programming Ron Jefferies – Extreme Programming Alistair Cocoburn - Crystal
• #12: In the 90’s and since they were delivering projects that delighted their customers, surrounded by IT projects failing left right and centre.
• #13: 1970 – Winston Royce paper of software engineering published, later on people started to call it ‘waterfall’ 80s onwards Rate of change increases significantly in business 1986 - Hirotaka Takeuchi and Ikujiro Nonaka – The new new product development game, published, it has many elements that are in Scrum. 90s rise of the ‘light weight methodologies’ (93 Scrum) http://en.wikipedia.org/wiki/Lightweight_methodology Feb 2001, 17 software developers created the agile manifesto 2013 Domination of Scrum
• #14: This is why, managers get excited about ‘agile’, they have been sold on this value proposition. This is what managers are being sold on for agile. You should know this slide inside and out. Reduce risk by providing quick feedback. Feedback on features, team fit, technology, other potential issues Visibility – tracking working software vs artefacts i.e.documents Adaptability – Business Value – validating working software by business people.
• #15: 1. Define outcome of a successful project. Games from http://tastycupcakes.org/2009/06/presto-manifesto/ Timing: 10 mins Ingredients: Whiteboards and/or flip-charts Markers Recipe: Begin by defining what success on a software development project means. Is it only about being on time and on budget? What about customer satisfaction?Divide the participants in to groups and ask them to, based on their project experiences, come up with a list of criteria that they have noticed as critical elements on successful projects.Ask them to reach a consensus within their team and have each member sign off on the criteria they agree with.Look for patterns between each team’s list and then discuss. Compare each teams list with the list that the 17 signatories of the agile manifesto came up with.You will be surprised at the results, regardless of the participants experience with agile. You will rarely see any team come up with prescriptive practices and I have yet to come across a list that did not include customer collaboration, communication, and team dynamics. Learning Points: The agile manifesto is a set of factors that are considered common on successful projects. These successful factors are not entirely new to our industry. The agile manifesto does not prescribe specific practices, reaching a wide consensus on these would be very hard.
• #16: You should know this slide inside and out. discuss what the problem is (not the right people involved, too many people etc) and try to find a solution that involves people and how they interact vs using a new tool without understanding the problem. Tracking working software vs tracking documentation. Internal vs external customer. Working together and starting early. Respond to all kinds of changes e.g. team, feedback, tooling, +ve/-ev, solutions
• #17: Agile is a great idea, but hard to follow. Most people want a simple process / guide to follow.
• #18: Here you can see that Scrum is hugely popular compared to other agile methodologies.
• #19: Combining all of the Scrum hybrids it is even more dominate. Scrum is the simple framework that allows people to be agile, if they can follow it.
• #21: Finding the fun early, is crucial in games development. Scrum done well, reduces crunch periods.
• #22: Finding the fun early, is crucial in games development. Scrum done well, reduces crunch periods.
• #23: It is possible to be Scrum master and Team Member It is NOT possible to be Product Owner and Scrum Master It is NOT possible to be Product Owner and Team member The conflicts of interest are just too great for the team to be truly successful.
• #27: NEED TO PRACTICE DRAWING DIAGRAM. Check video of Lisa Crispin. Draw out the process on the whiteboard, answering questions as you go. Image from: http://www.scrumprimer.org/overview Roles: Scrum Master, Product Owner, Team Member Ceremonies: Planning, Story Workshop, Stand up, Review, Retrospective Artefacts: Backlog, Sprint Backlog, Taskboard, Burndown, Product Increment. Additional: Definition of Done, Co-location
• #28: Please note, this is just an example Definition of Done, it is by no means a recommendation for what a DOD should be in GameSys.
• #30: Game on tastycupcakes.org: http://tastycupcakes.org/2014/01/scrum-roles-and-responsibilities-game/ Split the attendees into two groups of 3 to 8. Each group gets a sheet of butchers paper with the three sections (Team, SM, PO). It is best to put these on the corners of the table so that more people can gain access. Shuffle each deck of index cards and evenly spread them amongst each team. ROUND 1: Give everyone 1 minute in SILENCE to place their cards without touching anyone elses cards. They will need to be neat as the cards will cover the paper. ROUND 2: Give each team 5 minutes to review the place of cards, update them and agree. ROUND 3: Get teams to switch sides, review each others place and discuss between teams. What additional activities would you add? Cards include (39 so far): Prioritise Backlog Talk to stakeholders Make Product Backlog visible Ensure quality x 3 (PSS) Create Product Backlog items x 2 (PS) Build Design Test Deploy Integrate Attend Daily Stand up x 3 Attend Sprint Planning x 3 Attend Sprint Review x 3 Attend Backlog Grooming x 3 Attend Sprint Retrospective x 3 (PPS) Ensure Scrum is followed Coach team Facilitate Scrum events Resolve technical impediments Resolve organisational impediments Improve process Improve technical practices Track sprint progress Track release progress
• #31: Get them all to read this quote.
• #36: What are the impacts of each of these Scrum buts?
• #41: Finding the fun early, is crucial in games development. Scrum done well, reduces crunch periods.
• #43: You can use whatever format you like for User Stories, they are not locked in stone. However this format has several key benefits, that make it worthwhile. 1. We can confirm that the User will receive the benefit (link ‘as a’ line to the ‘so that’ line). 2. We can confirm that the output has a good chance of producing the benefit (link the ‘I want’ line to the ‘so that’ line). Hence we stand a better chance of making an impact.
• #45: Who has used User Stories? Do you have any stories about User Stories that were tough or painful to work on? Which INVEST properties did they miss out on?
• #46: INVEST came from Bill Wake For the Team to take into a Sprint Aim for as many as possible Compromise
• #47: Blue – So that, just repeats the I want to. It is actually a regulation in some countries to inform the user of their play time. Green – this is a phase ‘testing’, so it is highly dependent. Purple – user is missing, business benefit is missing. Orange – non negotiable, how do we know that the most realistic result will come from the colour silver, at that angle, etc.
• #48: This is how many people are used to working. The product is split into architecture layers / components, with teams formed around those components. Our product owner wants some functionality for the user. (I point to the top part of Story D). In this situation the work is split into four user stories, 1 per component/team. The first team starts work on Story A, they build and unit test their work, mark it as done, and let the next team know. (I point out a circle inside Story A). The next team starts work on Story B, they build and unit test their work, integration test their work with Story A, find some mistakes in A and get that team to fix them. (I point out an elipse, across story B and Story A) Repeat for C and D. Over all there is a lot of dependencies, a lot of retesting, waiting and uncertainty. Some companies may be set up so that there are only two teams/components, however there is still dependencies, delays etc.
• #49: In this situation we have the same architectural layers, however now our teams are cross functional. Again our Product Owner wants some functionality of the User Interface for the user (point to the top) This time, the work is split up into vertical slices by functionality. i.e. We deliver a small piece of functionality, Story A, where the team builds and tests all components at once. Then they move onto building the next slice. This is a vertical slice and it is what we want ALL of our user stories to be.
• #50: Non functional aspects include things such as performance, scalability, visual aspects, etc.
• #51: I got the drawing from the web, (not sure where from, so Gamesys cannot claim copyright over it).
• #52: You can also talk about increasing Fidelity between the three stages.
• #53: The team is building some parts at low fidelity, than adding more bits at low fidelity while increasing the fidelity of others. This allows for LOTS of fast feedback.
• #57: Finding the fun early, is crucial in games development. Scrum done well, reduces crunch periods.
• #58: Everyone put up their hand, when they know roughly how many centimetres the line is? Everyone put up their hand, when they know if the second line? The second question was answered much faster, because humans are naturally good at Relative Estimation, yet we are naturally poor at absolute estimation.
• #59: Agile estimation, uses relative estimation techniques. It also leverages the knowledge of the whole team, (devs, testers, business, designers) Lastly we focus on speed over accuracy, we just need the estimate to be accurate enough to prioritise and plan our work.
• #60: Effort – Raw effort / grunt work. I.e. Making a simple parameter change to hundreds of similar method calls. Complexity – Difficulty, hard algorithms, complex logic extra, abstract concepts. Doubt – Uncertainty around how will we build it or what it is that we need to build.
• #62: http://www.journey-to-better.com/2013/07/story-points-do-not-equate-to-time.html
• #64: If consensus is not coming, pick the number selected by the majority of participants. Do not average the numbers.
• #66: Hand out Planning Poker cards to everyone and explain to them that they are the Fruit eating team. You are the Scrum master and Product Owner (conflicted I know) Set Apple as the Reference Story with 2 Story points. Ask the team how they would eat the apple, making notes on the board. That is now their reference. Move onto estimating each piece of fruit in order. Each time asking how they will eat it prior to estimating. Definition of Done (this can be revealed bit by bit through the exercise) 80% of flesh eaten All other remains in the bin Kitchen and utensils are clean. Team hands and face are clean.
• #67: It took us about 20 minutes to estimate 5 pieces of fruit, we are now going to estimate cooking 26 meals in about 15 minutes. We are going to use Fast Estimation. http://www.journey-to-better.com/2012/05/fast-estimation.html
• #68: It took us about 20 minutes to estimate 5 pieces of fruit, we are now going to estimate cooking 26 meals in about 15 minutes. We are going to use Fast Estimation. http://www.journey-to-better.com/2012/05/fast-estimation.html
• #71: Finding the fun early, is crucial in games development. Scrum done well, reduces crunch periods.
• #73: Draw graph (Value vs. Time) Line 1: consistent delivery of value Line 2: emphasising value first.
• #74: Add to graph Line 3: reducing risk / uncertainty first
• #75: Credit Alistair Cockburn: http://alistair.cockburn.us/Disciplined+Knowledge+Acquisition+in+Product+Development
• #76: Split the attendees into two teams Hand out the index cards with the User Stories written out, to each team. Explain the value, risk and story point scales. In 5 minutes get the teams to order their backlog. Now switch sides and compare ordering.
• #82: Finding the fun early, is crucial in games development. Scrum done well, reduces crunch periods.
• #83: In sequential development, work is divided up into phase (you can see here as red, green, light blue, dark blue). They are mostly carried out in a sequential order with some overlap between each phase.
• #84: FE – Front end development, BE – backend development, QA – quality assurance /testing. As you can see this is more complex than sequential development, yet delivers completed work each sprint. Curves from Mountain Goat Software – redistributable introduction to scrum.
• #85: We will discuss each of these approaches on the coming slides
• #87: Linked tightly to Iterative & Incremental User Stories, Refactoring, Simple Design, Continuous Integration
• #88: Everyone is responsible for some element of managing technical debt.
• #90: These Technical practices (most of them comes from eXtreme Programming) are needed for us to have any hope of apply continuous development. Explain each practice. Simple Design – also know as Just in time Design. Only design for what you are working on now. Collective Code Ownership (from XP) was left off, because Gamesys does not have a strong push for it.
• #93: Ask the attendees for examples from each quadrant, helping them out as need be. The full set is revealed on the next slide. Credit: http://lisacrispin.com/wp-content/uploads/2011/11/Agile-Testing-Quadrants.png
• #94: Credit: http://lisacrispin.com/wp-content/uploads/2011/11/Agile-Testing-Quadrants.png
• #98: Finding the fun early, is crucial in games development. Scrum done well, reduces crunch periods.