Tuesday, October 10, 2017

Fwd: Beyond Hiring




Begin forwarded message:

From: "Sabarsky, Leon (GovCIO)" <Leon.Sabarsky@va.gov>
Date: October 10, 2017 at 7:20:03 AM CDT
To: "Sabarsky, Leon (GovCIO)" <Leon.Sabarsky@va.gov>, "leonsabarsky@gmail.com" <leonsabarsky@gmail.com>
Subject: Beyond Hiring

 

Friday, October 6, 2017

Scaling Agile: First Steps session

Hi,

Attached are photos of the notes and participants list from my session at Agile Open Florida. 

Thanks for a great event! 


All the best,
Anitra Pavka 


--
All the best,
Anitra Pavka
mobile: 785-218-7930

Do We Need Estimates? #NoEstimates


Topic Title: Do We Need Estimates? #NoEstimates

Initiator: Beth Galambos, PO, Healthesystems

Participants: Ryan Dorrell, Isa Jelez, Marilyn Brislin, Kate Leonardo, Bill Somerville, Sherrie Hanrahan, Patrick McClain, Liliana Talice, Prachi, Gordon Ridge, Riccardo Reimers, Ruchir Shah, Linda Cook, Bashanth Prasannathiotha

Discussion Highlights:
  • High/medium/low confidence on estimates 
    • Seen by business as 'scientific' 
  • Minimal business increment (MBI) 
    • What MUST go out the door to be value to the user 
  • Why even bother with estimating? 
    • Dev teams debating point values 
    • Teams may overestimate if there is a penalty for being 'wrong' in their estimates 
    • They have to learn, especially if coming from a waterfall environment 
  • Fixed vs variable outcome deliveries 
    • Fixed - more time estimating 
    • Variable - less valuable estimating 
  • Larger efforts not focusing on risk and project management, but should 
  • Customer education is important because some think that it's about 'more and faster' 
    • What it's really about is eliminating waste 
  • Who gets involved with estimating? 
    • Whole team, part of team? 
    • High level - representatives of the team 
    • Detailed - the whole team 
  • Retrospecting on stories' estimates 
    • How did we do on that estimate now that the work is done? 
Ideas for Action/Next Steps:
  • Anchor stories - bring a 3 pointer and 5 pointer to refinement/planning and point all stories compared in size to the anchor stories 
  • Kanban - try using a mean or average point value for every story. Do this if you have data to support it.

Agile Metrics - Light weight and relevant


Topic Title: Agile Metrics - Light weight and relevant

Initiator: Prashanth Prasannathirtha

Participants: Kevin Krieger, Suzanne Layne

Discussion Highlights:

What metrics are easy to produce and valuable to key stakeholders?

  • story points per sprint - this helps product owner to understand capacity of team and helps in future planning
  • Number of support hours spent by the team - This helps to understand the average time spent by team for support activities and provides inputs for sprint planning
  • number of releases per time period - this shows how quickly team can release features to production
  • sprint burn down charts - helps team to understand their progress. Not for management reporting
  • release burn up charts - in case of projects, this kind of chart shows the progress at end of each sprint. Helps to understand the overall health.
Additional discussion points
  • Comparing velocity across teams is not needed as velocity is specific to a team. 
  • defects in non-prod environment is not relevant to end user
  • if you have long running teams, the is better awareness of team's capacity and better trust between PO and teams. This will eliminate need for lot of metrics.
  • automation helps you to improve predictability and reduces manual metrics
  • some of the tools generates reports automatically


Ideas for Action/Next Steps:

How to Measure Progress & Stay True to Agile




Topic Title: How to Measure Progress & Stay True to Agile

Initiator: Monica Hernandez, MAS Global Consulting

Participants:
Stephanie Raffman
Tabatha Bowers
Jamie Fulmino
Beth Galambos
Kelley Watson
Lani McDaniel
David V Corbin

Discussion Highlights:
Ideas for other metrics to measure include...

  1. Technical health - not just technical debt 
  2. Planned to done ratio 
  3. Business value of done features 
    1. Scaled agile/SAFE 
    2. Have a business lead or chief PO assign a business value to Features/Epics across all teams 
    3. Sync point for prioritization 
  4. Adoption 
  5. Ask vs release cycle time - Dev Ops 
  6. Team motivation and happiness 

