Stuff Bad Product Owners Say

Global Scrum Gathering Pheonix – May 6, 2015

Open Space “Stuff (SH*T) Bad Products Owners Say”

Convener: Bob Galen

List of Participants: yes, lots

Discussion and recommendations:

Format: 3×5 cards – write:

a)    some bad statement a P.O. has said

b)   some context

c)    what would be a better way to have said it, or what would you say to the P.O.

Cards submitted:

(Did not capture “Better options” for each and every card – perhaps those that attended could send additional inputs to jay@dokimay.com ?)

Said:                      “I told the customer we could pull this into the sprint now.  That’s cool, right?”
Context:                
Better options:     Don’t!  Let’s trade x for this.  Let’s trade 2x points for this.  Is this a real emergency?

 

Said:                      “Go faster”
Context:                
Better options:     Ask: How can I help us go faster? What can we trade?…

 

Said:                      “I don’t care [about the things we have already committed to]”
Context:                
Better options:     Why didn’t this come up 2 weeks ago?  The team needs to finish something to stay motivated.  Let’s get this ready for next sprint.  Blue pill/Red pill challenge.

 

Said:                      “We can’t have all engineers talking with the stakeholders; we may as well get rid of the product team”
Context:                Said to prioritization team on getting better feedback loops
Better options:     

 

Said:                      “We can’t have engineers talking with the stakeholders.”
Context:                P.O. feeling out of the loop or defending his position
Better options:     Include the P.O. in the engineer/stakeholder conversations.  There’s a demo for that (those discussions)!

 

Said:                      “Build it like this ….” (suggesting a technical solution)
Said:                      “Implement this using … “
Context:                P.O. is also the Subject Matter Expert.  Trying to tell the “how”
Better options:     Here’s a suggestion.  Here are some options. Lets do an experiment first.

 

Said:                      “I don’t know why we are doing this” and/or “I don’t agree with this story but we have to do it anyway”
Context:                During grooming
Better options:     Then this is not “ready” to be scheduled – we don’t know its business value.  How does this add value to the customer?  How does this add value to cleaner code or infrastructure?

 

Said:                      “I will not pay for technical debt stories”
Context:                
Better options:     If I care about business outcomes help me understand the value of doing stories for tech debt.

 

Said:                      “Teams should get zero points for defects”
Context:                P.O. doesn’t understand what points are for.  Using points for performance credit rather than capacity and flow.
Better options:     Have a discussion to explain how the team uses points to estimate

 

Said:                      “Teams should not be allowed to change points once the release started”
Context:                
Better options:     What are you trying to baseline – features or delivery date?  Have a discussion around who owns the estimates and what they are for.

 

Said:                      “I don’t want external customers on the sprint review because teams didn’t know how to talk to them”
Context:                Developers are lacking social interchange skills
Better options:     Teach mediation skills.  Teach impact feedback skills.  Teach asking questions.  Teach listening skills.

 

Said:                      Complaining about team performance
Context:                Talking to others outside the team e.g. other P.O.s or management
Better options:     

 

Said:                      “I just wrote this story before sprint planning and we must do it now”
Context:                
Better options:     Wee need the team time to refine this first.  This will set a bad precedent – please only make changes at the beginning of a sprint.  Lets move this to the next sprint.  This story isn’t ready – they team hasn’t had time to review it and muse on it.

 

Said:                      “We have to give an estimate without having all the requirements”
Context:                Demanded by the P.O.’s boss
Better options:     Brake down into tasks leaving question marks on what is ill-defined.  Throw the boss a bone to get more details.

 

Said:                      “I want the UI to sparkle like a Tiffany Diamond!”
Context:                (Actual user story)
Better options:     Do a spike to create a sample and see if it sparkles.  Investigate what “sparkle…” means.  Field trip to Tiffany’s.  Discuss – how will we know we are done?  Or how will we test this?
 
Said:                      “Why do I have to write the user stories, isn’t that the teams responsibility?”
Context:                
Better options:     Remind the P.O. that the “O” in “P.O.” means owning the product.

 

