Education 

Scrum in 16 Minutes

$23.20

Agile Software Development with Scrum (Series in Agile Software Development)

From Amazon

Sales Rank 83551 Schwaber, Ken/ Beedle, Mike

eXtreme Programming is an ideal many software shops would love…
Buy now

Language:
[Music]according to the scrum guide scrum is aframework for developing delivering andsustaining complex products scrum is acollection of roles events artifacts andrules that help teams work together moreeffectively and harmoniously it's beenin wide use for over 20 years in avariety of industries ranging fromsoftware development where it is bestknown to harbor development marketingand even nonprofits because scrum ishighly compatible with the agile valuesand principles practitioners consideredto be an agile framework along with leanKanban XP and many others so let's startwith their company's vision our missionthis is why we show up to work every dayright if you're in a bigger company youmight have multiple products each withtheir own vision either way you've got asense of where you want your company orproduct to be over the course of thenext one to three years or so personallyI think it's useful to write visionsfrom your customers perspective onecompany vision statement that I reallylike is Amazon's our vision is to beearth's most customer centric company tobuild a place where people can come tofind and discover anything they mightwant to buy onlinecompare this to a vision statement likewe're the biggest online retailer in theworld another way of thinking of it isthis your vision statement reflects yourbig impact in the world the value thatwe wouldn't have if your company didn'texist to use Steve's jobs terminologyit's your dent in the universe yourvision should be succinctly stated rightsize and scope and realistic enoughgiven your current and likely futurecapabilities visions help us understandthe strategy while having a roadmaphelps us understand our tactand desire timing while a vision helpsus understand where we want to be in afew years a road map projects what willwe be doing over the next three to fourquarters but either way your road map isstill just a wish list basicallyinformation that you have available toyou now it will almost certainly changeover the course of the next severalmonths if it doesn't this should be ahuge red flag that you're notincorporating enough feedback from yourusers quickly enough one of the biggestways a technology company createspositive user outcomes is to outputreliable working software notice there'sa difference between output and outcomesyou probably need some working softwareto get positive outcomes for your usersbut there's no guarantee that aparticular set of outputs will producethe desired outcomes working software isjust half the battle if you want to keepbuilding working software quickly in thefuture and keep your customers happyyou're going to need to make sure you'vebuilt the software well agile teams usea definition of done to help themdetermine whether or not their softwaremeets their quality bar it's adocumented team agreement that specifiesthe conditions that must be met such asautomated testing and scalability beforethe team calls a piece of work doneisn't done this helps protect the teamfrom building up costly technical deathokay so over what time horizon two teamsdo work scrum teams complete work in oneto four week cycle is known asiterations or sprints the team expectsto create a done demonstrable andpotentially shippable product incrementbased on my experience coaching dozensof teams I now suggest one to two weeksSprint's three to four week Sprint'sdon't allow teams to iterate quicklyenough and allow for nasty anti patternsto creep in what work will they completein that sprint the team will refer to asprint backlogprioritize lists of the most valuablework that is ready for the team to workon now the team doesn't strictlyguarantee they'll they'll get all ofthis work done it's just a forecasthealthy team should be able to fullycomplete somewhere between 85 percentand a hundred and fifteen percent ofwhat they planned on let's take a momentfor an important discussion why do wesay that this is a forecast instead of acommitment it turns out that theofficial scrum guide used to saycommitment but they change it in 2011because quote reality keeps on showingus that it is difficult if notimpossible to always fulfilled thisself-imposed commitment without makingcompromises to quality on the other handthe chosen alternative forecast has todo with making assumptions based onreliable information and evidence thisis much closer to how an experiencedscrum team works that said the teamshould feel comfortable committing tothe Sprint goal which would be writtenin such a way that it can beaccomplished even if not all the itemsin the sprint backlog are completedwhere does a team get the work for theSprint backlog they get it from theproduct backlog a prioritized list ofwork that the team intends to work onfrom now to the medium term futureproduct backlogs contain every piece ofwork your team plans to work on workthat you plan to do in the next sprintor two will be granular and capturedwith detailed acceptance criteria whilework that you don't plan are doing foranother several months will be lessgranular you should have just highlightsof what you hope to accomplish by theway the official scrum guide calls us aproduct backlog but I think team backlogis more accurate this is because asingle team may be working on multipleproducts but should only work from onebacklog notice how some of the work onyour product backlog will be ready towork on while some isn't how do weprevent items from making it onto thesprint backlog before they're readywe use a definition of ready a documenta team agreement that specifies theconditions that must be met such asbeing the right size and having clearlyarticulated acceptance criteria that theteam understands before the team pullsthe item into the sprint backlog so whoare all the people doing all of thiswork first we have the product ownerthey are responsible for maximizing theoutcomes and impact from any given setof output that a team might produce whatthis means is that two development teamsmay write the same amount of softwarebut the saucier that one team producescould be far more valuable to users thatteam probably had a more experienced andempowered product owner this individualhas an incredibly important role andthey need to be fully enabled by theirorganization to set the productdirection in a nutshell the productowner is responsible for what and whywhat we're building and why we'rebuilding it next we have the entirecross-functional development team somecompanies think that just softwaredevelopers blame belong in thedevelopment team but I think that'sshort-sighted I found that teams are farmore functional when a wider breadth ofskillsets such as user experienceQuality Assurance and operations arealso on the team just as product ownersmust be empowered to decide what to workon the development team must beempowered to determine how and when howwe will meet the desire to use youroutcomes and when it will be potentiallyreleasable you've probably figured outthat the product owner has a need forspeed while the development team has areal need for quality they're both rightwho keeps all this in balancethat's right the scrum master the scrummaster is responsible for coaching boththe product owner and the developmentteam on effective scrum they teach andreinforce scrums values principles andpractices they are a servant leader forthe product owner development team andbroader organizationhow do we make work ready to work ononce or twice a week the whole team getstogether product owner scrum master anddevelopment team and reviews and refinesthe product backlog together we callthis event backlog refinement thoughsome people might refer to it as backloggrooming although this isn't an officialscrum event I see it in mostimplementations the product owner bringsup user stories and begins a clarifyingconversation with the team to improvethe quality of each user story forinstance suppose the product owner saysthat they would like a cup of hot coffeea member of the development team mightask how hot is hot after a briefconversation they'll decide on a moreobjective measurement of temperature andupdate the user story our goal will behad to have one and a half to twoSprint's worth of ready stories by thetime we start our next sprint the Sprintitself begins with sprint planning thepurpose of sprint planning is to adetermine what can be most likely todelivered in the next sprint and be comeup with a high-level plan for how thatwork will be accomplished only thedevelopment team can decide what it canaccomplish over the upcoming sprint theywill do this by considering the workcompleted and left incomplete from theprior sprint the team's capacity at thissprint and the team's historicalperformance teams often overcome iteither due to pressure from the productowner or naive optimism the scrum masterwill discourage this with effectivecoaching how do you determine areasonable sprint backlog thedevelopment team decides together howwe'll complete the work this sprint mostteams decompose user stories bugs andother product backlog items into moregranular tasks generally taking a day orless this is effective because thehigh-level design of the software occursin a high bandwidth facilitated eventwith all subject matter experts presentnow the team has kicked off their sprintthewe'll check in with each other every dayin an event called the daily scrum ordaily stand-up this is a 15-minute timebox event that allows a development teamto synchronize their work and plan forthe next 24 hours it's out of the sametime in place every day during the dailyscrum each development team membertypically answers three questions whatdid are you yesterday that will help ourteam meet our sprint goal what will I dotoday that will help our team meet oursprinkle and do I see any impediments orblockers that will prevent me or theteam from meeting our sprinkle manyteams will also use this opportunity toreview the quantity of remaining workand come up with a mitigation strategyif the team isn't on track to meet theirsprint goal at the end of the Sprint theteam will demonstrate their work tocustomers and other stakeholders and anevent called sprint review or the sprintdemo at a minimum the team willdemonstrate completed work solicitfeedback and answer questions teams willalso often discuss the current productbacklog recent developments that mayjustify a plan change and any notablemetrics finally this break concludeswith a retrospective this is when thewhole team inspects his own performanceand creates an improvement plan for thenext sprint it occurs after the reviewand before the next sprint planningevent together the team will inspect howthe sprint went in terms of team culturestructure processes and tools from thereit can identify major opportunities topersist what went well and change whatdidn't lastly the team will come up witha plan for continued self-improvementusually through actions experiments orchanges in team behavior for the nextsprint now there's a few roles thataren't part of official scrum but we canfind them in nearly every organizationfirst we have our stake holdthey are in theory our best proxy forend customers and users it's temptingfor a stakeholder to attempt to exertundue influence over the team toprioritize their specific requests somecompanies might even create incentivestructures that don't reflect realitysuch as having several stakeholderswhose bonuses all depend on getting afeature shipped this quarter even if theteam can deliver only one a good productowner can effectively work throughconflicts between stakeholders andcreate a roadmap and team backlog thatmaximizes value for the whole companynext we have our managers everyone fromengineering managers to productdirectors as teams move to becominghighly autonomous and self-organizing todescribe the traditional command andcontrol role of managers must beabandoned in favour of true servantleadership this change can be extremelydifficult for many managers in fact itrequires a much greater degree ofpsychosocial maturity and emotionalintelligence a skillful agile coach orscrum master if empowered can helpmanagers make this transition whichleaves us last with our executives whichcovers almost everyone with a chief roleas well as everyone on the boardthese individuals are far and away thesingle greatest factor and whether ornot any agile transformation will besuccessful they define the company'sculture through the behavior that theyexhibit and promote literally a leadersuch as an engineering manager cannotcreate safety and autonomy for theirteams if they do not feel safe undertheir leaders as well if we promote amanager with a habit of barking commandto control orders all the feel-goodculture events and posters won't fosterdevelopment of true servant leadershipso we talked about the fundamental rolesartifacts and events but you'll find inan organization as practicing scrum wellwhat's the end result let's suppose wecreate the right culture build aneffective organizational structure andlet teams to find the processes andtools that work best for themafter practicing textbook scrum longenough to fully internalize it what didwe get we create an environment whereeveryone feels empowered to creativelysolve the problems thanks for listening[Music]

Learn the fundamentals of Scrum in just 16 minutes. Covers the key events, roles, and artifacts. Big thanks to Steven Smith for the idea.

$23.20

Agile Software Development with Scrum (Series in Agile Software Development)

From Amazon

Sales Rank 83551 Schwaber, Ken/ Beedle, Mike

eXtreme Programming is an ideal many software shops would love…
Buy now

Related posts

Leave a Comment