SlideShare ist ein Scribd-Unternehmen logo
1 von 40
Downloaden Sie, um offline zu lesen
Facilitation Foundations
Improving the Quality of Agile Meetings
V. Lee Henson CST


                                          1
Improving the Quality of Agile Meetings




           Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   2
✤   Founded in 2007 - Salt Lake City, UT

✤   Specialize in Public & Private Certification Workshops
    & Courses

✤   Deep understanding of Agile & Traditional Project
    Management, (PMP), RUP, Lean, Kanban, Scrum, (CST),
    XP, & PMI-ACP

✤   Proven Applied Agile Principles in Software, Hardware,
    Financial, Insurance, Construction, Medical,
    Marketing, Legal, Entertainment, Research, Military,
    Government, Retail, Education, Law Enforcement, and
    many more...



                                                             3
V. Lee Henson CST

✤   Certified Scrum Trainer

✤   Project Management Professional

✤   PMI- Agile Certified Practitioner

✤   Certified Lean Agile Professional

✤   Motivational Speaker & Executive
    Coach

✤   Author of The Definitive Agile
    Checklist

✤   Inventor of Rapid Release Planning

✤   Information Technology / Psychology

                                                               4
Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.
What Are We Trying To Solve?

The 3 most common downfalls
of meetings are:
   The meeting has no purpose
   or planned Agenda
   The incorrect participants are
   invited or not invited
   The meeting goes exactly as
   planned, without positive
   results



                Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   5
The Agile Manifesto
     We are uncovering better ways of developing software
             by doing it and helping others do it.

           Through this work we have come to value:

      Individuals & Interactions over processes & tools

            Working software over comprehensive
                      documentation

      Customer collaboration over contract negotiation

         Responding to change over following a plan

     That is , while there is value in the items on the right,

               we value the items on the left more.

            Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   6
Agile vs. Plan Driven




        Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   7
Scrum vs. Waterfall




        Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   8
The Why Behind the What:

 • Teams struggle when they
     have a Vision with no strategy
     to get there
 •   Meetings can quickly dissolve
     when the right parties are not
     engaged and attend with a
     purpose
 •   Once the vision and strategy
     are clear, the needed
     meetings fall into place


                Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   9
Forming - Storming

                                             • Forming represents
                                               building of the team
                                             • The Forming Stage is
                                               Important as team
                                               members get to know each
                                               other and gel
                                             • Storming occurs when the
                                               team addresses how they
                                               will function both
                                               independently and as a
                                               group
                                             • Storming may be painful,
                                               but is necessary for the
                                               team to be successful

       Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.       10
Norming - Performing
                                          • Norming happens when
                                            teams adjust their
                                            behaviors and begin to
                                            work together as a
                                            cohesive unit
                                          • Motivation increases
                                            across the team as a result
                                            of Norming
                                          • Not all teams reach the
                                            Performing stage
                                          • At this point teams are
                                            able to handle both
                                            conflict and decision
                                            making without direct
                                            supervision


        Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.      11
Get a Tool Kit!




        Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   12
Meeting Rules
                                      • Every Agile meeting should have a
                                        purpose and goal
                                      • Prior to holding a meeting, all key
                                        participants should be invited
                                      • The agenda for the meeting should
                                        be distributed prior to the meeting
                                      • The meeting goal & agenda should
                                        be distributed prior to the meeting
                                      • All resources should be reserved
                                        and prepared for the meeting
                                      • The meeting facilitation toolkit
                                        should be well stocked and ready
                                        to go
                                      • The team should establish and post
                                        effective meeting rules

       Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.    13
Meeting Rules Continued
•   The meeting goal and objective should be presented
•   The time-boxed agenda should be presented
•   The rules should be posted and all should be reminded
    to take heed
•   If at any time a discussion begins that is not part of the
    agenda, the topic should be added to a running list for
    later discussion
•   If the meeting ends and the goal has not been reached,
    arrange for a subsequent meeting at a later time (do not
    go over time in hopes of solving an issue)
•   Once conclusive results have been reached, record all
    risks, assumptions, and action items
•   Insure that all list items have a party responsible to
    address each topic outside of this meeting
•   Post the results in a visible place for all to see




                                Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   14
Fist To Five
                   • Team makes decisions, ScrumMaster only
                     guides the decision process
                   • A ScrumMaster seeks consensus within the
                     team, a quick way to do this Consensus = “I
                     can live with and support that.”
                   • Fist to five:
                   • 5 = wild, unbridled support
                   • 4 = this is a fine idea, wish I’d thought of it
                   • 3 = I can live with and support it
                   • 2 = I have reservations I’d like to think
                     about
                   • 1 = I am very opposed; we shouldn’t move


        Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   15
Fist To Five




        Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   16
What About Business Priority?
                                                       ✤   We all know the business has a
                                                           3 point ranking scale for priority
                                                           of backlog items: High, Really
                                                           High, or Really Really High.

                                                       ✤   The business needs to use tools
                                                           to help them understand that
                                                           not everything can be of the
                                                           highest priority.

                                                       ✤   With the understanding that we
Two websites to assist with priority:                      would not be doing the work if it
       http://dotmocracy.org                               were not important, which items
 http://www.innovationgames.com                            have the greatest urgency? Can
                                                           we arrange them into High,
                                                           Medium, and Low categories?

                    Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.           17
Time vs. Relative Complexity

✤   Let’s paint the room!

✤   How many hours will it take?

✤   Why all of the different answers?

✤   Have any of you painted before?

✤   Compared to something else
    you have painted, would it be
    easier to determine how difficult
    it would be to paint the room?

✤   Is it easier to reach consensus?


                     Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   18
Planning Poker - Does It Work?




       Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   19
Let’s Use a T-Shirt Size...
✤   Smaller Than XS = a Task.

✤   Extra Small = 1

✤   Small = 2

✤   Medium = 3

✤   Large = 5

✤   Extra Large = 8

✤   Larger than XL = an Epic

                  Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   20
Understanding MoSCoW:
                                         ✤   MoSCoW = more than a Russian Capital

                                              ✤   Must Have

                                              ✤   Should Have

                                              ✤   Could Have

                                              ✤   Would Like

                                         ✤   Every iteration should have a mix of
                                             the above types of items.

                                         ✤   Stake holders LOVE the Would Likes.

                                         ✤   The Product Owner drives the product
                                             backlog and creates the rank order
                                             based heavily on the MoSCoW ratings.


      Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.                  21
Create Five Stories
✤   Think about what you have learned about user
    stories Take a few moments to create five Story
    Cards that look like the ones we have created so
    far:

✤   1) Make 5 cards each with a title & description.
    (Bonus points for using roles & personas in the
    description.)

✤   2) Take the 5 cards and give them each a priority.
    (Remember, this is from the business perspective.)

✤   3) Take the 5 cards and give them each a MoSCoW
    rating. (Remember, this is from the customer
    perspective.)

✤   4) Next, take the 5 cards and give them a T-Shirt
    size based on relative complexity & scope.

✤   5) Finally, take the 5 cards and place them in stack
    rank order. Be certain to take all 3 corners into
    consideration when placing them in order.
                           Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   22
The Formula
✤   Here is the formula for correct placement of stack
    rank order of your backlog items. Address risk by
    performing the items with the highest complexity                    Must Have           High Priority
    earlier working towards the lower complexity items
    later in the process:
                                                                        Would Like             H-M-L
✤   1) All Must Have High Priority items should be
    considered first and foremost.                                       Must Have              Medium
                                                                                               Priority
✤   2) Be certain to get at least one Would Like in every
    sprint. Next should be one Would Like High Priority                 Must Have           Low Priority
    item.

✤   3) Next should be the Must Have Mediums and Must
                                                                       Should Have             H-M-L
    Have Lows.
                                                                        Could Have             H-M-L
✤   4) The Should’s go next from High to Low Priority.

✤   5) Finally, place the Could’s from Highest to Lowest             All states are stack ranked from highest
    Priority.                                                        to lowest risk unless the velocity of the
                                                                     Sprint does not afford this as an option.
                                                                           Team velocity always prevails.
✤   Note: Dependencies trump priority & moscow rating.

                            Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.                         23
Rapid Release Planning Checklist

• Product Vision Statement
• Product Roadmap
• Release Themes
• Release Timeline
• Important Dates in Release
• Team Identification
• Prioritized Product or Release Backlog
• Team Velocity (or capacity)
• Technical ‘gotchas’ and dependencies that we
  know already

            Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   24
Release vs. Sprint Planning
                               Release Planning                             Iteration Planning
Attendees                      Team, SMEs and                               Team, SMEs and
                               product owner                                product owner
                               required. Managers/                          required. Managers/
                               customers optional.                          customers optional.

Lowest level of work           User stories                                 Tasks
breakdown

Estimates Provided in          Points, t-shirt sizes, or                    Hours
                               duration (weeks)

Output of meeting              Release plan (= high                         Iteration plan (=
                               level plan for multiple                      detailed plan of tasks
                               iterations)                                  for one iteration)
                    Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.                     25
Rapid Release Planning Instructions:

 1) Print out all of the story cards you hope to be included in the release leaving
 off the product owner t-shirt size. (After all, we would not want to influence the
 team.)

 2) Place all of the cards in a large box, bucket, or basket.

 3) Invite all of the teams participating in the release to be part of the rapid
 release planning session to gather around a large table.

 4) Explain that in a moment you will be dumping out all of the cards. The team
 will have a preset amount of time to find a card they all agree is small in scope.

 5) Once the team has identified a small benchmark item, explain they will have a
 preset amount of time to place all of the remaining cards in columns on the wall
 listed as small, medium, and large relative to the first item and to each other.

 6) If a team member picks up a card they are uncertain about, have them return
 the card to the table for other team members to review.

                     Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   26
Rapid Release Planning Instructions:

 7) If an item is smaller than small, make a column for extra small. If the item is
 larger than large make a column for extra large.

 8) If an item is placed in the wrong column on the wall, feel free to move it. Any
 card can move except for the initial small benchmark item.

 9) For the final few seconds, I command silence and have the team carefully
 study as many items on the wall as they can in an effort to allow for any final
 adjustments to be made.

 10) Once the time expires, I excuse the team for an extended lunch and ask the
 product owners to stick around for a while so we can do a quick comparison.

 11) Any items with no disparity or with only one column of difference in either
 direction between the product owner and the team is a good enough estimate.
 The team will get better at estimating as they go and product owner will have a
 lot fewer items for additional review. The teams estimate in this case is the
 final one.

                    Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   27
Rapid Release Planning Instructions:
 12) If there is more than one degree of separation in the t-shirt size between the
 product owner and the team, this warrants additional discussion regarding that
 item. In most cases this limits the number of items requiring additional
 conversation to a much smaller number.

 13) Outliers are marked with moth the team size and the PO size and placed in a
 separate column for additional discussion.

 14) When the team returns, we talk about the outliers for a time-boxed period of
 five minutes each in an attempt to clarify scope.

 15) The teams estimate stands and we move quickly through the items.

 16) Before we exit the room, the team takes a sheet of round stickies and identifies
 any backlog items in the release that have an internal or external dependency.

 17) Based on the teams projected velocity, the product owner places items into
 future sprints to identify any items that could be considered at risk of not making
 the release.

                    Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.       28
The Sliding Scale
✤   The amount of time allowed for each step in the Rapid
    Release Planning Process varies based on the number of
    items you are trying to plan for, the number of people,               # Of Items          # Of People
    and whether teams are remote or collocated. The scale at
    right should be used as a guide and can be adjusted
    according to what works best for you. Please remember:                 0-99 (5)           1 Team (+0)
✤   1) The times are intentionally FAST! This is to perfect
    reaching a true grit gut decision instead of pondering.            100-199 (10)          2 Teams (+5)
✤   2) Every team member may not get to see every card. This
    is PERFECTLY fine. They need to trust in the ability of the         200-299 (15) 3 Teams (+10)
    team member that did see the card.

✤   3) Movement of cards throughout the exercise is both               300-399 (20) 4 Teams (+15)
    normal and expected.

✤   4) Limit the number of people participating to no more
                                                                       400-499 (25) 5 Teams (+20)
    than 50 People.
                                                                           500 (30)          6 Teams (+25)
✤   5) Video Record your teams executing this and send it
    directly to me or upload via YouTube for a chance to win
    cool prizes!                                                        Times in Parentheses should be added
                                                                        together to calculate the TOTAL team
✤   Note: Remote teams should add 50% to the times listed.                     time needed for the RRP

                              Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.                     29
At The Wall...

        Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   30
Sprint Planning - Six Steps
✤   1) Schedule items into a sprint making certain not to exceed the teams
    projected velocity. (If you did Rapid Release Planning, this step is done)

✤   2) Review Team member capacity to ensure that people will not be over
    allocating themselves.

✤   3) Detail Planning - Breakdown the work into tests and tasks. (No
    estimating or signing up for the work should take place during this step.)