Said:                      “I estimated it and it doesn’t match your estimate – you are way to high”
Said:                      “That should be 3 points and not 8!”
Context:                
Better options:     Why do you think so?  Remind the P.O. who owns the estimates.

 

Said:                      “I want all of these stories, so I’m not going to prioritize them”
Context:                
Better options:     

 

Recap – what a bad P.O. should do more of in order to become a better P.O.:

Allow experimentation

Be available as a P.O. the team

Ask questions instead of tell or demand

Get P.O. education on Scrum

Support the team and remember you are a key part of the team.

Support the team by giving the team time.  Rem that introverts (most developers) need time to process and think alone before contributing to the group

Manage the stakeholders

Don’t bully the team

Use “the board” to show real readiness (show the story not being ready and what needs to be done)

Say Thank You to the team – often

(Respect, Trust, … etc.)

 

 

 

Deep Dive into Kanban

Convener: Sriram Natesan


List of Participants: 15 – 20 people, attendee names not captured


Discussion & Recommendations:










Books Recommendation:

***Special thanks to Fred Mello & Sue Johnson for capturing essence of the session with the pictures!!

How to help disorganized people self organize

Convener: Bill Ambrosini
Participants: There were 6, didn’t write down their names ???
Discussion: & reccomendations:
Examples
  • Architect level person starting on taks not in the sprint or related to any committed stories

Strategies to help
  • Micro manage the person when they are off track
  • If it’s outside of the sprint the team member has to ask permission
  • Make it a topic in the retro
  • Post it’s for personal tasks
  • Keeping email box clean, what’s in there requires action
  • Ask them if they might want to try personal kan ban, look up link to this
  • During sprint planning stress taking on only one thing at a time
  • Make sure the sprint backlog is prioritized so they can follow what they should be doing next


Example
Management asks developer to help with something else. He doesn’t communicate this.

Strategies:
  • Tell the dev that they must let the team know
  • Lack of respect for the rest of the team can be a cause
  • May need to talk to his manager so he can motivate him to do this scrum thing
  • Lack of training of team members can lead to this the symptom of looking disorganized

Example
The dev that is a people pleaser and helps the rest of the team

  • Set up a time where the dev’s can exchange ideas 
  • Mid sprint check point
  • Daily scrum will show the symptoms 
  • Look at the burn down every day and be honest about if we are tracking, if not be honest on why
  • Does the team understand why getting to a done and successful iteration is important?


Link to notes: Evernote Link

The Agile Coaching Profession

Convener: Roger Brown, CSC

Participants: ~25, no names collected

Discussion:
Roger gave an abbreviated version of a prior presentation with interactive Q&A. He covered the following topics:

 

The enclosed photos are reminders of the presentation. A more extensive treatment is available at: http://www.slideshare.net/AgileCrossing/the-agile-coaching-profession

 

Additional References mentioned in the presentation:

www.AgileCoachPath.com

www.AgileCoachJournal.com

www.AgileCrossing.com/resources/articles#coaching

www.ICAgile.com

http://www.amazon.com/Mindful-Coach-Facilitating-Leader-Development/dp/0470548665

http://www.amazon.com/Crucial-Conversations-Talking-Stakes-Edition/dp/0071771328/

 

For more information, contact roger.brown@agilecrossing.com

 

Certified Scrum Coach Program Update

Convener: Roger Brown, CSC

Participants: About 35, no names collected

Discussion:

 

Roger gave an overview of the current program as extensively revised for 2015. He also announced the formation of a Scrum Alliance Working Group to create a certification at the multi-team level for coaches who are not currently working at the enterprise level required by the CSC Program. Q & A followed.

 

The enclosed pictures have minimal information and are provided just for attendees to help trigger memories of the discussion. A more extensive treatment can be found in this prior presentation: http://www.slideshare.net/AgileCrossing/csc-program-update-2015-11

 

Further details on the current program are at https://www.scrumalliance.org/certifications/csc-certification.

 

Additional references for Agile Coaching are in the presentation. Two of these mentioned in the session are:

 

