• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Good-vs-great-agile-teams
 

Good-vs-great-agile-teams

on

  • 1,732 views

Many agile teams start off well. But once the initial energy has dropped, and the team has gained some experience, what’s next? What do great agile teams do that good or failing agile teams don’t? ...

Many agile teams start off well. But once the initial energy has dropped, and the team has gained some experience, what’s next? What do great agile teams do that good or failing agile teams don’t? You will learn how great agile teams develop the skills to continually improve, moving from good teams to high-performing teams that work ‘in the zone’. You will also develop a ‘flight plan’ for your agile team, creating the environment to stay in the sweet spot of high performance.

Statistics

Views

Total Views
1,732
Views on SlideShare
1,728
Embed Views
4

Actions

Likes
1
Downloads
36
Comments
0

2 Embeds 4

http://www.linkedin.com 3
http://www.twylah.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Good-vs-great-agile-teams Good-vs-great-agile-teams Presentation Transcript

    • good vs. greatFrom good, sustainable agileteams to great agile teams
    • phases of teamdevelopmentagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Tuckman (1965) performingFocus on task (productivity) norming forming storming Relationshipagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • after starting a team, are your poll agile teams sustaining (good), performing (great) or regressing?agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Tuckman (1965) performingFocus on task (productivity) norming sustaining forming storming regressing Relationshipagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • change is not the same as progress The last 100 years hasseen lots of improvements in golf clubs but golf scores have stayed the sameagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • empowerment used to mean self-managementagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • today self-organization trumps self-managementagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • how to lead throughchangeagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Know what we don’t know... Ibn Yamin Faryumadi One who doesnt One who knows know, but knows and knows that he (Persian-Tajik poet) knows that he doesnt knows... said there are four know... This is a man of personal awareness This is an illiterate knowledge; get to types of men: man; teach him! know him! One who doesnt doesn’t know One who knows, know and doesnt but doesnt know know that he that he knows... doesnt know... This is a man whos This is a dumb man; unaware, so bring it and would be dumb to his attention. forever! doesn’t know knows personal knowledgeagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • situational leadership (Hersey, Blanchard) The Hersey-Blanchard supporting coaching for people with: Situational Leadership for people with: a lot high competence some competence supportive behaviour Theory rests on two variable commitment some commitment fundamental concepts; • leadership style and delegating directing • the individual or for people with: for people with: little high competence low competence groups maturity high commitment high commitment level little a lot directive behaviouragile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Shu: Learn the basics - focus on followingsteps exactlyHa: Explore the principles through guideddeviations from the basicsRi: Adapt within the principles through self-directed experimentation (c) Alistair Cockburn 2000-2006agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • balance directive andsupportive actions• let the team experience the need, not just talk about it• there are priorities to learning• plan situations, don’t wait for a need to emergeagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • a newly launchedagile team• 1-3 sprints• shared team commitment• emerging xp practices• transparent impediments• balanced feature development and tech debt removalagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • the team crashes?• change is often painful, requiring sacrifice before the reward • pain avoidance, often a result of no strong direction• inside the team: • new incremental changes that violate core principles• outside the team: • management intervention as murder or manslaughteragile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • signs of regressionagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • core concepts underpinning self-organization shippable product team commitment feedback cyclesagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • core concepts underpinning self-organizationpersonal backlog items,parallel and individual work, us shippable& them vocabulary product partial or locally-optimized team delivery avoiding commitment organizational pain-points feedback cycles anything that lengthens feedback loops, or eliminates them altogetheragile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • e.g. no daily standup...because• I need time to develop• we already know what everyone is doing• its just a status reporting meeting• tasks take too long - nothing changes within only one day Potential indicators of something more fundamental: • lack of information • pain avoidanceagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • crossing your arms shouldn’t a little bit of participation feel this awkwardagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • leadership challenge “However most of the high- performance teams were not manager-led teams. They were teams where the management had deliberately stepped back, or was inattentive or where one reason or another was totally absent, thus enabling the team to self- organize.” Steve Denningagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • management attitudes that kill performing teams sometimes its murder - death by intent to kill sometimes its manslaughter - death by negligenceagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • how to destablize a high-performing team• are high-performance teams fragile and short lived, prone to self- destruction? • no – the reality is such teams are often the victim of management practices that result in what Tom Demarco & Tim Lister refer to as teamicide. agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • how to destablize a high-performing team• are high-performance teams fragile and short lived, prone to self-destruction? • no – the reality is such teams are often the victim of management practices that result in what Tom Demarco & Tim Lister refer to as teamicide. • sometimes it’s murder • managers can feel threatened by teams that break rules of the prevailing corporate culture and disband them, in order to preserve the status quoagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • how to destablize a high-performing team• are high-performance teams fragile and short lived, prone to self-destruction? • no – the reality is such teams are often the victim of management practices that result in what Tom Demarco & Tim Lister refer to as teamicide. • sometimes it’s murder • managers can feel threatened by teams that break rules of the prevailing corporate culture and disband them, in order to preserve the status quo• sometimes it’s manslaughter • management misunderstands the high-performance team or its mode of operation and does things that unintentionally eliminate high-performanceagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • sustaining progress• stable progress dependent on learning new skills - focus on process/practices, not principles• become very good at what they do, but miss the continual practice of change• still inertia to change - tend to be dogmatic about rules, not agile• typically teams replace one institutional process with anotheragile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • sustaining agile teams quickly regress to the mean replace one defined process with another dogmatic and selective application of new rules change practices for comfort rather than results learn little in way of new skillsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • sustaining agile teams quickly regress to the mean replace one defined process with another dogmatic and selective application of new rules change practices for comfort rather than results learn little in way of new skillsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • sustaining agile teams quickly regress to the mean replace one defined process with another dogmatic and selective application of new rules change practices for comfort rather than results learn little in way of new skillsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • sustaining agile teams quickly regress to the mean replace one defined process with another dogmatic and selective application of new rules change practices for comfort rather than results learn little in way of new skillsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • growing learningteams• strong product and quality ownership• builds mental muscle for adapting to change• continually practices small change, challenging status quo• focus on accelerated learning practices• hungry for responsibilityagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • great agile teams are continually changing build out good practices without compromise incorporates holistic view / guidance leadership creates environment for successagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • great agile teams are continually changing build out good practices without compromise incorporates holistic view / guidance leadership creates environment for successagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • great agile teams are continually changing build out good practices without compromise incorporates holistic view / guidance leadership creates environment for successagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • realigning regressingagile teams• get commitment to 30-60 days• educate and inform • the +15 team framework leads discussion on agility• move at speed • nay-sayers can be distracted by rapid progress • avoid miss-selling any progress is really positiveagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • ct du Pro ble pa S hip n w ga do and rin urn ts t b poin ly elive rin sp ation ts o done n D is a estim . Poin are ere ly Is Th t uses d dai n PB tha date whe p n ly is u n dow us rs bu r uo e io tin nd th arni av of on s c ality a ive L ctiv e B eh p i rint h e to BIs eam g qu e Ac ospe t Sp mt P et fro 6-10 Th rovin ith th e retr a kes east e into imp ess w ing th m t at l e siz c pro le du r tea g n it s he acklo e sam sprint T b Cy c rs o a s e out th eek ive at le th b w del th f of a ry 1-2 m tea Is a t am t wi tio o+15 team framework kl og ve the 3 PB s e te itmen ty (ra at ac e Th m i sti m int, - Ii bil aB ±2 spr st 2 PB com dicta tted e ri ng s 7 al, ha n the at mo il the re mmi p o pa eam ctio ring n nt Pre D u r k s o i me u to c ve nt t s-fun ry to t of e me os a ss int wo one nd rs a op cr to o l eve d is s nec spr e any e ni n t the e i ve ed n ll a don ow ugh At m del e pro Th ple a e ski side n d ll eno , l o ll th pe a Ii n ro ke a m ay s oard tea ppab or u h r a PB , e b are s 1-2 d taskb hi sed• the +15 team framework leads wit ve n h, r s isio r pitc Is a t in s rele a del i tv uc evato PB ks tha eted team l rod el ents e tas comp n the a p an ay dc discussion on agility be ked o m lu e is ed as quire ss va yd are er s Th res re sine tr ac ver , for a to Sh vely t of se d p i exp a lis by b u eet boar ndu act exa m m task n) sta • what does the core scrum d og for d and ritize ack l e te a e mi ies n p rio uc t b ll 1-2 Th und th x 15 ctivit tre od s to fi e pr BI ro t (ma ys a a r framework look like th da is a P eet sho the t e n M. ere nough all m y lan im Th e t d p ed the S h ha ea p wit ints, t of R n im by kly SM• allows progress to be tracked s pr ition De fi n m t ee . PO PBI tima m s tes Th kl c is a wned e quic or the ere og o s ar am ent e te and oom m es o the ba edim by th • e.g. review every sprint e te m gr a o t Th ularly in th mmit a e te ting t p ed Im olv res e o• brings clarity to the what is reg ryon ore c e Ev s b e f has O ne P BI f Do the P of a n o en sists expected of team eD e itio twe fin d be d con ints ee Th n agr am, to 10 an po e be the of te up and cklist cheagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • +15 Team Preparing a Backlog Sprint Behaviors Delivering a Shippable Product The development team has 7±2 The team takes from the top of There is a sprint burndown people and is cross-functional, the backlog at least 6-10 PBIs that uses estimation points and with all the skills necessary to of about the same size into is updated daily. Points only deliver a PBI inside a sprint every 1-2 week sprint burn down when PBIs are done There is a product vision, During the sprint, the team The team is continuously expressed as an elevator pitch, works on at most 2-3 PBIs at improving quality and the and a list of requirements any one time until the PBI is process with the Active Learning prioritized by business value done Cycle during the retrospective There is a product backlog PBIs are broken down into The team delivers on its with enough PBIs to fill 1-2 tasks that are small enough to commitment with at least 90% sprints, that all meet the be completed in 1-2 days, predictability (ratio of accepted Definition of Ready tracked on the teams taskboard to committed estimation points) The team and PO meet The team meets every day At the end of every sprint the regularly to groom PBIs. around the task board, for a team delivers a potentially Everyone in the team estimates short (max 15 min) standup to shippable product, that can be PBIs before committing to them plan the days activities released or used internally The Definition of Done has There is an impediment Shared code ownership is been agreed between the PO backlog owned by the SM. actively pursued by the team, and the team, and consists of a Impediments are quickly for example, by pairing or checklist of up to 10 points resolved by the team or the SM trending the bug count to zeroagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • software deliverydoesn’t have to be along, uphill climb withno end in sight...recognize new paradigm ofsoftware deliveryagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • delivering working software can be empirically tested every few steps delaying verification against planned progress is no longer acceptableagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • focus on outcomesover outputspoint teams at small changes tothe whole, not steps in the processsuccess is defined by outcomes,not the amount of work doneagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • agile methods forsmall teamslittle divergence from commonapproachshared artifacts emerge naturallyagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Focus on outcomes not process Address technical debt in the sprint Capture the right artifacts Institutionalize knowledge sharingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Focus on outcomes not process Address technical debt in the sprint Capture the right artifacts Institutionalize knowledge sharingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Focus on outcomes not process Address technical debt in the sprint Capture the right artifacts Institutionalize knowledge sharingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Focus on outcomes not process Address technical debt in the sprint Capture the right artifacts Institutionalize knowledge sharingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • agile methods atscale• teams diverge from common approach• artifacts harder to shareagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • •teams adapt to •development need •experience curve•each team adapts in a different way•legislating an approach cripples value delivery•define working practices over theoretical approachesagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Focus on framework and boundary objects Guide self-awareness not maintain status quo Share success not best practicesagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • Growing Agile Teams team name: Specialist knowledge shared Acceptance test-driven dev Limited manual testing STEP 4. Scale Automated testing of NFRs grow knowledge, share learning, Communities of Practice Focus on framework expand capabilities Shared Definition of Done Stable and verifiable builds Cross-cutting concerns Entire team works on release and boundary objects Everyone experiences SM Team owns environment Velocity guides release Business value drives work Visible measure of value Swarms on committed PBIs Owns external dependencies STEP 3. Maximize Value organize to deliver maximum value Reduces technical debt Grow engineering practices Automated PBI testing Team takes 6-10 PBIs Guide self-awareness Predictability over 90% Business value understood PBIs done in priority order not maintainteams first focus quo status on PBIs reviewed as done STEP 2. Gain Experience Shared code ownership people, process and work all settling in, focus on learning Technical debt identified Bugs actively fixed agile 1-3 improvement actions Release Definition of Done smoothing flow and enhancing quality, leading to Cross-functional Teams Working Agreement maximizing of value delivery Share success not best Regular backlog PBIs for 1-2 sprints grooming Impediment backlog STEP 1. Organize PBIs broken into tasks Active Learning Cycle maximizing value preparing the structures, work and Transparent team Definition of Done practices people capacity Definition of Ready enhancing quality Daily stand-ups Potentially shippable Sprint burndown Vision and requirements smoothing flow Focus on 2-3 PBIs more each stage acts as a scaffold, offering guidance and more directive support, for different phases of a team’s agile journey guidingcopyright 2011We advise, trainltd agile42 | agile42 consulting and coach companies building software the accompanying Growing Agile Teams worksheets provide more details behind the checklist 2007 - 2009. www.agile42.com | All rights reserved. Copyright © for each step
    • Auditing agile methods at scale Share success not best practicesagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
    • thank you dave.sharrock@agile42.com skype: dave.sharrock follow us on: @agile42 follow me on: @davesharrockagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.