Managing agile teams


Published on

Advanced course discussing the stages of Agile teams and the various expectations & management tactics during each stage.

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide
  • 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?
  • Managing agile teams

    1. 1. Managing Agile Teams – 300 series<br />Brian Blanchard – Chief Architect/CIO, HyperVize<br />
    2. 2. Agenda<br />Agile Basics<br />The Agile Management Conflict<br />What do Agile Teams need?<br />How do we manage self organizing teams?<br />Tools that can make our jobs easier<br />
    3. 3. Which is worse?<br />Herding Cats is hard work!<br />Herding pigs is deadly!<br />We <br />give them <br />Sharp tusks!<br />And encourage <br />them to <br />charge us<br />
    4. 4. Are we insane or sadistic?!!Why would we do this?!!<br />No, We’re just dedicated to building teams<br />We remove management overhead & interference<br />We capitalize current strengths<br />We grow individuals strengths<br />The team grows and increases in value<br />
    5. 5. What’s a pig?<br />
    6. 6. Define the Agile Management Conflict<br />
    7. 7. What’s a self organized team<br />Team of 6 – 8 individuals<br />Amongst them are all the skills needed for a project: Arch, Coding, DB, Design, QA, etc…<br />Everyone is accountable regardless of skillset<br />Notice there is no leader<br />
    8. 8. Properties of traditional management<br />Everyone has a place – Get there now!<br />Managers job:<br />Check for completion <br />Check for completion <br />Check for completion <br />Yell at people for not being done<br />
    9. 9. The Agile Management Conflict<br />Old Way<br />We’re accountable<br />We manage<br />We work together<br />We solve problems<br />We police ourselves<br />Agile Way<br />You do A job<br />I manage<br />I tell you when to work together<br />I solve problems<br />I police you<br />
    10. 10. Mitigating the management conflict<br />Mitigate by changing priorities, approaches, & tactics.<br />Develop healthy team members<br />Then, meet the needs of the team<br />Next, meet the needs of manager(s)<br />Finally, meet the needs of customer* <br /> (*Internal or External customers)<br />
    11. 11. Why isn’t the customer first?<br />Customers are happy when desired features are delivered in a timely manor.<br />This can only happen if the manager is leading the team correctly.<br />The manager can’t lead an unhealthy team effectively.<br />You can’t have a healthy team without healthy people working in a healthy environment.<br />This all starts with motivation and basic needs / skills.<br />
    12. 12. Develop Healthy Team Members<br />
    13. 13. Maslow’s hierarchy of needs <br />
    14. 14. Needs of a self-organized team member<br />Physiological: <br />Caffeine, food, reasonable hours<br />Safety: <br />Sufficient resources (PC, Apps, Desk, etc…), Corporate Stability<br />Belonging: <br />Heard, Accepted by the group<br />Esteem: <br />Respected, Challenged, Trusted<br />
    15. 15. Needs of a developer<br />Self-actualization: The Ultimate Goal<br />Team members are free to create, solve problems, and accept <br />consequences<br />When these needs are <br />met, people can become<br />motivated<br />
    16. 16. Meet the needs of the team<br />
    17. 17. Bruce Tuckman – 1965 Doing principals<br />Performing<br />Norming<br />Forming<br />Storming<br />
    18. 18. What do Agile Teams need?<br />Understand the objective & drivers to understand the needs. <br />Agile Manifesto paraphrased<br />Ship good code<br />Maintain transparency to customers<br />Respond to change rapidly<br />Value individuals & interactions<br />Performing<br />Norming<br />Forming<br />Storming<br />
    19. 19. Forming the team – Value Individuals & Interactions<br />Clear a path – Remove barriers to success<br />Identify skills, weaknesses, growth objectives of individuals<br />Compile teams with all needed skills<br />Preserve individuality <br />Equalize Super Stars & get everyone talking<br />Encourage interactions as a team<br />Respect us as a team of individuals<br />Hold us accountable to commitments to each other<br />
    20. 20. Storming – Respond to change<br />Lead the way <br />Set basic rules<br />Point us in the right direction<br />Help us discover new problems<br />Teach us to discover them ourselves<br />Protect our voice as a team and individuals <br />Let us solve all of the problems<br />Encourage interactions within the company<br />Respect our role in the project & the company<br />Hold us accountable to commitments to each sprint<br />
    21. 21. Norming – Maintain transparency to customers<br />Keep us focused<br />Guard the team – Help us stay on course<br />Help us focus on the goals and problems<br />Let us see the fruits of our labor<br />Respect our relationship/duty to the customer<br />Encourage interactions with the customer<br />Hold us accountable to customer commitments<br />
    22. 22. Performing – Ship Good Code<br />Stay out of the way<br />Don’t hold us back<br />Coach us – Don’t tell us<br />Provide training & growth opportunities<br />Create new opportunities to interact<br />Require retrospectives<br />Respect our ability to think, reason, & create<br />Encourage us to grow our skills & talents<br />Hold us accountable to commitments<br />
    23. 23. The two faces of management<br />Public facing activities<br />Meet the teams needs<br />Celebrate successes<br />Address team failures<br />Point out areas to grow<br />Talk openly & with purpose<br />Private facing (1-on-1) activities <br />Maintain the environment<br />Manage failures<br />Practice subtle control & influence techniques<br />Complete them quietly & move on<br />
    24. 24. Meet the needs of the manager(s)<br />
    25. 25. The team has what they need,What about me?<br />We have bosses & clients too.<br />Our bosses want results not good feeling methodologies<br />As managers we are accountable for:<br />Keeping productivity high<br />Meeting deadlines<br />Keeping costs low<br />Ensuring the product meets satisfaction levels<br />
    26. 26. Keep Productivity High <br />Are you producing motion or motivation?<br />Desire<br />creates motivation<br />Fear & rewards <br />creates motion<br />
    27. 27. What do developers desire?<br />The same things as everyone else<br />A safe environment<br />Show stability by enforcing normal schedules<br />Respect<br />Let everyone have time to talk<br />To be heard & recognized<br />Stop digs, insults, & rumors quickly<br />To know they made a difference<br />Make sure the team sees the results – Good or Bad<br />To know they are valued <br />Demonstrate & encourage honest feedback in each sprint wrap up<br />Create team awards for each sprint, let the team do so<br />
    28. 28. Geeks like geeky things<br />Learning, gadgets, & toys are the greatest desire of most developers<br />Be creative and fun with motivation<br />Wii is the best investment for any IT team<br />Nerf gun fights are ok – sometimes mandatory<br />R&D is a special treat – use it to motivate<br />If you want a fun, open team you should have a fun, open office<br />
    29. 29. Why all of the fun?<br />Fun creates interaction & unites teams<br />Stress & fear create rifts<br />Coding is stressful<br />People fear failure<br />People who are stressed and afraid underperform<br />Stress & fear should be managed & controlled<br />Get to know you team so you can know when to reduce unhealthy stress & fear<br />
    30. 30. Keep Productivity High<br />Accountability & Deadlines create more than enough natural, healthy fear based motivation<br />Let the team participate in setting deadlines<br />Start every meeting with a quick review of the deadline & objective<br />Start every team with a sense of accountability<br />If you live accountability & deadlines productivity will improve as will deadlines<br />
    31. 31. WARNING!!!!!Meeting deadlines<br />You will fail<br />Your team will fail<br />It takes time 2 – 8 sprints to determine a teams ability to produce.<br />Get corporate buy in when starting<br />Start with small measurable “sub-projects”<br />Learn the teams groove<br />
    32. 32. Keep Costs Low<br />Cost in a healthy self organizing team is simple<br />In a crucible everyone wants more money in exchange for their pain<br />When employees are happy, challenged, & growing reasonable pay adjustments are acceptable<br />Watch spending on games, interactions, & learning<br />
    33. 33. Product Quality<br />Quality & customer satisfaction begin on day 1<br />Make sure Architecture, QA, Design, & Product management are represented in your initial team<br />Hold developers accountable for the quality of code.<br />Peer reviews, refactoring, community ownership<br />
    34. 34. Tools to make it easier<br />
    35. 35. Manual Tools<br />Daily Stand up Sprint meetings<br />Time boxing clock<br />BS flags<br />Scrum Wall<br />Stories/tasks in sprint<br />Burn down rate<br />Architecture / Storyboard wall<br />Often a whiteboard for developing stories or parts of product architecture<br />
    36. 36. Manual Tools<br />Sprint & Project retrospectives<br />Review success, failure<br />Awards for the sprint<br />Examples:<br />High on hog – Stuffed pig for someone who hogs up time<br />Superhero – Action figure for best idea<br />Super-villain – Evil action figure for the biggest mistake<br />Bar of soap – Dirtiest code review<br />Be creative – Let the team decide what to award<br />These will be displayed proudly on peoples’ desks<br />
    37. 37. Pigs can stink - Scrum Smells Detection List<br />Loss of Rhythm<br />Talking Chickens <br />Missing Pigs<br />Persistent Signatures <br />ScrumMaster Assigns Work <br />The Daily Scrum is For the ScrumMaster<br />Specialized Job Roles <br />Testers will not integrate with Team<br />Reluctance to estimate Backlog Items<br />Is It Really Done<br />Nothing Ever Changes Around Here<br />No One Wants to Attend Retrospectives <br />Executive Pressure <br />Missing Sprint Commitment<br />Technical Debt<br />Not Acting Like a Team <br />No Engineering Practices<br />Lack of progress<br />Backlog fail<br />Feature definition fail<br />Enforcement fail<br />
    38. 38. TFS 2010<br />Integrated support for Scrum methodology<br />Integrated reports<br />Visibility for team, customers, & your boss(es)<br />Central repository for stories, tasks, & impediments<br />
    39. 39. Progress Dashboard<br />
    40. 40. Test Dashboard<br />
    41. 41. Bug Dashboard<br />
    42. 42. Quality Dashboard<br />
    43. 43. Build Dashboard<br />