www.AgileCoachPath.org

www.ICAgile.com

 

For information on the new certification, contact roger.brown@agilecrossing.com for now. We are just now chartering the team and do not have a public news channel set up yet.

Internal Corporate Coaches/Trainers

Internal Corporate Coaches/Trainers

 

This session was aimed at getting together people who are coaching/training Scrum teams as an internal company employee, not as an external consultant or otherwise Certified Scrum Coach or Trainer.  The aim was to find out the range of teams and organizational issues of concern and then see who would be interested in some sort of ongoing contact.

 

This chart shows the range of teams, general distribution of them, and main topics of interest for those who attended, at least at the beginning when we were doing introductions:

 

#Teams

Distributed

Topics

28

2 US

Leadership training; SMs on multiple teams

9

No

Where do you sit organizationally and what influence do you have?

2

Multiple US

How to get better as a coach

3

No

Change

0

 

Why conversations with 50 sales and marketing personnel

5

No

Remove “doing” frustration (as opposed to “being”)

20

US & India

Overall communication and direction

10

5 US and 5 not

Influence without any authority

30

US

Moved to feature teams issues

40 (5 Kanban)

CA, NJ, India

Release planning; internal change of teams

70

Argentina, Ukraine, … (9 locations overall)

Scrum -> lean, Kanban

9 -> 6

Mostly collocated

Consolidation transition

80-90+

US and India

Variety of maturity levels across teams

137

US (3), Canada, India, Israel, Germany (2), France, UK (2), Korea, Vietnam

Sustaining the transformation and growth in “experimentation”

 

Email addresses were collected.  Those interested who were not able to attend or did not get their email noted can contact Scott Duncan at scott.duncan@intergraph.com.

Outcome Driven Organizations: A framework for change

Conveyers:

Skip Angel, @skipangel

Richard Watt, @richardjwatt

We had a small group of people and had a discussion of how Agile transformations have gone and introduced the framework.


Walkthrough of the framework:

1) Understand the PURPOSE through visioning, guiding values, and finding your organization’s “voice”
2) Drive towards OUTCOMES that achieve your purpose through achievements, artifacts and actions 
3) Execute the IMPROVEMENTS needed against Tools, Process, Policies and People through small and incremental experiments
4) Create and mature in CAPABILITIES needed for continuous discovery, development and delivery for greater performance
5) Establish and improve in BEHAVIORS needed to adapt to change, align across organization, and hold each other accountable towards becoming a resilient organization


Outcome Driven Organizations: A framework for change

Conveyers:

Skip Angel, @skipangel

Richard Watt, @richardjwatt

We had a small group of people and had a discussion of how Agile transformations have gone and introduced the framework.


Walkthrough of the framework:

1) Understand the PURPOSE through visioning, guiding values, and finding your organization’s “voice”
2) Drive towards OUTCOMES that achieve your purpose through achievements, artifacts and actions 
3) Execute the IMPROVEMENTS needed against Tools, Process, Policies and People through small and incremental experiments
4) Create and mature in CAPABILITIES needed for continuous discovery, development and delivery for greater performance
5) Establish and improve in BEHAVIORS needed to adapt to change, align across organization, and hold each other accountable towards becoming a resilient organization


Outcome Driven Organizations: A framework for change

Conveyers:

Skip Angel, @skipangel

Richard Watt, @richardjwatt

We had a small group of people and had a discussion of how Agile transformations have gone and introduced the framework.


Walkthrough of the framework:

1) Understand the PURPOSE through visioning, guiding values, and finding your organization’s “voice”
2) Drive towards OUTCOMES that achieve your purpose through achievements, artifacts and actions 
3) Execute the IMPROVEMENTS needed against Tools, Process, Policies and People through small and incremental experiments
4) Create and mature in CAPABILITIES needed for continuous discovery, development and delivery for greater performance
5) Establish and improve in BEHAVIORS needed to adapt to change, align across organization, and hold each other accountable towards becoming a resilient organization


Team Building Game