✤   4) Member Planning - Allow team members to sign up for the work they
    choose and give an estimate in hours as to how long each task will take to
    complete.

✤   5) Review open issues and impediments that may put any item in the sprint
    at risk. Replace items as needed with approval from the product owner.

✤   6) COMMIT to the sprint as a team! (Let’s do this!)

                      Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   31
Meeting Timeline Guide:
✤   Scrum Meetings should be
    time-boxed according to the
    number of weeks in the
    sprint.

✤   For example: If you are
    doing two week sprints, the
    sprint planning meeting
    should last no longer than
    two hours. Three weeks =
    three hours. Etc.

✤   The same holds true for end
    of sprint meetings.

                  Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   32
The Daily Standup Rules:
✤   Daily 15 minute or less                            ✤   Do not be late...
    meeting
                                                       ✤   Fines go to a reputable charity
✤   Same time same place
    everyday                                           ✤   Team stands in a circle
✤   No problem solving                                 ✤   Chickens around the outside
✤   * No Electronics of any kind                       ✤   Chickens follow the same rules
✤   No pen and paper to record                         ✤   Stick to the three questions
✤   Team rules posted on the wall                      ✤   Always end on time


                    Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.          33
Hold a Daily Standup
✤   Many teams regard the daily standup as a less than
    desirable meeting. These teams have not fully embraced
    what the standup is intended to do. Today we will hold a
    daily standup:

✤   1) Eight volunteers will participate in this meeting. Imagine
    you are a team member developing an e-commerce
    website.

✤   2) Take a moment to decide what you have been working on
    and how you will answer the following 3 questions:

    ✤   What have you worked on since we last met?

    ✤   What will you be working on until we meet again?

    ✤   Are there any obstacles preventing you from making
        forward progress that you cannot solve yourself?

✤   3) The ScrumMaster will facilitate, not drive the meeting.

✤   4) We will try hard to give a solid report in record time.

✤   5) At the conclusion, we will review and discuss
    improvements.

                                Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   34
Review & Demo

                             • Delivered features
                             • Incomplete features
                             • Verifying ‘Done’ with the customer/
                               product owner
                             • Maintaining trust with customer by not
                               “hiding” undone work
                             • Team and Customer responds to the
                               delivery
                             • The Goal: Collaborative Decision-
                               Making about the emerging product




        Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   35
Retrospectives
• Project retrospectives help teams examine what went
  right and what went wrong on a project
• Retrospectives are designed to:
• Find & fix problems
• Find and Reinforce team strengths
• Address both people & technical issues
• Use tools and practices proven in the real world
• The retrospective is the perfect chance to inspect and
  adapt.
• Teams who perform meaningful retrospectives are
  consistently better at completing work on time and
  under budget
• Ask the 3 questions and record findings




                        Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   36
Sample Retrospective Agenda
✤   What were the major events in our timeline?

✤   What can we observe about the flow of events?

✤   What were the sprint metrics like?

✤   What have we learned about the product as a result of the sprint?

✤   What have we learned about the team as a result of the sprint?

✤   What worked well in our sprint that we would want to do again?

✤   What do we wish we had done differently?

✤   What recommendations are there moving forward with our next sprint?

✤   Inspect the process not the people.

                      Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   37
Innovation Games

                        • These interactive techniques let your customers
                            and prospects help you create the products they
                            want. Understand customer needs, identify
                            product functionality, learn how customers
                            interact with your products, and shape your
                            products’ future
                        • Luke Hohmann has devoted his professional
                            career to creating environments where everyone
                            can work to their fullest creative and intellectual
                            abilities. He is a committed coach, working with
                            every individual and the organization as a whole
                            to achieve greater levels of performance

       Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.         38
✤   You now hold the keys to success!

✤   You have been educated and empowered.

✤   Visit often and drink from the well!




                                http://www.agiledad.com/
                      Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   39
Thank You!
 Lee@AgileDad.Com- Twitter @AgileDad - LinkedIn leehenson@gmail.com


                Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.   40

Weitere ähnliche Inhalte

Was ist angesagt?

Product Development using Agile Teams: What? Why? How?
Product Development using Agile Teams: What? Why? How?Product Development using Agile Teams: What? Why? How?
Product Development using Agile Teams: What? Why? How?Brad J. Neiman, MS, CSPO, CSM
 
Practices of an agile developer
Practices of an agile developerPractices of an agile developer
Practices of an agile developerDUONG Trong Tan
 
OSSCube - Zend Webinar
OSSCube - Zend WebinarOSSCube - Zend Webinar
OSSCube - Zend WebinarOSSCube
 
Introducing the Enterprise Transformation Meta Model
Introducing the Enterprise Transformation Meta ModelIntroducing the Enterprise Transformation Meta Model
Introducing the Enterprise Transformation Meta ModelRenee Troughton
 
Qa team sport
Qa team sportQa team sport
Qa team sportLeanDog
 
Agile Washington 2015 Creating a Learning Culture
Agile Washington 2015 Creating a Learning CultureAgile Washington 2015 Creating a Learning Culture
Agile Washington 2015 Creating a Learning CultureRenee Troughton
 
Jax Sql Saturday Scrum presentation #130
Jax Sql Saturday Scrum presentation #130Jax Sql Saturday Scrum presentation #130
Jax Sql Saturday Scrum presentation #130Christopher Daily
 
Project Management in Agile Organizations - The Project Managers Role
Project Management in Agile Organizations - The Project Managers RoleProject Management in Agile Organizations - The Project Managers Role
Project Management in Agile Organizations - The Project Managers RoleKnowit_TM
 
How to be an agile programmer.
How to be an agile programmer.How to be an agile programmer.
How to be an agile programmer.Tsuyoshi Ushio
 

Was ist angesagt? (20)

Product Development using Agile Teams: What? Why? How?
Product Development using Agile Teams: What? Why? How?Product Development using Agile Teams: What? Why? How?
Product Development using Agile Teams: What? Why? How?
 
Practices of an agile developer
Practices of an agile developerPractices of an agile developer
Practices of an agile developer
 
OSSCube - Zend Webinar
OSSCube - Zend WebinarOSSCube - Zend Webinar
OSSCube - Zend Webinar
 
Simple design
Simple designSimple design
Simple design
 
Agile intro module 1
Agile intro   module 1Agile intro   module 1
Agile intro module 1
 
Introducing the Enterprise Transformation Meta Model
Introducing the Enterprise Transformation Meta ModelIntroducing the Enterprise Transformation Meta Model
Introducing the Enterprise Transformation Meta Model
 
Qa team sport
Qa team sportQa team sport
Qa team sport
 
