1. Johanna Rothman Help Your Meetings Provide Value Chapter 13
Copyright © 2017

2. Agile teams have the kinds of meetings listed below
Meetings about the work and work process:
Retrospectives
Review of WIP
Demos
Work-planning meetings
The challenge is how the team can make the most of meetings and also keep them short

3. Retrospectives Provide Valuable Data
Teams should (must!) examine
their results (the work product)
their process (how the team works together)
“The retrospective is a look back at the team’s actions and output so the team can assess their work and learn how best to proceed!”
What is essential for the team to know:
Does the team know how well they are progressing?
Does the team have a clue as to whether improvement can and should be made?
Can team members talk honestly about how the work is going?

4. How often should a team reflect?
Every week or every other week … regardless of whether the team uses iterations
Reflect every time the team releases to the customer (Rothman makes reference to Continuous Delivery… which in many ways requires daily reflection)
Reflect at the start of the project to ask “What do we want to keep, add, remove, or change from previous work experience we have had?”
Reflect at the end to the project… which should be obvious
If not, you must believe there is nothing to learn (and therefore no reason to approve upon) from the experience

5. Plan the work, then learn from the Plan
Single Loop Learning
When the team and Product Owner check their assumptions, and not just what was produced (for example, a Feature), they are able to replan…
Double Loop Learning

6. Rothman’s advice … produce value!
“Is the team working in a way that promotes the value of the product underdevelopment?
Where are the opportunities to improve and change?”
Two references provided:
Agile Retrospectives
Esther Derby and Diana Larsen
Getting value out of Agile Retrospectives
Luis Gonҫalves and Ben Linders

7. Use a “Parking Lot” for the Improvement List
Use a White Board for all to see… Allows team to track what it added and have a way of working thorough through the parking lot When the team plans its work, they can decide how many items to take off the parking lot, turn into stories, and work on them The team can convert each entry on the list to a “story”… with each having a specified acceptance criteria

8. TABLE 11 - Use a “Parking Lot” for the Improvement List
Idea
Date
Added
Value to Us
Notes
Progress
Figure out how to build learning into the week
Feb. 10
We would have time to learn
We are so full of WIP and new work we don’t seem to have time to do this. If not started by Aug. 10 (6 months) do something different
Goal: Some kind of learning every week
Smoke test assumption from API
May 2
We would know about the builds
Full API smoke tests take a few weeks…chip away
Goal: For all new features, another 10% every two weeks
Full system test automation from API
We would have support for frequent changes
Start with engine, add , admin ASAP
Mob.
June 15
Improve throughput?
None yet
Track cycle time as well as velocity
May 15
Story size
Just talking about it made some progress
Need to change board. Tool doesn’t allow us to do both

9. The team needs to “Walk their Task Board”
“… team members need to connect with each other and see each other’s work on a frequent, if not daily, basis.
The team needs to understand what everybody is doing…
… and especially if any work is “stuck”
“Walking the Board” is a team responsibility
The “Daily Stand-ups” provide the structure for this…
Senior Project: On a different scale, the weekly team meetings with their Faculty Adviser should provide the same opportunity

10. “The task Board is for the team”
The Board represents the state of the team… For each Feature “story” the team needs to be clear about what “Done” means… Retrospective learning is necessary if the team is to be affective in “pulling” the work from the Product Backlog Learning… so that the team knows all of what is needed to design and develop the functionality required of the “story” All team members are responsible for knowing and working toward moving each “story” to “Done” Meaning that the team is responsible for managing the WIP!

11. Standups Create Recommitment & Collaboration
The purpose of the Standup is to reveal the status of the team’s work… … that is, where each member (or group) is in completing their WIP This “face-to-face” interaction helps the team members recommit to each other and to be aware of whatever impediments they face Transparency… means no need (or place) to hide!

12. How to Conduct a Standup
First… the Standup is not to be a working meeting!
The meeting’s focus is on the Task Board… and an assessment of progress
The standard “Agile Questions” of each team member:
What have we completed since the last standup?
What are we working on right now?
What are our impediments?
What is needed to move the work to “Done”?
The team lead manages the Standup
The team lead may (and probably) should be rotated amongst the team members

13. Trust?
There could be good reasons for someone to not have finished the work?
Assume that people want to do the best job they can and that team members question each other out of a desire to supportive and to provide help if needed…
On the other hand, if your team is blaming people for not finishing work… what would you think would be the impact on the team’s culture?

14. Watch for Standup Antipatterns
You would hope that the team can recommit to its work and expose problems the team needs to solve. Rothman’s list of possible antipatterns: Blaming certain team members for not finishing “their” work Allowing people to take other people's work while it was being worked on by other team members Standups taking more than 15 minutes! The standup becoming a serial status meeting There are lots of ways that standups fail with the result being that the team becomes dysfunctional

15. Solve problems outside of Standups
Standups are not about doing the work but about getting the work “done” Standups should expose problems… … Impediments associated with a specific Feature or Feature story There may be a need to plan a “spike”… an experiment to get past the blockage The team may have overcommitted in a sprint … the result being that WIP is accumulating The team needs to understand the problems and solve them The Standup is not where the work is done… but where the commitment is made to do the work that is needed.