Convener: Adele Maynes
Very Short Description:
Purpose: Give the team an own Identity
  1. Selection of 40+ pictures (Cars; Architectural; TV-Shows; Heroes; etc)
  2. Let the team Dot-Vote (5 red 5 Green) the picture they most addressed to.
    • Group the pictures in Like, Dislike and the disagreed ones. (get rit of the non voted pictures)
  3. Let the team add Sticky with words (nouns and adjectives)
  4. Debate the pictures and words.
  5. Let the Team come up with a Team Name; Slogan and Logo.

Agile in the Real World

These people (photos attached) got together and had a passionate discussion about Agile in the Real World.  We brainstormed a list of problems (photo attached), prioritized the list, and had discussions around the top several items.
The top item was “Waterfall is not the enemy / culture is”.  People shared ideas about this and the other top items including integrating the PMO with Scrum, and Management dictating time frames, deadlines and making commitments.
There was lots of great discussion and sharing of ideas.  No real conclusions other than we need to keep fighting the good fights.
Organized and facilitated by:
Harvey Lindauer, CSP

How to scrum outside IT

How to Scrum outside IT?

1. How to scrum in a process-driven environment where the goal is not a release?
■ What is the deliverable? 
still delivering something
■ Use completion of team goal as “deliverable”
■ Define something incremental or iterable– call that the solution or product
■ Consider that scrum is not the answer – try Kanban, Scrumban
■ Latest ScrumGuide is no longer software-specific
■ If lots of changes and interrups with changing requirements might consider Kanban

 

 

2. How to plan when research is involved?
■ Spike story –no deliverable at end – can have acceptance criteria defined –  Non-pointed user-story
■ Time box story for research
■ Operational task on a non-operational story
■ End of story may require another story for next sprint

 

 

3. Kanban vs scrum in non-IT
■ Kanban  good if you have high degree of change or can’t plan ahead

 

 

4. How do you handle planning activities that require long lead times? (like supplies/delivery in construction)?
■ Can you have parts/suppliers in inventory?
■ Can delivery time be shortened? 
■ Find supplier who can deliver more quickly
■ Groom backlog to bring long-lead time (high risk) stories up to top
■ Change procurement model to be more modular

 

Sent from my iPhone

Tech Talk Tuesday

by Ben Carnes

This forum has facilitated developing and sharing of great ideas at my company.

The format:
- free lunch
- broadcast invite to team, management, and other buiz units.
- Topic open to anything (tech, process, vision, …)
- attendance not obligatory. People come because they like the great topics
This forum can facilitate connecting separate teams and business units that may have similar needs but no way of sharing ideas or collaborating.
This form levels the playing field. The developer can become a thought leader. In our experience good thought leaders have emerged from the ranks of the developers.
Resources
- book "Fearless Change" — describes the "brown bag lunch" practice.
- book "Community of Practice" — observations of Silicon Valley's culture

User stories suck

Convener: Brian Holt
Participants: some folks
Discussion: user stories are way better than requirements docs, but they still suck and people still anchor to 'I want'. We should focus more on the problem we're solving and what makes it done. Conclusion, we don't like user stories, there needs to be something better, but we're now to sure what yet. We need to have teams focus on the problem statement.

Impediments for Fun and Profit

Convener: Tom Perry

Discussion:
1) Use a “Reward Board”
- Associates money and impediments
- Massage
- Day off
-Team Event preferred (keep the focus on team level activity)
- Not necessarily monetary reward
2) Post it on the bosses door!
3) Gamify it
- Badges
- Stickers/Kill List
- Issue a challenge
- Program or SoS
- Redeemable “impediment points”
4) “Most wanted” board
- Prioritized
- Update once a week
- Business champion
5) Acknowledgement
- Executive Visit
- Quarterly Meeting
- Ice cream Social
- take Team out
- Coffee time
6) Play the “Fearless Journey” game



Tom Perry
Author of The Little Book of Impediments
https://www.facebook.com/ImpedimentsBook
https://leanpub.com/ImpedimentsBook
email: tom.perry@acm.org
twitter: @tlperry