Agile intro module 2
Agile intro   module 2Agile intro   module 2
Agile intro module 2
 
Agile Washington 2015 Creating a Learning Culture
Agile Washington 2015 Creating a Learning CultureAgile Washington 2015 Creating a Learning Culture
Agile Washington 2015 Creating a Learning Culture
 
Utah PMA Quarterly Meeting, June, 2009
Utah PMA Quarterly Meeting, June, 2009Utah PMA Quarterly Meeting, June, 2009
Utah PMA Quarterly Meeting, June, 2009
 
Agile intro module 1
Agile intro   module 1Agile intro   module 1
Agile intro module 1
 
Intro to scrum webinar
Intro to scrum webinar Intro to scrum webinar
Intro to scrum webinar
 
Jax Sql Saturday Scrum presentation #130
Jax Sql Saturday Scrum presentation #130Jax Sql Saturday Scrum presentation #130
Jax Sql Saturday Scrum presentation #130
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & Scrum
 
Project Management in Agile Organizations - The Project Managers Role
Project Management in Agile Organizations - The Project Managers RoleProject Management in Agile Organizations - The Project Managers Role
Project Management in Agile Organizations - The Project Managers Role
 
Introduction to agile scrum july 18th
Introduction to agile scrum july 18thIntroduction to agile scrum july 18th
Introduction to agile scrum july 18th
 
How to be an agile programmer.
How to be an agile programmer.How to be an agile programmer.
How to be an agile programmer.
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & Scrum
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & Scrum
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & Scrum
 

Ähnlich wie Facilitation Foundations - A Guide to Effective Agile Meetings

Communicating agile project status to executive managers
Communicating agile project status to executive managersCommunicating agile project status to executive managers
Communicating agile project status to executive managersAgileDad
 
agile42 TCF Team Assessment
agile42 TCF Team Assessmentagile42 TCF Team Assessment
agile42 TCF Team Assessmentagile42
 
Team Dynamics
Team DynamicsTeam Dynamics
Team Dynamicss bhaumik
 
PMI-ACP Lesson 12 Knowledge and Skills Nugget 3
PMI-ACP Lesson 12 Knowledge and Skills Nugget 3PMI-ACP Lesson 12 Knowledge and Skills Nugget 3
PMI-ACP Lesson 12 Knowledge and Skills Nugget 3Thanh Nguyen
 
Key lean principles for organizational change
Key lean principles for organizational changeKey lean principles for organizational change
Key lean principles for organizational changeLeanDog
 
Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011
Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011
Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011IIBA UK Chapter
 
Practical Implementation of Agile Methodologies
Practical Implementation of Agile MethodologiesPractical Implementation of Agile Methodologies
Practical Implementation of Agile MethodologiesSociety of Women Engineers
 
Human aspect in scrum
Human aspect in scrumHuman aspect in scrum
Human aspect in scrumAJAY RAWAT
 
Creating a High Performance Team
Creating a High Performance TeamCreating a High Performance Team
Creating a High Performance Teamtholtz11
 
Bmp1 forming, storming, norming, performing
Bmp1   forming, storming, norming, performingBmp1   forming, storming, norming, performing
Bmp1 forming, storming, norming, performingLife's Too Good
 
Driving an Accountable and Collaborative Culture
Driving an Accountable and Collaborative CultureDriving an Accountable and Collaborative Culture
Driving an Accountable and Collaborative CultureCynthia Clay
 
Successful Agile Transformation - Jim Grundner - Agile Maine
Successful Agile Transformation - Jim Grundner - Agile Maine Successful Agile Transformation - Jim Grundner - Agile Maine
Successful Agile Transformation - Jim Grundner - Agile Maine agilemaine
 
The Disciplined Leader (Property Management Industry)
The Disciplined Leader (Property Management Industry)The Disciplined Leader (Property Management Industry)
The Disciplined Leader (Property Management Industry)AppFolio
 
Driving and Accountable and Collaborative Culture
Driving and Accountable and Collaborative CultureDriving and Accountable and Collaborative Culture
Driving and Accountable and Collaborative CultureCynthia Clay
 
Agile Camp Dallas- Path to Agility
Agile Camp Dallas- Path to Agility Agile Camp Dallas- Path to Agility
Agile Camp Dallas- Path to Agility Agile Velocity
 

Ähnlich wie Facilitation Foundations - A Guide to Effective Agile Meetings (20)

Communicating agile project status to executive managers
Communicating agile project status to executive managersCommunicating agile project status to executive managers
Communicating agile project status to executive managers
 
Strategic Scrum
Strategic Scrum Strategic Scrum
Strategic Scrum
 
agile42 TCF Team Assessment
agile42 TCF Team Assessmentagile42 TCF Team Assessment
agile42 TCF Team Assessment
 
Team Dynamics
Team DynamicsTeam Dynamics
Team Dynamics
 
PMI-ACP Lesson 12 Knowledge and Skills Nugget 3
PMI-ACP Lesson 12 Knowledge and Skills Nugget 3PMI-ACP Lesson 12 Knowledge and Skills Nugget 3
PMI-ACP Lesson 12 Knowledge and Skills Nugget 3
 
Team management
Team managementTeam management
Team management
 
Key lean principles for organizational change
Key lean principles for organizational changeKey lean principles for organizational change
Key lean principles for organizational change
 
Surfing the Agile Wave
Surfing the Agile WaveSurfing the Agile Wave
Surfing the Agile Wave
 
Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011
Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011
Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011
 
Practical Implementation of Agile Methodologies
Practical Implementation of Agile MethodologiesPractical Implementation of Agile Methodologies
Practical Implementation of Agile Methodologies
 
Human aspect in scrum
Human aspect in scrumHuman aspect in scrum
Human aspect in scrum
 
Creating a High Performance Team
Creating a High Performance TeamCreating a High Performance Team
Creating a High Performance Team
 
Bmp1 forming, storming, norming, performing
Bmp1   forming, storming, norming, performingBmp1   forming, storming, norming, performing
Bmp1 forming, storming, norming, performing
 
Driving an Accountable and Collaborative Culture
Driving an Accountable and Collaborative CultureDriving an Accountable and Collaborative Culture
Driving an Accountable and Collaborative Culture
 
Agile pandemic.pptx
Agile pandemic.pptxAgile pandemic.pptx
Agile pandemic.pptx
 
Successful Agile Transformation - Jim Grundner - Agile Maine
Successful Agile Transformation - Jim Grundner - Agile Maine Successful Agile Transformation - Jim Grundner - Agile Maine
Successful Agile Transformation - Jim Grundner - Agile Maine
 