16. Rothman’s reference to http://leancoffee.org/
Lean Coffee is a structured agenda-less meeting
Team members build the agenda and begin talking
Conversations are directed & productive because the agenda was democratically generated
How it works
Set up a Kanban board – 3 columns
Each member has pad of post-it notes and a pen
Team members add the topics To Discuss
When the ideas reach a certain point (the team decides when), each topic gets a 1 to 2 sentence introduction … so members know what they are voting for
To Discuss
Discussing
Discussed

17. Rothman’s reference to http://leancoffee.org/
How it works Vote and Talk Each member gets two votes (both votes can be placed on the same topic) The votes are added for each topic and the conversation begins The “power” is that the team has a list of topics everyone is interested in and is motivated to discuss for real
To Discuss
Discussing
Discussed

18. Problem solving meetings that focus on a Problem
Example
Prepare the agenda for a problem solving meeting
Specify the location & participants
Provide the agenda in advance so participants have time to prepare
List this week’s problems (“obstacle removal” or “impediment removal”
Discuss each problem (timebox the discussions… if there is no resolution, escalate the problem to the “next level”)
If the team can’t resolve the problem, add the problem to the team’s “task board” as a action item with a “date” for its resolution
Review any outstanding action items or task board item not yet resolved
Adjourn the meeting

19. Demonstrations to Show Progress and Value
Scrum: The expected collaboration between the Team and the Product Owner Working from the prioritized Product Backlog Team and Product Owner agree on what is to be “pulled” into the next Sprint If the Team and Product Owner have not as yet collaborated on the understanding of what each “story” requires… it is done at this time (the 3 C’s) Rothman’s “possible structure for the backlog planning meeting” is an example to the 3 C’s that the team and the Product Owner collaboration” This includes whatever is needed to “refine the stories for the team”

20. The Three Amigos Strategy
Three amigos refers to the primary perspectives to examine an increment of work before, during, and after development.
Those perspectives are:
Business - What problem are we trying to solve?
Development - How might we build a solution to solve that problem?
Testing - What about this, what could possibly happen?
People holding these different perspectives should collaborate to define what to do, and agree on how they know when it is done correctly
The end result of such a collaboration results in a clearer description of an increment of work often in the form of examples, leading to a shared understanding for the team

21. Organizing the Team’s Meetings
How to best “manage” the time spent at meetings
“If the team uses iterations… consider a standup during the day” (morning preferred)
Timebox all meetings
Backlog planning
Sprint planning
Standups
Sprint review
Backlog refinement (“grooming” Mike Cohn’s term)

22. Rothman’s “agile approach to meetings”
Start the iteration on a Wednesday after lunch
Conduct the one-hour timeboxed planning meeting right after lunch. Start the iteration!
Consider standups every day just before lunch
On the middle Wednesday, conduct a one-hour timeboxed refinement meeting in the morning
On the last morning of the iteration, that next Wednesday, start a demo at 9:00 AM
Start the next iteration after lunch (back to step 1)
(“… I prefer the middle of the week so that the team doesn’t need to work over the weekend to get ready for the next iteration)

23. “Rothman’s flow-based agile approach & meetings”
Team meeting … review the task board (before lunch) and do the daily work as committed Create a cadence … that is, “make sure important events and activities occur on a regular, predictable schedule” Create a cadence for the retrospective activities that is “make sure important events and activities occur on a regular, predictable schedule” Decide about demos as part of the team’s working agreements … that is, demo a stories as “done” Agile methodologies “tend to have more meetings, touch points, about the work”

24. Measure the Value of Meetings
Like the “standups”, each meeting should have a purpose… recognized by its value by all attendees!
If you have to ask… your agenda is at fault
If you have to ask… your ability to work the agenda and get the intended results associated with each item is at fault
The team lead should work with the team in identifying what needs to be discussed and what needs to be covered… and all should know in advance what the expectation are
Like the “standups”

25. Create Learning Opportunities
“Learning about the product domain…”
Learn about the Organization and Customers (“users”)
This is the reason for close collaboration with the Product Owner … this person represents all the stakeholders that will be affected the work that is done
Learn about other ways to work
Rothman… “When I visit teams, I often discover they barely know the agile methodology they are attempting to practice.”
A self-organized team would identify what they need to learn and … have an agreed upon plan as to how they intend to do the learning

26. Recognize Meeting Traps
Examples of how meetings fail:
The standup becomes a serial status meeting
Asking each attendee about their status
Focus is on the individual and not on team collaboration and commitment
The team meets instead of delivering finished work
Meetings with no clear agenda
Work but no commitment to delivering value
Too much WIP… little, if any, Product Owner collaboration over stories
Team members don’t have enough time in retrospectives to identify possible solutions or experiments
Identifying problems but not collaborating on how to solve the problem
Team members commit but provide no evidence of delivering value … trust is rare