Managing agile teams
Upcoming SlideShare
Loading in...5
×
 

Managing agile teams

on

  • 1,637 views

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

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

Statistics

Views

Total Views
1,637
Views on SlideShare
1,637
Embed Views
0

Actions

Likes
1
Downloads
32
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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
  • 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 Managing agile teams Presentation Transcript

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