Role of scrum master
Role of scrum masterRole of scrum master
Role of scrum master
 
The Disciplined Leader (Property Management Industry)
The Disciplined Leader (Property Management Industry)The Disciplined Leader (Property Management Industry)
The Disciplined Leader (Property Management Industry)
 
Driving and Accountable and Collaborative Culture
Driving and Accountable and Collaborative CultureDriving and Accountable and Collaborative Culture
Driving and Accountable and Collaborative Culture
 
Agile Camp Dallas- Path to Agility
Agile Camp Dallas- Path to Agility Agile Camp Dallas- Path to Agility
Agile Camp Dallas- Path to Agility
 

Kürzlich hochgeladen

UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
The Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API ManagementThe Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API ManagementNuwan Dias
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Commit University
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?Juan Carlos Gonzalez
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 

Kürzlich hochgeladen (20)

UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
The Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API ManagementThe Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API Management
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 

Facilitation Foundations - A Guide to Effective Agile Meetings

  • 1. Facilitation Foundations Improving the Quality of Agile Meetings V. Lee Henson CST 1
  • 2. Improving the Quality of Agile Meetings Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 2
  • 3. Founded in 2007 - Salt Lake City, UT ✤ Specialize in Public & Private Certification Workshops & Courses ✤ Deep understanding of Agile & Traditional Project Management, (PMP), RUP, Lean, Kanban, Scrum, (CST), XP, & PMI-ACP ✤ Proven Applied Agile Principles in Software, Hardware, Financial, Insurance, Construction, Medical, Marketing, Legal, Entertainment, Research, Military, Government, Retail, Education, Law Enforcement, and many more... 3
  • 4. V. Lee Henson CST ✤ Certified Scrum Trainer ✤ Project Management Professional ✤ PMI- Agile Certified Practitioner ✤ Certified Lean Agile Professional ✤ Motivational Speaker & Executive Coach ✤ Author of The Definitive Agile Checklist ✤ Inventor of Rapid Release Planning ✤ Information Technology / Psychology 4 Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.
  • 5. What Are We Trying To Solve? The 3 most common downfalls of meetings are: The meeting has no purpose or planned Agenda The incorrect participants are invited or not invited The meeting goes exactly as planned, without positive results Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 5
  • 6. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals & Interactions over processes & tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is , while there is value in the items on the right, we value the items on the left more. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 6
  • 7. Agile vs. Plan Driven Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 7
  • 8. Scrum vs. Waterfall Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 8
  • 9. The Why Behind the What: • Teams struggle when they have a Vision with no strategy to get there • Meetings can quickly dissolve when the right parties are not engaged and attend with a purpose • Once the vision and strategy are clear, the needed meetings fall into place Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 9
  • 10. Forming - Storming • Forming represents building of the team • The Forming Stage is Important as team members get to know each other and gel • Storming occurs when the team addresses how they will function both independently and as a group • Storming may be painful, but is necessary for the team to be successful Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 10
  • 11. Norming - Performing • Norming happens when teams adjust their behaviors and begin to work together as a cohesive unit • Motivation increases across the team as a result of Norming • Not all teams reach the Performing stage • At this point teams are able to handle both conflict and decision making without direct supervision Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 11
  • 12. Get a Tool Kit! Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 12
  • 13. Meeting Rules • Every Agile meeting should have a purpose and goal • Prior to holding a meeting, all key participants should be invited • The agenda for the meeting should be distributed prior to the meeting • The meeting goal & agenda should be distributed prior to the meeting • All resources should be reserved and prepared for the meeting • The meeting facilitation toolkit should be well stocked and ready to go • The team should establish and post effective meeting rules Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 13
  • 14. Meeting Rules Continued • The meeting goal and objective should be presented • The time-boxed agenda should be presented • The rules should be posted and all should be reminded to take heed • If at any time a discussion begins that is not part of the agenda, the topic should be added to a running list for later discussion • If the meeting ends and the goal has not been reached, arrange for a subsequent meeting at a later time (do not go over time in hopes of solving an issue) • Once conclusive results have been reached, record all risks, assumptions, and action items • Insure that all list items have a party responsible to address each topic outside of this meeting • Post the results in a visible place for all to see Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 14
  • 15. Fist To Five • Team makes decisions, ScrumMaster only guides the decision process • A ScrumMaster seeks consensus within the team, a quick way to do this Consensus = “I can live with and support that.” • Fist to five: • 5 = wild, unbridled support • 4 = this is a fine idea, wish I’d thought of it • 3 = I can live with and support it • 2 = I have reservations I’d like to think about • 1 = I am very opposed; we shouldn’t move Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 15
  • 16. Fist To Five Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 16
  • 17. What About Business Priority? ✤ We all know the business has a 3 point ranking scale for priority of backlog items: High, Really High, or Really Really High. ✤ The business needs to use tools to help them understand that not everything can be of the highest priority. ✤ With the understanding that we Two websites to assist with priority: would not be doing the work if it http://dotmocracy.org were not important, which items http://www.innovationgames.com have the greatest urgency? Can we arrange them into High, Medium, and Low categories? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 17
  • 18. Time vs. Relative Complexity ✤ Let’s paint the room! ✤ How many hours will it take? ✤ Why all of the different answers? ✤ Have any of you painted before? ✤ Compared to something else you have painted, would it be easier to determine how difficult it would be to paint the room? ✤ Is it easier to reach consensus? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 18
  • 19. Planning Poker - Does It Work? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 19
  • 20. Let’s Use a T-Shirt Size... ✤ Smaller Than XS = a Task. ✤ Extra Small = 1 ✤ Small = 2 ✤ Medium = 3 ✤ Large = 5 ✤ Extra Large = 8 ✤ Larger than XL = an Epic Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 20
  • 21. Understanding MoSCoW: ✤ MoSCoW = more than a Russian Capital ✤ Must Have ✤ Should Have ✤ Could Have ✤ Would Like ✤ Every iteration should have a mix of the above types of items. ✤ Stake holders LOVE the Would Likes. ✤ The Product Owner drives the product backlog and creates the rank order based heavily on the MoSCoW ratings. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 21
  • 22. Create Five Stories ✤ Think about what you have learned about user stories Take a few moments to create five Story Cards that look like the ones we have created so far: ✤ 1) Make 5 cards each with a title & description. (Bonus points for using roles & personas in the description.) ✤ 2) Take the 5 cards and give them each a priority. (Remember, this is from the business perspective.) ✤ 3) Take the 5 cards and give them each a MoSCoW rating. (Remember, this is from the customer perspective.) ✤ 4) Next, take the 5 cards and give them a T-Shirt size based on relative complexity & scope. ✤ 5) Finally, take the 5 cards and place them in stack rank order. Be certain to take all 3 corners into consideration when placing them in order. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 22
  • 23. The Formula ✤ Here is the formula for correct placement of stack rank order of your backlog items. Address risk by performing the items with the highest complexity Must Have High Priority earlier working towards the lower complexity items later in the process: Would Like H-M-L ✤ 1) All Must Have High Priority items should be considered first and foremost. Must Have Medium Priority ✤ 2) Be certain to get at least one Would Like in every sprint. Next should be one Would Like High Priority Must Have Low Priority item. ✤ 3) Next should be the Must Have Mediums and Must Should Have H-M-L Have Lows. Could Have H-M-L ✤ 4) The Should’s go next from High to Low Priority. ✤ 5) Finally, place the Could’s from Highest to Lowest All states are stack ranked from highest Priority. to lowest risk unless the velocity of the Sprint does not afford this as an option. Team velocity always prevails. ✤ Note: Dependencies trump priority & moscow rating. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 23
  • 24. Rapid Release Planning Checklist • Product Vision Statement • Product Roadmap • Release Themes • Release Timeline • Important Dates in Release • Team Identification • Prioritized Product or Release Backlog • Team Velocity (or capacity) • Technical ‘gotchas’ and dependencies that we know already Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 24
  • 25. Release vs. Sprint Planning Release Planning Iteration Planning Attendees Team, SMEs and Team, SMEs and product owner product owner required. Managers/ required. Managers/ customers optional. customers optional. Lowest level of work User stories Tasks breakdown Estimates Provided in Points, t-shirt sizes, or Hours duration (weeks) Output of meeting Release plan (= high Iteration plan (= level plan for multiple detailed plan of tasks iterations) for one iteration) Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 25
  • 26. Rapid Release Planning Instructions: 1) Print out all of the story cards you hope to be included in the release leaving off the product owner t-shirt size. (After all, we would not want to influence the team.) 2) Place all of the cards in a large box, bucket, or basket. 3) Invite all of the teams participating in the release to be part of the rapid release planning session to gather around a large table. 4) Explain that in a moment you will be dumping out all of the cards. The team will have a preset amount of time to find a card they all agree is small in scope. 5) Once the team has identified a small benchmark item, explain they will have a preset amount of time to place all of the remaining cards in columns on the wall listed as small, medium, and large relative to the first item and to each other. 6) If a team member picks up a card they are uncertain about, have them return the card to the table for other team members to review. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 26
  • 27. Rapid Release Planning Instructions: 7) If an item is smaller than small, make a column for extra small. If the item is larger than large make a column for extra large. 8) If an item is placed in the wrong column on the wall, feel free to move it. Any card can move except for the initial small benchmark item. 9) For the final few seconds, I command silence and have the team carefully study as many items on the wall as they can in an effort to allow for any final adjustments to be made. 10) Once the time expires, I excuse the team for an extended lunch and ask the product owners to stick around for a while so we can do a quick comparison. 11) Any items with no disparity or with only one column of difference in either direction between the product owner and the team is a good enough estimate. The team will get better at estimating as they go and product owner will have a lot fewer items for additional review. The teams estimate in this case is the final one. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 27
  • 28. Rapid Release Planning Instructions: 12) If there is more than one degree of separation in the t-shirt size between the product owner and the team, this warrants additional discussion regarding that item. In most cases this limits the number of items requiring additional conversation to a much smaller number. 13) Outliers are marked with moth the team size and the PO size and placed in a separate column for additional discussion. 14) When the team returns, we talk about the outliers for a time-boxed period of five minutes each in an attempt to clarify scope. 15) The teams estimate stands and we move quickly through the items. 16) Before we exit the room, the team takes a sheet of round stickies and identifies any backlog items in the release that have an internal or external dependency. 17) Based on the teams projected velocity, the product owner places items into future sprints to identify any items that could be considered at risk of not making the release. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 28
  • 29. The Sliding Scale ✤ The amount of time allowed for each step in the Rapid Release Planning Process varies based on the number of items you are trying to plan for, the number of people, # Of Items # Of People and whether teams are remote or collocated. The scale at right should be used as a guide and can be adjusted according to what works best for you. Please remember: 0-99 (5) 1 Team (+0) ✤ 1) The times are intentionally FAST! This is to perfect reaching a true grit gut decision instead of pondering. 100-199 (10) 2 Teams (+5) ✤ 2) Every team member may not get to see every card. This is PERFECTLY fine. They need to trust in the ability of the 200-299 (15) 3 Teams (+10) team member that did see the card. ✤ 3) Movement of cards throughout the exercise is both 300-399 (20) 4 Teams (+15) normal and expected. ✤ 4) Limit the number of people participating to no more 400-499 (25) 5 Teams (+20) than 50 People. 500 (30) 6 Teams (+25) ✤ 5) Video Record your teams executing this and send it directly to me or upload via YouTube for a chance to win cool prizes! Times in Parentheses should be added together to calculate the TOTAL team ✤ Note: Remote teams should add 50% to the times listed. time needed for the RRP Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 29
  • 30. At The Wall... Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 30
  • 31. Sprint Planning - Six Steps ✤ 1) Schedule items into a sprint making certain not to exceed the teams projected velocity. (If you did Rapid Release Planning, this step is done) ✤ 2) Review Team member capacity to ensure that people will not be over allocating themselves. ✤ 3) Detail Planning - Breakdown the work into tests and tasks. (No estimating or signing up for the work should take place during this step.) ✤ 4) Member Planning - Allow team members to sign up for the work they choose and give an estimate in hours as to how long each task will take to complete. ✤ 5) Review open issues and impediments that may put any item in the sprint at risk. Replace items as needed with approval from the product owner. ✤ 6) COMMIT to the sprint as a team! (Let’s do this!) Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 31
  • 32. Meeting Timeline Guide: ✤ Scrum Meetings should be time-boxed according to the number of weeks in the sprint. ✤ For example: If you are doing two week sprints, the sprint planning meeting should last no longer than two hours. Three weeks = three hours. Etc. ✤ The same holds true for end of sprint meetings. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 32
  • 33. The Daily Standup Rules: ✤ Daily 15 minute or less ✤ Do not be late... meeting ✤ Fines go to a reputable charity ✤ Same time same place everyday ✤ Team stands in a circle ✤ No problem solving ✤ Chickens around the outside ✤ * No Electronics of any kind ✤ Chickens follow the same rules ✤ No pen and paper to record ✤ Stick to the three questions ✤ Team rules posted on the wall ✤ Always end on time Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 33
  • 34. Hold a Daily Standup ✤ Many teams regard the daily standup as a less than desirable meeting. These teams have not fully embraced what the standup is intended to do. Today we will hold a daily standup: ✤ 1) Eight volunteers will participate in this meeting. Imagine you are a team member developing an e-commerce website. ✤ 2) Take a moment to decide what you have been working on and how you will answer the following 3 questions: ✤ What have you worked on since we last met? ✤ What will you be working on until we meet again? ✤ Are there any obstacles preventing you from making forward progress that you cannot solve yourself? ✤ 3) The ScrumMaster will facilitate, not drive the meeting. ✤ 4) We will try hard to give a solid report in record time. ✤ 5) At the conclusion, we will review and discuss improvements. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 34
  • 35. Review & Demo • Delivered features • Incomplete features • Verifying ‘Done’ with the customer/ product owner • Maintaining trust with customer by not “hiding” undone work • Team and Customer responds to the delivery • The Goal: Collaborative Decision- Making about the emerging product Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 35
  • 36. Retrospectives • Project retrospectives help teams examine what went right and what went wrong on a project • Retrospectives are designed to: • Find & fix problems • Find and Reinforce team strengths • Address both people & technical issues • Use tools and practices proven in the real world • The retrospective is the perfect chance to inspect and adapt. • Teams who perform meaningful retrospectives are consistently better at completing work on time and under budget • Ask the 3 questions and record findings Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 36
  • 37. Sample Retrospective Agenda ✤ What were the major events in our timeline? ✤ What can we observe about the flow of events? ✤ What were the sprint metrics like? ✤ What have we learned about the product as a result of the sprint? ✤ What have we learned about the team as a result of the sprint? ✤ What worked well in our sprint that we would want to do again? ✤ What do we wish we had done differently? ✤ What recommendations are there moving forward with our next sprint? ✤ Inspect the process not the people. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 37
  • 38. Innovation Games • These interactive techniques let your customers and prospects help you create the products they want. Understand customer needs, identify product functionality, learn how customers interact with your products, and shape your products’ future • Luke Hohmann has devoted his professional career to creating environments where everyone can work to their fullest creative and intellectual abilities. He is a committed coach, working with every individual and the organization as a whole to achieve greater levels of performance Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 38
  • 39. You now hold the keys to success! ✤ You have been educated and empowered. ✤ Visit often and drink from the well! http://www.agiledad.com/ Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 39
  • 40. Thank You! Lee@AgileDad.Com- Twitter @AgileDad - LinkedIn leehenson@gmail.com Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 40

