Managing agile teams
•Download as PPTX, PDF•
2 likes•753 views
Advanced course discussing the stages of Agile teams and the various expectations & management tactics during each stage.
Report
Share
Managing agile teams
- 1. Managing Agile Teams – 300 seriesBrian Blanchard – Chief Architect/CIO, HyperVize
- 2. AgendaAgile BasicsThe Agile Management ConflictWhat do Agile Teams need?How do we manage self organizing teams?Tools that can make our jobs easier
- 3. Which is worse?Herding Cats is hard work!Herding pigs is deadly!We give them Sharp tusks!And encourage them to charge us
- 4. Are we insane or sadistic?!!Why would we do this?!!No, We’re just dedicated to building teamsWe remove management overhead & interferenceWe capitalize current strengthsWe grow individuals strengthsThe team grows and increases in value
- 6. Define the Agile Management Conflict
- 7. What’s a self organized teamTeam of 6 – 8 individualsAmongst them are all the skills needed for a project: Arch, Coding, DB, Design, QA, etc…Everyone is accountable regardless of skillsetNotice there is no leader
- 8. Properties of traditional managementEveryone has a place – Get there now!Managers job:Check for completion Check for completion Check for completion Yell at people for not being done
- 9. The Agile Management ConflictOld WayWe’re accountableWe manageWe work togetherWe solve problemsWe police ourselvesAgile WayYou do A jobI manageI tell you when to work togetherI solve problemsI police you
- 10. Mitigating the management conflictMitigate by changing priorities, approaches, & tactics.Develop healthy team membersThen, meet the needs of the teamNext, meet the needs of manager(s)Finally, meet the needs of customer* (*Internal or External customers)
- 11. Why isn’t the customer first?Customers are happy when desired features are delivered in a timely manor.This can only happen if the manager is leading the team correctly.The manager can’t lead an unhealthy team effectively.You can’t have a healthy team without healthy people working in a healthy environment.This all starts with motivation and basic needs / skills.
- 12. Develop Healthy Team Members
- 13. Maslow’s hierarchy of needs
- 14. Needs of a self-organized team memberPhysiological: Caffeine, food, reasonable hoursSafety: Sufficient resources (PC, Apps, Desk, etc…), Corporate StabilityBelonging: Heard, Accepted by the groupEsteem: Respected, Challenged, Trusted
- 15. Needs of a developerSelf-actualization: The Ultimate GoalTeam members are free to create, solve problems, and accept consequencesWhen these needs are met, people can becomemotivated
- 16. Meet the needs of the team
- 17. Bruce Tuckman – 1965 Doing principalsPerformingNormingFormingStorming
- 18. What do Agile Teams need?Understand the objective & drivers to understand the needs. Agile Manifesto paraphrasedShip good codeMaintain transparency to customersRespond to change rapidlyValue individuals & interactionsPerformingNormingFormingStorming
- 19. Forming the team – Value Individuals & InteractionsClear a path – Remove barriers to successIdentify skills, weaknesses, growth objectives of individualsCompile teams with all needed skillsPreserve individuality Equalize Super Stars & get everyone talkingEncourage interactions as a teamRespect us as a team of individualsHold us accountable to commitments to each other
- 20. Storming – Respond to changeLead the way Set basic rulesPoint us in the right directionHelp us discover new problemsTeach us to discover them ourselvesProtect our voice as a team and individuals Let us solve all of the problemsEncourage interactions within the companyRespect our role in the project & the companyHold us accountable to commitments to each sprint
- 21. Norming – Maintain transparency to customersKeep us focusedGuard the team – Help us stay on courseHelp us focus on the goals and problemsLet us see the fruits of our laborRespect our relationship/duty to the customerEncourage interactions with the customerHold us accountable to customer commitments
- 22. Performing – Ship Good CodeStay out of the wayDon’t hold us backCoach us – Don’t tell usProvide training & growth opportunitiesCreate new opportunities to interactRequire retrospectivesRespect our ability to think, reason, & createEncourage us to grow our skills & talentsHold us accountable to commitments
- 23. The two faces of managementPublic facing activitiesMeet the teams needsCelebrate successesAddress team failuresPoint out areas to growTalk openly & with purposePrivate facing (1-on-1) activities Maintain the environmentManage failuresPractice subtle control & influence techniquesComplete them quietly & move on
- 24. Meet the needs of the manager(s)
- 25. The team has what they need,What about me?We have bosses & clients too.Our bosses want results not good feeling methodologiesAs managers we are accountable for:Keeping productivity highMeeting deadlinesKeeping costs lowEnsuring the product meets satisfaction levels
- 26. Keep Productivity High Are you producing motion or motivation?Desirecreates motivationFear & rewards creates motion
- 27. What do developers desire?The same things as everyone elseA safe environmentShow stability by enforcing normal schedulesRespectLet everyone have time to talkTo be heard & recognizedStop digs, insults, & rumors quicklyTo know they made a differenceMake sure the team sees the results – Good or BadTo know they are valued Demonstrate & encourage honest feedback in each sprint wrap upCreate team awards for each sprint, let the team do so
- 28. Geeks like geeky thingsLearning, gadgets, & toys are the greatest desire of most developersBe creative and fun with motivationWii is the best investment for any IT teamNerf gun fights are ok – sometimes mandatoryR&D is a special treat – use it to motivateIf you want a fun, open team you should have a fun, open office
- 29. Why all of the fun?Fun creates interaction & unites teamsStress & fear create riftsCoding is stressfulPeople fear failurePeople who are stressed and afraid underperformStress & fear should be managed & controlledGet to know you team so you can know when to reduce unhealthy stress & fear
- 30. Keep Productivity HighAccountability & Deadlines create more than enough natural, healthy fear based motivationLet the team participate in setting deadlinesStart every meeting with a quick review of the deadline & objectiveStart every team with a sense of accountabilityIf you live accountability & deadlines productivity will improve as will deadlines
- 31. WARNING!!!!!Meeting deadlinesYou will failYour team will failIt takes time 2 – 8 sprints to determine a teams ability to produce.Get corporate buy in when startingStart with small measurable “sub-projects”Learn the teams groove
- 32. Keep Costs LowCost in a healthy self organizing team is simpleIn a crucible everyone wants more money in exchange for their painWhen employees are happy, challenged, & growing reasonable pay adjustments are acceptableWatch spending on games, interactions, & learning
- 33. Product QualityQuality & customer satisfaction begin on day 1Make sure Architecture, QA, Design, & Product management are represented in your initial teamHold developers accountable for the quality of code.Peer reviews, refactoring, community ownership
- 34. Tools to make it easier
- 35. Manual ToolsDaily Stand up Sprint meetingsTime boxing clockBS flagsScrum WallStories/tasks in sprintBurn down rateArchitecture / Storyboard wallOften a whiteboard for developing stories or parts of product architecture
- 36. Manual ToolsSprint & Project retrospectivesReview success, failureAwards for the sprintExamples:High on hog – Stuffed pig for someone who hogs up timeSuperhero – Action figure for best ideaSuper-villain – Evil action figure for the biggest mistakeBar of soap – Dirtiest code reviewBe creative – Let the team decide what to awardThese will be displayed proudly on peoples’ desks
- 37. Pigs can stink - Scrum Smells Detection ListLoss of RhythmTalking Chickens Missing PigsPersistent Signatures ScrumMaster Assigns Work The Daily Scrum is For the ScrumMasterSpecialized Job Roles Testers will not integrate with TeamReluctance to estimate Backlog ItemsIs It Really DoneNothing Ever Changes Around HereNo One Wants to Attend Retrospectives Executive Pressure Missing Sprint CommitmentTechnical DebtNot Acting Like a Team No Engineering PracticesLack of progressBacklog failFeature definition failEnforcement fail
- 38. TFS 2010Integrated support for Scrum methodologyIntegrated reportsVisibility for team, customers, & your boss(es)Central repository for stories, tasks, & impediments
- 40. Test Dashboard
- 41. Bug Dashboard
- 43. Build Dashboard
Editor's Notes
- Leading a development team has often be called hearding catsIn Agile, you heard pigs or self organizing teams We let place them in small tightly night teams of 6 - 8– “kind of like a gang” We make them accountable – “now they’re united against us” We preserve their voice in the org – “we give them tusks” Herding pigs is deadly – back out now!!!!
- Before we go any further explain what a pig is
- Leader jobs at each stage: 1- Get them talking, interacting, & building – Form a team of peers 2- Get them working together – Help everyone have a voice 3- Team interacts & communicates – Stars start to deminish Team understands risks & commitments 4- Team becomes self functioning & efficient
- You can use this dashboard to answer the following questions: Is the team likely to finish the iteration on time? Will the team complete the planned work based on the current burndown? How much progress has the team made on implementing user stories in the past four weeks? How quickly is the team identifying and closing Issues? What were the most recent check-ins?
- You can use the User Story Test Status report to determine whether tests are covering all the code and to answer the following questions:Which User Stories have a low overall count of Test Cases?Which User Stories have a high overall count of Test Cases that are blocked or have never been run?Does the Test Case coverage for each User Story meet expectations?Which User Stories have a high rate of test failures? What is the average number of Test Cases that are defined for each User Story?
- By using the Bugs dashboard, the team can answer the following questions:Is the number of active Bugs acceptable based on team goals? Is the team postponing too many Bugs?Is the team finding, fixing, and closing Bugs quickly enough to meet expectations and at a rate that matches previous development cycles? Is the team addressing high priority bugs before lower priority bugs?Does any team member need help in resolving bugs?
- For the Build Status, Code Coverage, and Code Churn reports to be useful and accurate, team members must perform the following activities: Configure a build system. To use Team Foundation Build, you must set up a build system. For more information, see Configure Your Build System.Create build definitions. You can create several build definitions and then run each of them to produce code for a different platform. Also, you can run each build for a different configuration.For more information, see Creating and Working with Build Definitions.Define tests to run automatically as part of the build. As part of the build definition, you can define tests to run as part of the build or to fail if the tests fail.For more information, see Define a Build Using the Default Template.Configure tests to gather code coverage data. For code coverage data to appear in the report, team members must instrument tests to gather that data.For more information, see How to: Configure Code Coverage Using Test Settings for Automated Tests and How to: Gather Code-Coverage Data with Generic Tests.Run builds regularly. You can run builds at regular intervals or after every check-in. You can create regular builds when you use the schedule trigger.For more information, see Create a Basic Build Definition and Running and Monitoring Builds.
- You can use the Code Coverage and Code Churn reports to answer the questions that are listed in the following table. Which builds succeeded? Which builds have a significant number of changes to the code? How often are builds succeeding?How volatile is the code base?How much of the code is the team testing?How high is the quality of the builds? Is the quality increasing, decreasing, or staying constant?