• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile practices from a standing start
 

Agile practices from a standing start

on

  • 931 views

We all know the engineering practices we should be using, and many teams I meet say that they have plans to start unit testing or test automation, ‘in the next 6 months’. But for a variety of ...

We all know the engineering practices we should be using, and many teams I meet say that they have plans to start unit testing or test automation, ‘in the next 6 months’. But for a variety of reasons familiar to all of us, like time pressure and ever increasing demands from the customer, these worthy plans rarely come to pass. Using experiences from starting agile teams, I’ll throw out some proven strategies for getting a toe hold in adopting great agile practices, as well as looking at real examples from the audience and how we might accelerate the adoption of good practices.

Statistics

Views

Total Views
931
Views on SlideShare
928
Embed Views
3

Actions

Likes
2
Downloads
29
Comments
0

2 Embeds 3

http://www.linkedin.com 2
https://www.linkedin.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

    Agile practices from a standing start Agile practices from a standing start Presentation Transcript

    • Agile practices from astanding startHow do we get agile engineeringpractices into a team?
    • what do you look for in a team forming agile teams as a manager, as an agile team member and as a customeragile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • forming agile team has different, often conflicting objectives, depending on your point of viewagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • “A team effort is a lot of people doing what I say.”Michael WinnerBritish Writer and Film Directoragile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • "What we need to do islearn to work in thesystem, by which I meanthat everybody is therenot for individualcompetitive profit orrecognition, but forcontribution to thesystem as a whole on awin-win basis."W. Edward Demingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • characteristics of anagile team• cross-functional• 7±2 people• co-locatedagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • how many agile teams meet the poll scrum characteristics?agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • the team includes all the skills cross-functional teams necessary to deliver the end product (from concept to cash)agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • every team will have its specialists working together to deliver an end productagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • sometimes you can’t because of:scaling - too many peopleor too big a product Scrum of Tea Tea Tea Scrum of Scrum of Tea Tea Tea Tea Tea Tea Scrum of Scrum of Tea Tea Tea Tea Tea Tea Scrum of Scrum of Scrum of Scrum of Tea Tea Tea Tea Tea Tea Tea Tea Tea Tea Tea Teaagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • sometimes you can’t because of:scaling - too many peopleor too big a productdifferent technologies,products, backlogs agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • sometimes you can’t because of:scaling - too many peopleor too big a productdifferent technologies,products, backlogslimited availability ofspecialists, e.g. architect agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • sometimes you can’t because of:scaling - too many peopleor too big a productdifferent technologies,products, backlogs then you need to 1. managelimited availability of dependenciesspecialists, e.g. architect 2. create knowledge agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • specialists exist on the team, but every team member pitches in to help when necessaryagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • a result of self-organization, not cross-functionalityagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • The Ringelmann effect refers to optimum (agile) team a combination of social loafing size is 7±2 people and coordination lossesagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • the RingelmanneffectThe more people Ringelmannadded to a group, the greater thedecline in personal effort.Three people pulled at only 2.5xthe average individual effort, andeight people pulled at a forceequal to the combined individualeffort of only four people.agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • social loafing (and coordination losses) increase with team sizeagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • the perfect size is...agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • many aspects of distributed co-located vs. virtual teams are still unclearagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • global market in labour means distributed or virtual teams are here to stay in many businesses todayagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • many agile practices work just great with distributed teamsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • agile practicessupport distributedteams“Teams in which leadersperiodically gathered informationabout others and revealedinformation about themselvesperformed better than teams inwhich members did not do this.” Suzanne Weisband Associate Professoragile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • significant risk factors for virtual teams • Insufficient knowledge transfer • Lack of project team cohesion • Cultural or language differences • Inadequate technical resources, i.e. hardware, processing availability • Resource inexperience with company and its processes • Loss of key resource(s) that impact the project • Hidden agendas impact the projectProject Risk Differences BetweenVirtual and Co-Located Teams, Reed & Night agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • emerging agilepractices from astanding startagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the teamagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the team done means coded and testedagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the team done means coded and tested limit WIP (the number of open stories)agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the team done means coded and tested limit WIP (the number of open stories) build habit of predictable deliveryagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the teamcapture learnings indefinition of doneagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the team always keep a future-capture learnings in state DoD on the tabledefinition of doneagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the team always keep a future-capture learnings in state DoD on the tabledefinition of done use retrospective to tighten DoD oftenagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the team always keep a future-capture learnings in state DoD on the tabledefinition of done use retrospective to tighten DoD often automate compliance with DoD if possibleagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the teamcapture learnings indefinition of donesearch out championsand enthusiastsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the team challenge and remindcapture learnings in team of desired statedefinition of donesearch out championsand enthusiastsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the team challenge and remindcapture learnings in team of desired statedefinition of done watch for signs of interest across teamsearch out championsand enthusiastsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the team challenge and remindcapture learnings in team of desired statedefinition of done watch for signs of interest across teamsearch out champions give credit for success,and enthusiasts accept blame for failureagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • drive collaborationacross the teamcapture learnings indefinition of donesearch out championsand enthusiastscreate pilots owned bythe teamagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • automate user interface quick to set up, brutal to maintain but plants the seeds of testing through macros benefit very fastagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • support manual testers once developers are dragged into manual testing, test with automation automation appears quicklyagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • implementation of CI get basic CI in place immediately an automated test and static code analysis is readyagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • automate acceptance help developers own step definitions so that testers can tests for BDD provide tests prior to codingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • refactoring legacy code add to definition of done and give plenty of visibility to any touched by new stories and all examples, however smallagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.
    • “Coming together is a beginning. Keeping together is progress. Working together is success.” Henry Ford 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 - 2011.
    • Dave Sharrock enterprise transitions international B2B matchmaking MBA agile executive leadership husband start-ups part-time Canadian father seismology scrum Englishemail: dave.sharrock@agile42.comtwitter: @davesharrockskype: dave.sharrockagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2011.