Hinweis der Redaktion

  1. \n
  2. \n
  3. \n
  4. \n
  5. If you find that you are beat up at meetings, you are in the right place. The fact is many Agile teams struggle with why meetings are needed or if they indeed provide value. I am here today to tell you that MOST Agile meetings provide little or no value to the team or key stakeholders because of the manner in which they are approached and conducted. This session will help you identify why the meetings are important and what we can do to make them most effective. \n
  6. Principles behind the Agile Manifesto\nWe follow these principles: \n\nOur highest priority is to satisfy the customer through early and continuous delivery of valuable software. \nWelcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. \nDeliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. \nBusiness people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. \nThe most efficient and effective method of conveying information to and within a development team is face-to-face conversation. \nWorking software is the primary measure of progress. \nAgile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. \nContinuous attention to technical excellence and good design enhances agility. \nSimplicity--the art of maximizing the amount of work not done--is essential. \nThe best architectures, requirements, and designs emerge from self-organizing teams. \nAt regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. \n
  7. \n
  8. \n
  9. Nobody likes to be asked to do something because ‘the book’ says we should do it. In fact, this is the ultimate turnoff! Teams need to be motivated to know the why behind the what and have some idea of the value add that the meeting provides. \n
  10. Forming:\n\nIn the first stages of team building, the forming of the team takes place. The team meets and learns about the opportunity and challenges, and then agrees on goals and begins to tackle the tasks. Team members tend to behave quite independently. They may be motivated but are usually relatively uninformed of the issues and objectives of the team. Team members are usually on their best behavior but very focused on themselves. Mature team members begin to model appropriate behavior even at this early phase. Sharing the knowledge of the concept of "Teams - Forming, Storming, Norming, Performing" is extremely helpful to the team.\nSupervisors of the team tend to need to be directive during this phase.\nThe forming stage of any team is important because in this stage the members of the team get to know one another and make new friends. This is also a good opportunity to see how each member of the team works as an individual and how they respond to pressure.\n\nStorming: \n\nEvery group will then enter the storming stage in which different ideas compete for consideration. The team addresses issues such as what problems they are really supposed to solve, how they will function independently and together and what leadership model they will accept. Team members open up to each other and confront each other's ideas and perspectives. In some cases storming can be resolved quickly. In others, the team never leaves this stage. The maturity of some team members usually determines whether the team will ever move out of this stage. Some team members will focus on minutiae to evade real issues.\n\nThe storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict. Tolerance of each team member and their differences needs to be emphasized. Without tolerance and patience the team will fail. This phase can become destructive to the team and will lower motivation if allowed to get out of control.\nSupervisors of the team during this phase may be more accessible but tend to still need to be directive in their guidance of decision-making and professional behavior. The groups will therefore resolve their differences and group members will be able to participate with one another more comfortably and they won't feel that they are being judged in any way and will therefore share their own opinions and views.\n
  11. Norming: \n\nAt some point, the team may enter the norming stage. Team members adjust their behavior to each other as they develop work habits that make teamwork seem more natural and fluid. Team members often work through this stage by agreeing on rules, values, professional behavior, shared methods, working tools and even taboos. During this phase, team members begin to trust each other. Motivation increases as the team gets more acquainted with the project.\nTeams in this phase may lose their creativity if the norming behaviors become too strong and begin to stifle healthy dissent and the team begins to exhibit groupthink.\n\nSupervisors of the team during this phase tend to be participative more than in the earlier stages. The team members can be expected to take more responsibility for making decisions and for their professional behavior.\n\nPerforming: \n\nSome teams will reach the performing stage. These high-performing teams are able to function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision. Team members have become interdependent. By this time they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decision-making process without supervision. Dissent is expected and allowed as long as it is channeled through means acceptable to the team.\n\nSupervisors of the team during this phase are almost always participative. The team will make most of the necessary decisions. Even the most high-performing teams will revert to earlier stages in certain circumstances. Many long-standing teams will go through these cycles many times as they react to changing circumstances. For example, a change in leadership may cause the team to revert to storming as the new people challenge the existing norms and dynamics of the team.\n
  12. The meeting facilitation toolkit should include: \n \n Whiteboard & Markers\n Pens\n Index Cards\n Sticky Notes\n Agile Planning Poker Cards\n Toy or Widget to be held by the only person speaking\n Timer or Stopwatch\n List of Meeting Rules which should be posted\n Team Defined definition of Done (which also should be posted)\n Painters or masking tape\n Bell or Chime to alert when time is up on a topic\n
  13. All agile meetings should follow a set of rules or guidelines used to facilitate and keep the meeting on topic and on time. Below you will find a helpful list of items that will help you be prepared for a meeting and moderate it in an agile fashion. \nBe Prepared: \nEvery agile meeting should have a purpose and goal\nPrior to holding a meeting, make certain all of the key participants are invited\nThe agenda for the meeting should be well defined and published at least 24 hours in advance\nThe meeting goal and agenda should be sent to each attendee prior to the meeting\nAll resources should be reserved and prepared for the meeting\n\n Do you have the room scheduled? \n Do you have a projector in the room selected? \n Will you have at least one participant with a laptop to project the backlog and record issues, actions, and assumptions? \n Is your meeting facilitation toolkit ready? \n
  14. Only one person should speak at a time during the core focus of the meeting unless time is set aside for group collaboration on a specific topic. \nMeetings should follow a specific time-boxed flow. Below I will provide a sample standard meeting workflow:\nThe meeting goal and objective should be presented\nThe time-boxed agenda should be presented\nThe rules should be posted and all should be reminded to take heed\nIf at any time a discussion begins that is not part of the agenda, the topic should be added to a running list for later discussion\nIf the meeting ends and the goal has not been reached, arrange for a subsequent meeting at a later time (do not go over time in hopes of solving an issue)\nOnce conclusive results have been reached, record all risks, assumptions, and action items \nInsure that all list items have a party responsible to address each topic outside of this meeting\nPost the results in a visible place for all to see\nTake the time to allow the team to formulate meeting rules and make certain all meeting participants are clear on what the rules consist of and who is responsible for enforcement. Remember, if it is not written, it is not a rule. \n
  15. \n
  16. \n
  17. \n
  18. \n
  19. \n
  20. \n
  21. \n
  22. \n
  23. \n
  24. \n
  25. \n
  26. \n
  27. \n
  28. \n
  29. \n
  30. \n
  31. \n
  32. \n
  33. \n
  34. \n
  35. Are you looking at me? This is where the real finger pointing begins. The fact is we need to assess the level of management oversight vs. the level of helpful management. This follows the Servant-Leader Principle. It is far easier for managers in these roles to stick to removing impediments and steering clear of the everyday nature of the work the team does. \n\nLikewise, a good Product Owner / Manager can learn to stay focused on the customers needs and the direction the product takes to get there. The Project Manager should be focused on the success of the team and should really work to gain the team’s trust. This role should serve more as a consultant and mentor. The greatest fall any manager level position could take is to dive too deeply into roles outside of their own. \n\nThe fact is effective managers manage from the outside in. Worry about the bare minimum that you need to in order to insure the project’s success. Focus on removing impediments and providing the team the tools they need to be successful. In return you will receive the greatest level of visibility into the project. \n
  36. \n
  37. \n
  38. There are at least 12 unique innovation games (and any number of new games derived by combining elements of these 12 games).\n20/20 Vision: Several potential product features appear on a shuffled set of note cards, one feature per card. The facilitator tapes the first card face-out onto the wall and displays each of the remaining cards one at a time to the participants, asking if the feature on the card is more or less important than the feature on the wall. No two features are allowed to be of equal importance. \nBuy a Feature: Participants see a list of proposed product features and a cost (expressed as development effort or street-level pricing) associated with each. Each participant “buys” a desirable feature; participants may also pool resources to buy features too expensive to be purchased with individual funds. \nGive Them a Hot Tub: Several potential product features appear on a shuffled set of note cards, one feature per card. Some of the proposed features are completely outrageous, such as a “crush rocks” setting for a new food blender. Observers note what happens when a customer uncovers one of these outrageous features. \nMe and My Shadow: Observers carefully record a participant using a product or service. Observers sit next to the participant to watch for and listen to actions, expressions, comments, and suggestions. Observers ask questions of the participant, such as “Why are you doing that,” or “what are you thinking at this moment”. \nProduct Box: Participants imagine that they’re selling a vendor’s product at a tradeshow, retail outlet, or public market. Participants use plain cardboard boxes, glue, paint, crayons, and other scraps and knickknacks to design a product box that they would buy. \nPrune the Product Tree: A very large tree (representing a system or product) is drawn on a whiteboard. Thick limbs represent major areas of functionality within the system. The edge of the tree—its outermost branches—represent the features available in the current release of the product. Participants write new features on several index cards that are shaped like leaves, and then they place these feature-leaves onto the tree, revealing which branches (product features) are important to customers for future improvements. \nRemember the Future: Participants imagine a time in the future when they will have been using the product almost continuously between now and then. (“Future” may be expressed in months, years, or some other time frame.) Participants then write down exactly what the product will have done to make them happy, successful, rich, safe, secure, etc. \nShow and Tell: Participants bring in examples of artifacts created or modified by the product or service. Participants explain why these artifacts are important, and how and when they are used. \nSpeed Boat: A drawing of a boat appears on a white board or sheet of butcher paper. Anchors “attached” to the boat prevent it from moving quickly through the water. The boat represents a product or system, and the anchors are features that the participants don’t like. The lower the anchor, the more debilitating the feature. \nSpider Web: A product name appears at the center of a circle drawn in the middle of a whiteboard. Participants draw other products and services, explaining how, when, and why they are used. Participants then draw lines that link these additional services to each other and to the product’s circle. \nStart Your Day: Participants describe their daily, weekly, monthly, and yearly events related to their use of a product. Descriptions are written on pre-printed, poster-sized calendars or timelines taped to the walls. Participants include events with time frames that match the product’s expected lifecycle or release cycle. Participants may also include one-time events (particularly horrible days where everything goes wrong) and describe how the product helps or hinders as the event unfolds. \nThe Apprentice: An engineer or product developer uses the product as an end-user. For example, if the system is used for data entry, the developer enters data for a couple of days. Observers record the engineer’s actions, expressions, comments, and suggestions. \n
  39. \n
  40. Please send me your feedback and or thoughts. \n