Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Challenging your comfort zoneAgileSparksW W W . A G I L E S P A R K S . C O Minfo@agilesparks.com
  2. 2. We are very happy to have you with us at AgileIsrael2013, our sixth Agile conference. AgileIsrael is themajor Agile event of the year in Israel, and we arehappy to host it.This year we are focusing on "hands-on”, whichmeans that every session is practical and immediatelyusable after the conference.We filled the conference with many interestingsessions and case studies, and have brought 5international speakers to give you a uniqueexperience.In the spirit of hands-on, some of our speakers havejoined us in producing this booklet which includeshandouts containing tips on various topics of Agilefrom meeting facilitation to discovering pains.We hope this booklet is useful to you and helps youleverage the ideas you got today in the near future.Please feel free to share it with your fellow workers.We will be happy to hear your feedback and assistyour Agile journey, please write us at:info@agilesparks.com.Thank you for being part of this conference and seeyou all at AgileIsrael2014!Inbar Oren, conference ChairAgileSparks
  3. 3. Feature Teams – 10 guidelines and tips to make it happen rightFor those who have already been convinced about the need for their organization to migrate tofeature teams. Here are some practical considerations and tips to help make the transitioneffective and successful.1. Define the domain – Define the orientation of the team: specific line of business, specificproduct, specific strategic goals to achieve, or a squad team that can achieve anything.2. Maximize autonomy - Align the team structure, processes, tools and environments withthe teams’ goals so as to enable them achieve maximum results autonomously.3. With empowerment comes ownership – Team should be responsible for end to endsuccess or failure and have continuous improvement cycles to make the team performbetter.4. Invest in the technical landscape – Assign tech owners to each component, subsystemor knowledge domain. 5%-20% of their time will be allocated to the well being of thecomponent (scale, stability, architecture, coding standards etc), enabling efficient andscalable development (test and deployment automation, etc) and knowledge transfer.5. Remember the matrix – Although we push for autonomy of the team, we need a matrix ofcollaboration that crosses teams’ boundaries: PMs, Team leaders, Experts, QA etc.Establish forums and platforms for knowledge sharing AND relevant decision making.6. Think architecture – Architects should be involved in major development efforts. Makesure they have free communication channels to PMs. Architects should enable, educate,review and promote system well being.7. Delivery automation included – Each team needs to deliver. Delivery automationshould be part of the team skills, supported if needed by external specific team (e.g. QAautomation, deployment automation)8. System support and stability - Based on the system maturity and size choose one of thetwo models for handling system support cases: All support cases to be handled in onespecific team, or through rotation between teams. The more mature and larger the system– rotate it.9. Dev-Ops collaboration culture – Feature teams boost the power of each team to makedecisions. These might affect system stability. Be aware of this. Establish opencommunication and improvements cycles between dev and ops. Educate for collaboration.10. Transition to feature teams - Execute as a step function. Make all the right preparations,execute, and be prepared for a few months stabilization period with lower efficiency.Mind: Treat transitioning to feature teams on one hand with great determination but keepreflecting and adapting to your own needs.
  4. 4. Planningmeeting-9stepsforhavinganefficientplanningmeeting1.Capacity(1minute)-Settingthetime(Days/hours)foreachteammember.Eachteammemberprojectstheamountoftimes/heisgoingtoinvestinthesprint.Itisimportantthattheteammemberwillgivethecapacity.Fromthe100%capacitytheteammembershouldomitpersonaltime(e.g.vacation,courses,takingpartinanotherteam),company’stime(e.g.Allhandsmeetings,funday)andScrumtime(e.g.endofsprintsmeetings).2.Releasevision(5minutes)-Theproductownerbrieflydescribestotheteamwhatishappeningwiththerelease,newtrends,newcontentandwhatisthefocusoftherelease.3.Sprintvision(5minutes)-TheProductownerbrieflydescribestotheteamwhatisthevisionofthesprint,e.g.whatisthe“story”ofthesprint.4.Softestimation(5minutes)-Basedontheaboveandthe"sniffingera",theteamwiththeproductowner,briefly,discusswhatuserstoriesseemreasonablefortheteamtodowithintheupcomingsprint.5.TeamEstimationgame(60minutes)-Theteamstartsto“digest”eachandeveryuserstoryaccordingtotheirpriorityandsetanestimateforit.Theestimationisbeingdonefortheentireuserstory.Theteamalsodecideswhowilldowhat.Theentireteamparticipateswitheachestimation.Yes,EVERYBODY!Itendswhenthecapacityisexhaustedasfarastheabilitytofinishawholeuserstory(acommonmistakeistostartauserstoryonlybecauseyouhaveacodingcapacitywithnoQAcapacity.Thiswillleadtoinventorywaste)6.HardEstimation(10minutes)-TheteamcommunicatestotheproductownerwhataretheuserstoriesthattheteamcancommitfortheincomingsprintandwhataretheuserstoriesthattheteamMAYdeliverincasethecommitteduserstorieswillbecompletedaheadoftime.Thislistwillbenamed“sprintbacklog”7.Menu(10minutes)-Similartoarestaurantmenu,theteamcreatesamenuofitemsthattheteamisgoingtopresentattheendofthesprint.Asopposedtoatechnicallanguageofauserstory,thismenuinwritteninPOlanguage.Thismenushouldbevisibletoallthroughtheentiresprintandistheagendaforthereviewmeeting.8.Visibility(10minutes)-Createthevisibilitychartforthesprintthatincludesalloftheaboveandwillbeupdatedonlybytheteambutvisibletotheentireworld.Bestpracticeistoplacethevisibilitychartinamajor"highway"ofthecompanyforincreasedvisibility.9.Daily-Settingthetimeandlocationofthedailymeeting(whichisactuallythedailyplanningoftheteam).Itisimportantthattheteamwillsetitandnooneelse(e.g.themanager)Forthosewhowanttoknowwhatarethestepstoa2hoursplanningmeeting,heretheyare.Notethatitwilltakearound5sprintsinordertogetintothistimeframethusitisperfectlynormaltohavea6hoursplanningmeetinginthefirsttime.
  5. 5. tips for ATDD implementation–QA Transition to Agile testingTips for QA team transition to ATDD: Promote the new tester role.o From bug hunter to “Represent the PO within the team”o QA and developers understand Agile approach for testing (whole teamapproach, ATDD, automation pyramid) Train early the entire team (also development) on ATDD and how to write good BDDo Understanding the framework (Text<->code) is a must! It is not so difficult to learn to write code automationo One week Java training is enough to starto But, Automation champion to support the QA team and ensuretest infrastructure is a must !o Need more focus on software engineering and refactoring (for the automationcode)o Ensure Scrum team support  shared ownership concept accepted by the team Read the Cucumber book ! be part of the community !Tips for choosing ATDD tool Expressing expectations in a language and format that allow collaboration among thewhole team (PO/Dev/QA) Required minimum of test code (allow re-use, auto-completion) Test code written in the team “native” language (so developers can also develop andsupport the QA) Play nicely with source control systems and continuous integration Pluggable to support a variety of interfaces (e.g. UI automation) Can become a product spec. (documentation tool) Active communityTips for BDD development process Describe ALL expected business behavior with BDD , decide later what will be tested inwhich level (UI, Manual, AT) Write Acceptance test (feature file) for MMF, Write user stories DoD as scenarios withinthe MMF feature file Ensure BDD is readable, written in business language (not implementation) , as possibleuse tables for the data description Integrate ATDD into the release processo PO writes User Story description in the backlog management tool (it is rare tofind PO that willing to describe it in BDD format )o QA translate it to BDD (after team sniffing, before iteration planning)o PO review the BDD with QA (and if possible with development representativefrom the team)o BDD is a condition for “Ready Story”, might be a step in the release Kanban flow Team commit to the BDD!!! Not to the user story description. When team start working on the story:o Developer and QA review together the BDD and agree: What to test, by whomand how to automate it (unit/acceptance)o Developer develop first the “API contract” (so automation can run and fail),QA develops the automation (code review with developer)
  6. 6. 5 Tips on how to implement electronic projectmanagement toolBegin with physical task board Encourage: team work, commitment and trust through transparency,visualization and activeness Make the board the team’s tool in the daily routine – use it to facilitatediscussions and meetings such as dailies, planning and retrospectivesOnly when the team shows active use….Start using the electronic tool in the team Use big screens for visualizing the task board Facilitate the daily meetings Team member ownership on items on the board – they createupdate theitemsContinue using sticky notes to facilitate discussionsdecision making In order to be fully present in the meeting and focus on having an effectivemeeting input the results of the meeting after the meeting to the tool (notthe manager)Visualize project progress Use Agile reports to visualize project progress, preferably Burn-up chartand cumulative flow diagram Management feels thing are under control and allows the team to work Connects the team to the big picture and creates common language withmanagementVisualize Improvement Choose 2 key KPI’s and use them on the board Fuel motivation by visualizing and acknowledging improvement in theselected KPI’s UpdateChange the KPI’s according to needs periodically
  7. 7. FromPainstoPracticesInstructions:1.Startwithwhyyouwanttochange(i.e.whyareyoupursuingAgile?)2.Identifytop1-2pains.WhichAgileprinciplesworkonimprovingthesepains?3.ForeachoftheAgileprinciplesidentifiedabove,whichAgilebestpracticesfocusontheseprinciples?4.Selectthosepracticesyou’dliketopursue.5.Rinseandrepeat.*ManagethechangeasanAgileproject.**Alwaysrememberwhyyouarepursuingthechanges.
  8. 8. Individuals and Interactions: 10 Lessons from Putting People Before ProcessIn the last 15 years, many Agile teams and organizations have been valuing individuals and interactionsover processes and tools. Here are their top 10 lessons.1. People are not “resources.” Respecting them as individuals opens the door to the amazingpotential of intrinsic motivation, self-organization, collaboration, and positive team synergy.2. Focus keeps you going. By limiting individual multi-tasking and the team’s overall work inprogress, and by having all necessary participants collaborate, teams can finish and deliver workearlier, which motivates and energizes them.3. Nurture the joy of delivering value. Changing one’s role from “building software” to“delighting customers with outstanding value” creates a virtuous cycle of engagement andsuccess.4. Take small, safe, feedback-rich steps. Approaching every activity this way reduces the fearand mental weight of large or unfounded moves, so teams can focus on doing the right thing.5. A standardized environment is for standard people. Proximity among colleagues increasescommunication and collaboration, as well as the sense of belonging and recognition that peoplecrave.6. Collaboration requires a suitable social environment. In collaborative teams, emotionalintelligence and social skills must outweigh technical skill so people want to be members andhave each other’s back.7. High-performance teams need investment. Most teams need support to reach highperformance and stay there: facilitation, leadership, championing, protection, coaching.8. Manage less, lead more when the situation allows self-organization, empowerment(autonomy), and collaboration to flourish.9. Lead collaboratively. Collaboration doesn’t just improve results through reduced mistakes andsimpler solutions. Collaboration mitigates the risk of employing human beings to do work.10. Human conduct trumps “best practices.” Practices must be tailored to context: “Will peopleuse them?” and “Will they do them well?” Let the team choose, to increase buy-in.Visit us at: www.TheHumanSideOfAgile.com and www.3PVantage.com© 2013 Gil Broza Email: gbroza@3PVantage.com
  9. 9. How Technically Agile Is Your Team? (Self-Assessment Tool)
  10. 10. Visit us at: www.TheHumanSideOfAgile.com and www.3PVantage.com© 2013 Gil Broza Email: gbroza@3PVantage.com
  11. 11. W W W . A G I L E S P A R K S . C O Minfo@agilesparks.comThe 10 commandments for the facilitator1. Do you have strong opinions on the meeting subject / agenda / conflict / interest?Maybe you should ask someone else to help you by participating in the meeting torepresenting this opinion so that you can remain neutral…2. Prepare… who is attending? Who really needs to be? Who shouldn’t be?3. Is the team willing to accept a new way of work? Are they prepared to take it from you?Today?4. Are the meeting participants, boundaries, constraints clear? Make sure time limits,space, time-of-day, etc…5. Oh – are all the participants coming? Are they ready? Did they prepare last meetingsaction items?6. Meeting goals and agenda, are theyclear to everybody? Including you?State them to agree and start themeeting. Is anybody taking notes?7. Is there enough time? Do less, butclose issues…8. Is everybody with you during thediscussion? Are you helping peopleunderstand each other? Are all thevoices heard? Is anyone toodominant?9. Accumulate action items. State them clearly when they show up, and make sure theyare visible. Action item – what, who, by when…10.Decisions? Is the team committing, or is just the manager making decisions? Who willreally carry out the action items?For consulting about the transition to efficient meetings, visitwww.agilesparks.com