Demos/Review - Stakeholder Participation

  • Execs/key stakeholders can't always attend every 2 weeks. Push for them to attend every few Reviews. They will see the value and make time more often. 
  • Don't blame them for not attending and then not having information about your team's progress. Instead, offer to help them understand your team's progress so that they do not get defensive. 


Educate the Business

  • Business will want a project plan/% complete timeline 
  • Focus their attention on the right (other) numbers instead 
  • Train your HiPPO (highest paid person's opinion) 


Caution: Do not compare teams!
  • It's not apples to apples 
  • If necessary, aggregate numbers and report together, so as not to put any one team on the spot 


Ideas for Action/Next Steps:

Topic Title: What is beneath vunerability courage and shame

Initiator: Kristy Erbeck

Participants:

Discussion Highlight:

Trust, shared experiences
getting lost together and being found
- Free to ask the dumbest questions and make suggestions
- taking risks
- willing to be stupid
- being transparent about things that could cause you pain
- risking feeling bad
- people seeing through you
- showing your soft under belly

Failing/Failure (alone or together)
- scary
- freing
- brave
- relief
- fear of unknown

How go through the failure or loss
- defensiveness
- anger
- withdrawal
- be funny
- comic relief
- sadness
- depression
- over reaction / over compensation

Reference:  Radical Candor - Kimberley Burke


Ideas for Action/Next Steps:



Topic Title: Life after Agile--> Agile Life

Initiator: Julee Bellomo

Participants: Lots

Discussion Highlights:
Agile Coaching is not going to be the same in 5 years.
First phase: Frameworks
Second Phase: Scaling Agile
Third Phase: Design Thinking
What are you doing to prepare for the future?
* Moving agile to business side
* Work with Millenials
-Put problems and problem solvers together
-Learn to listen and acknowledge them!

* Put yourself into different positions
* Have the ability to pivot
* Become a change agent - help others to change
* Nourish an agile mindset - embrace new learning models
* Practice lean thinking - train and study for it. Look for it. Incorporate into your life.
* Be creative
* Foster a growth mindset and continual learning
* Be okay with failure

Prepare now to augment your agile world:
* Coaching as a career
* Facilitation as a career
* DevOps as a career
* Training as a career
* Mediation as a career

It's a whole different world out there! Fields that agile is moving into:
Agile / Law / Real Estate / Marketing

Follow your passion (Maslow's triangle)
Create safety in your life, find your tribe, follow your passion
Prepare now with service work, volunteering, be on a board

Continual Learning + Opportunity = A Life after Agile

Managing large numbers of stakeholders and products with a small team




Topic Title:
Managing large numbers of stakeholders and products with a small team
Initiator:
Carrie Waddel
Participants:
Erik Tandberg
Travis Thompson
Cindy Covertry
Vanessa Smith
Connie Pope
Tami Volkert
Stephanie Ruffian
Sarah Urriste
Christopher Martinez

Discussion Highlights:

  • How can we manage multiple customers, especially when there is sensitive data?
    • Use codewords!
    • Invite customers to see backlog and help determine priority
  • Managing Stakeholders with disparate needs
    • Get them talking to one another

Ideas for Action/Next Steps:

  • Internal "Dress Rehearsal" of planning and refinement meetings, then have the "real one" with stakeholders present
  • Include agenda in Review meeting invites to encourage attendance
  • Shorten Reviews in general, keep them higher level
  • Tag which items in a sprint we intend to demo
  • Share the attendance list

2:20 work agile - Venus

2:20 work agile - Venus

Working with Agile and not

Managing product BA team - not PO
Development is Agile

Rita mixed Agile
Jack fill Agile team
Pushback from other departments, get their buy in for inclusion
Started with Kanban, using Scrum

Kanban is multiple sprints

Scrum for enhancements
Kanban for production support

Pitfall totally scrum - emergency updates
Refine/Breakdown stories to fit into a sprint

Requirements for one month

Contract waterfall - tie box requirements
Dev Agile

How do you transform to Agile?
Business requirements should be features
User stories - writing is Agile and requires training
Keep in mind velocity
Conversation between waterfall - requirements and development deliverables
How accurate is velocity and team working together
Using 3 week sprints

2 week sprint - how quick can you deliver

Pushback from departments
Level of transparency- fearful when moving from waterfall
Have good relationship with resource management
Need Mature process for process
Have to work at it - be open minded and listen
Iterative process
Building trust - guide them to make decisions

Can have waterfall and agile teams in one company

Documentation- don't change
Break into feature
Only include actual new feature in specs. Any general information in template

How long to work toward user stories? 6 months to year
Longest transition - stop thinking linearly
Product should be thinking function not by page - create smaller pieces
Hands on coaching - really helps

Infrastructure and security separate

Cold turkey transformations? - might be easier

Grow - fully agile
Documentation same process - but moving to "done"
SDLC - who needs to sign off

3 refinements before can move into sprint
Steering committee and two more committees before going into sprint
Components, model for what needs to be approved

Work on velocity- product owner needs to understand

Pitfalls
Adding extra work









Cheers,

Rita


Topic Title:
Why does Agile adoption F.A.I.L? (first attempt at learning)

Initiator: Dominique McCarthy

Participants: Serg Ivanov, Dan Crowley, Mike Miller, Daniel Hamilton, Chris Levine, Bill Dean, Daniel Hirschlein, Eli Berrios, Bernie Manlapig, Oral Ashley, Patrick McClain

Discussion Highlights:
What is everyone's experience with Agile -- where are you in the process of adoption?


- What are the obstacles to adopting agile?
Understanding the agile methodology, not knowing the why of changing to agile
Implementing takes time
Cargo cult agile - building fake notions that the process will fix everything
No committment -- top down and across other teams (sales sold specific product to be delivered on specific date)
People use buzzwords / terminology without really understanding them...getting them confused-- agile, scrum, kanban
Understanding the why -- want to be more responsive
Too easy to snap back to old ways
Unsure how to handle emergencies
Not understanding the context --- Cynefin ...agile is not the answer for all scenarios
Complicated │Complex
Chaos           │  Simple



- What are the solutions/ideas for action/next steps
Agile coach or evangelist to continue enterprise education
Create a space for adapting
Failure is ok → First Attempt at Learning...just experiments
Having Sprints/iterations to show work completed and allow opportunity to make changes
Prioritize; respect the sprint -- if something comes in, something needs to come out
Use Visual tools to show stakeholders
Add in spikes, placeholders to allow time for research and production issues
Celebrate successes -- even small ones -- then more teams will want to adopt
Continuously retrospect and learn from the past -- don't 'snap back to old ways' and abandon all together




Topic Title:  How do you stabilize teams in a highly chaotic enterprise environment

Initiator:  Mike Miller

Participants: Denise Duggan Jamie Leatherman, Amanda Serrano, Elton Nix, Jennifre Maldonado, Swati Chintana, Daniel Bridges, Tyson Bakes, Vicki Braun, Ed Brunner

Discussion Highlights: 
Isolate team
Visualize interruptions
Visualize impediments
Sococo
Joural commitment / delivery
Swarming
Distance doesn't help communication
Metadata on trends
Kill sprint
Negotiate things out if you pull stuff in
Slack plug-in (Standuply)
Filter work through PO
Tell PO "no"
Agility Health Radar - survey - integrates with 1
SAFE Team Heath Check

Ideas for Action/Next Steps:
Build trust
Check in with your team
Get team buy-in / involve them in decisions
Cynefin scale
                                     |
         Complicated        |       Complex
 ---------------------------|-----------------------------
          Chaos                 |        Simple
                                     |         

Life after Agile






Julee Bellomo
703-362-7525

Vulnerability image



Sent from my iPhone

Topic Title: Self-Forming Teams

Initiator: Adam Hsu

Participants: Adam Hsu, Kate Leonardo, Gordon Ridge, Kevin Tighe, Riccardo Reihers, Tina Duncan, Anitra Pavka, Gaile Sweeney, Michelle Michael, Jason Stanley, June Fox

Discussion Highlights: In this session Adam Hsu provided background and insights on what a Team Self-Formating event is about and why an organization might consider leveraging it to stimulate a true feeling of change during an organizational redesign to enable small, co-located cross-functional teams to self-organize around the work.

Key points that were covered at the beginning of the session were:
1. A Team Self-Forming event should be planned months in advance and should not be done lightly
2. Leaders, teams, and coaches need to be trained and coached before, during and after the event, which only marks the beginning of a change in the organizational design
3. People are also given the opportunity to "opt-out" ahead of the actual self-formation event if they feel they do not want to be part of the organizational redesign to create small, co-located, cross-functional teams
4. Senior leadership must truly support the outcome of the event and not undo decisions made by the people who self-formed into teams by reassigning people to what they feel "should be" the teams - this takes as much time needed to coach leadership on understanding and following through with support
5. Facilitators need to understand that it is not about them and the event is completely focused on the best outcome of the people in the room who are empowered to form into the best teams they can to support the product or organization's goals
6. Facilitators also must be comfortable knowing that self-formed teams may not result from the event due to whatever unforeseen circumstance and allow non-formed teams at the end of the day
7. Facilitators need to be prepared to deal with emotional and sometimes very tense situations where the participants are challenged to self-form due to personality conflicts, different intents, and misunderstandings.

Observing the key points above, the session participants were given the opportunity to learn how to facilitate a team self-formation event using a simulation.  Participants were given the challenge of self-forming into teams that would support a new restaurant with a very clear product vision.  Using a cartesian map to help visualize four dimensions of (1) Love (2) Hate (3) Expert and (4) Novice the participants oriented themselves in the room based on those four dimensions regarding each critical skill identified by the group to fulfill the product vision.  Finally, the participants were then facilitated through several rounds of self-formation based on their personal skills map into cross-functional teams that could meet the goals of the product vision, and also checking to make sure that those who would be potential team mates are happy about the configuration.





Ideas for Action/Next Steps: After learning how to run a team self-formation exercise the participants were encouraged to run their own simulations in their workplace to experience for themselves how it would feel to facilitate a team self-formation event. Once they are comfortable with the mechanics of how to facilitate a team self-formation event, they may choose to begin planning an actual team self-formation event for their own organizational redesign.

Measuring Value Beyond Straight Fibonacci


Topic Title:Measuring Value Beyond Straight Fibonacci

Initiator: Steve Sladoje

Participants:
Steve Granese, Simon Stankeuicius, Lucille Scaglione, David Haight, Brandon Peacock, Jack Cayon, Efrain Perez Jr, Lani McDaniel, Sarah Urriste, Danielle Hinson, Kevin Krieger

Discussion Highlights:

  • Add Business Value to Features
  • Epics are likely too large and would have necessarily large risk in the valuations
  • PBIs are too granular
  • Screen Shots from the Flip Charts:







Ideas for Action/Next Steps:

Explore your own factors and create valuation calculations using the ADDITIVE, SUBTRACTIVE and MULTIPLICATIVE techniques to see what kind of Business Valuations you might uncover.

Topic Title:  How do you incorporate business team UAT testing into Agile development team cycles / sprints to avoid late testing and defects ("wagile")?

Initiator:  Shannon Hausey & Sherrie Hanrahan

Participants:  Brian Attuso, Patrick McClain, Knud Hansen, Caurie Waddell, Jody Dattisman-Wagman, Rene Clayton, Cindy Coventry, Tracey Long, Jakob Andersen, Evy Vicioso, Theresa Travis, Bill Aikens, Jennifer Maldonado, Amit Bathia, Brad Silverman, Yvette Krayer, Tabatha Bowers, Vanessa Smith, Laura Boodran, Rita Oglesky, Erik Tandberg, Sheetal Agonle

Discussion Highlights:
  • Struggle with business not having a UAT test plan.  Some business users want to use UAT test results for UAT.  Looking for suggestions on how to bring in business users earlier for UAT, possibly as part of the sprint.
Ideas for Action/Next Steps:
  • Have collaborative brainstorm session with SME's on both business and IT side to identify how testing should be conducted, and note differences in QA testing vs. UAT testing.
  • Push back on the business with a deadline for UAT completion.  Hold them accountable for timeline, and force them to make decision on priorities if UAT is delayed or there are other blockers keeping team from finalizing / pushing to production.
  • Try to do UAT at the same time as QA, iteratively, then the end to end / UAT at the end will not be as tedious and should result in less defects.
  • Schedule time with business to review their test plan / test cases for UAT.
  • Ensure there is end to end integration testing planned.
  • Keep business and agile team engaged throughout the entire process (not just at kickoff and project completion).
  • Use a Cloud to spin up environments for testing.  User can deploy to environments when ready (after content updates / non-dev changes are applied) and will not hold up systems dev team.
  • Perform live demos for users, vs. screen shots.  Suggest "Science Fair" style where users can site with QA or Developers for an up close view of the work.
  • Host demo, per usual, but then schedule one hour after the demo for a working session / UAT for real time feedback.
  • Automate test scripts for UAT when possible.
  • Hire or assign a dedicated UAT tester, vs. relying on FTE staff to do it side of desk.
  • Use Product Owner to UAT at the story level to catch functional issues quickly.  
  • Add a task for UAT to the user story, and assign to business user.  Story will not be done until UAT completed.
  • Cross train QA and Developers as Users for better understanding of the UAT process.
  • When there are hold ups to project completion because of UAT / business sign off, determine cost of delay and share with business owner / sponsors / management to give a big picture perspective.  

Topic Title:How to stay busy in a sprint (keeping developers active at the end)

Initiator: Tracy Sells

Participants: Kate Leonardo, Gordon Ridge, Bill Dean, Kevin Krieger, Sarah Baca, Becca Franklin, Stephanie Raffman, Rita Oglesby, David Aaron, Evy Vicioso, Jason Stanley, Tyson Baker, Tami Volkert, Sherrie Hanrahan, Graile Sweeney, Theresa Travis, Kelley Watson

Discussion Highlights:
In the last part of the sprint, where QA is testing the last stories, and developers have idle time, what should they work on to stay busy?

Below are the ideas from the group:
  • Technical Debt
  • Breakdown Stores
  • Pull Stories from future sprints
  • Review Technical Documentation
  • Plan for next sprint
  • Technical Assessment Stories (Spikes)
  • Training / Personal Development
  • Cross Training in other areas (Dev / Test)

Ideas for Action/Next Steps:

Find ways to reduce the size gap
  • Smaller Stories
  • Have QA and Developers work in tandem (TDD) so everything is done at the same time
Implement a testable API for QA Automation so when everything is done the tests can run and be completed.  This would force the developers and the testers to code against the same API.

Topic Title: How to successfully execute training for  globally distributed teams

Initiator: Kimberly Reynolds

Participants:Wendy Culpepper, Alina Geddard, Karam Labban, Phil Zofrea, Rita Oglesby

Discussion Highlights:
1. Different Time Zones and Cultures - have meetings using video and tent cards. For each person not in the same room have a tent card with all the team members that are not in the same room. Challenging to find times to meet for several hours across time zones.
2. Challenge to perform SM and PO and team training globally. Some ideas presented were:
  • Have a coach at each location
  • Send a coach for the first time and then train someone to assist in training
3. Use different applications to assist in the locations differences. Suggestions were:
  • Adobe Connect
  • ZOOM
  • SOCOCO
4. Need to understand the WHY for going Agile with leadership first. Create the right environment and have the right people to assist.

Ideas for Action/Next Steps:
Have a conversation with leadership asking them to discuss the why for the company and how it compares to the WHY for going Agile and have them NOT use buzz words.
Need to hire a consulting company to assist

Uranus 1:10p

Why does Agile adoption F.A.I.L.?

Daniel Hamilton

Kanban Cannot Save You: Overcoming Scrum Antipatterns without Abandoning Scrum


Topic Title: Kanban Cannot Save You: Overcoming Scrum Antipatterns without Abandoning Scrum

Initiator: Sam Falco

Participants: Denise Duggan, Jamie Leatherman, Joey deVilla, Abbie Field, Lemont Chambliss, Eileen Cease, Laynn flannery, Ed Brunner, Albia Santiago, Charlie Neighbors, Marilyn Brislin, Liasa de Almerde, Anne Jones, Adam Ullery, Richard Martinez, Tom Clemente, Michael C. McGreevy

Discussion Highlights:What problems do we see in Scrum that lead teams to say, "Let's do Kanban," and how can we solve them?

Antipatterns:

  • Constantly carrying over stories into the next sprint
  • "We're a service organization, we have to do product support issues the minute they come in." (Kanban is actually good for this type of problem... if that's really the problem)
  • Priorities change
  • Management does not value team focus
  • Role alignment != actual skills
  • Environments don't match (structural issues)
  • Team member churn
  • Team member attrition

Ideas for Action/Next Steps:


Correcting Course - addressing the antipatterns

  • Continuing education - outsider or internal
  • Validate whether executives really commit to Scrum
  • Enforce and respect the Product Owner role
  • Relaunch the Scrum Team(s)
  • Listen to your coaches
  • Don't have a coach? Get one.
  • Can't get a coach? Get a mentor:
    • Local Agile meetups
    • Slack Channel - AgileFlorida.slack.com
  • Take the Valpak Agile Tour
  • Read/Understand Agile books and apply the lessons
  • Pick your battles--don't try to fix everything at once
  • Find your "why"
  • Solve your people problems



Topic Title: Identifying/Measuring Bandwidth

Initiator: Daniel Bridges

Participants: Tyson Baker, Dennis Griffith, Jimmayya Jojjauaru, Justin Hirota, Chris Teeples

Discussion Highlights:
Tracking is your friend - if something seems important, track it. How many production issues did you have? You'll know if you track where issues are discovered and their size.

Sprints are for prediction - avoid adding unpredictable things to them

Ideas for Action/Next Steps:
Track new fields in your software like Jira. Where did bugs get discovered, by who, How many hours of QA is this ticket, etc. Provide this data to stakeholders/PMs to enable decisions.

Manage external dependencies- make your definition of ready include what you need for tickets, you aren't ready to work on tickets if something unpredictable is a prerequisite.

Process brings predictability - if you can define a process, you can start predicting things. If you don't have the control over something, like UAT, maybe it shouldn't be part of your sprint, since that needs to be predictable.

Analysts in Agile


Topic Title:  Analysts in Agile

Initiator:  Jill Wilson, Healthesystems

Participants:  Efrain, Jamie, Simon, Mariane, Jack, Brandon, Euy, Tina, Tabatha, Lani, Jonathon, Ed, Dan, Kevin, Marilyn, Vanessa, Prachi, Jane, Kelley, Denise, Zach, Jill.

Discussion Highlights:

Tell us what you, as an Analyst, do on your Agile team:
  • work closely with the Product Owner to gather requirements and write User Stories
  • work with Product Owner to review backlog
  • work ahead of the current Sprint to gather requirements for up to 3 sprints ahead
  • work with Stakeholders in answering questions
  • perform analysis as needed which may involve creating database queries and looking at code
  • perform QA as needed
  • fill in as PO or SM as needed
  • perform data maintenance as needed
  • translate requirements to the development throughout the Sprint
Go around the room and tell us what title you have:
  • Analyst
  • Business Analyst
  • Systems Analyst
  • Business Systems Analysts
Go around the room and tell us who do you report to:
  • some report to the Business
  • some report to IT
There were 21 people at this session, including Analysts, Product Owners, and Scrum Masters.  This topic brought about much participation and discussion as people raised questions and talked about their experiences.


Topic Title: DevOps

Initiator: Gary Hernon

Participants: Thomas Banea, Jared Porcenalum, Jennifer Mollitor, Sheetal Agashe, Knud Hansen, Justin Hirta, Connie Pope, Monica Hernandez, Matt Warner, Gary Hernon

Discussion Highlights:
To be agile there is a real need for continuous integration and deployment.
DevOps is a mentality, not a person
Feature toggle can be used to deploy small features until they can be turned on for a release.
Keep doing what is painful, until it is no longer painful.
Always be releasing!