Tuesday, November 22, 2016

Session notes - What to do for AOF2017

Shared a little bit of history
- 2014 and 2015 in Tampa at Valpak
- 2016 moved to Orlando and intend to have in Orlando a second year
- then see if we can move to another city

We are considering holding it with Agile Coach Camp (ACCUS) where AOF will be on Friday and then ACCUS will be Saturday/Sunday
- or we could have a games day or a games track (like Give Thanks for Scrum)

Appeal of AOF?
- The honesty of the people involved
- We know we can "suck together" - we realize we are all having the same struggles and can learn from each other.

Graduated Ticket Sales - Another idea (from Give Thanks for Scrum)
- longer you wait, the more expensive you get
- the people who buy early are the most passionate about attending; give them the cheapest rate
- have rate go up every 2-3 weeks

Other ideas?
- should we have some scheduled sessions?
- should we continue with inside and outside sessions (seemed to be appealing for many)

As we get bigger, what should we consider?
- should we get bigger?
- get those engaged who normally would not in the community
- adding more diversity to the event
- in surveys: What brought you here for the first time?
- focus on some different themes: agile beyond software, agile for life, scrum for hardware, agile for the rest of us
- how to help adoption where they are

Monday, November 21, 2016

Subject: Agile for Maintenance Projects

Problems / Challenges

Direct Solutions to Listed Problems / Challenges

General Solutions

Developer Enthusiasm


The work is boring

(find out why it's boring and discover what holds interest … )

Even the term "Technical Debt" is negative

(don't call it that … )

It seems like a marathon of never ending tasks

(see "innovation Sprint" … )

For backend fixes, a lot of what the team works on can't be easily demo'd 


Developers can't see the shiny new thing they just built


The organization can't see it as well as a new feature build 


The organization thinks of the developers as "Resources" and treats them as such, rather than as "People"

Let teams be more empowered, and let them make some more of their own decisions

Quarterly "Innovation Sprint"

Team Ownership -- they get to decide what to work on

Development team gets to provide creative input

Depends on which of the two kinds of Maintenance work you are talking about: 


1. Here and Now Bugs Fixes

Use Kanban

2. Planned Maintenance

Use Scrum (teams can commit and deliver increments)

Example of something that works for one organization: the developers who maintain the system use Kanban, along with a Scrum (Scrumban). They plan 2-week Sprints with all the normal Scrum ceremonies including Retrospective. They also plan a % of capacity within the Sprint to be used for "unplanned work" (e.g., bugs). The Scrum part is for the planned maintenance. The Kanban board is for unplanned work. New bugs come in and team members pull in whatever work they want. They limit to the capacity that was planned for that Sprint.

Switching Resources from one project to another

It's about how well the PEOPLE work together (to be successful)


Every time you swap out peope from one team to another, the new team has to go through "storming, norming, forming" cycle again


Don't call them "Resources"

The Core System is out of our control

Embedding -- Have the Vendor work on-site with you

Example: a vendor system needs integration, but there are dependencies, and delays while waiting for components to be ready


Example: a vendor system has a bug that impacts a system we need to maintain, and it's not easy to determine the source


Re-work due to delay, and slow progress (need to re-test)


Friday, November 18, 2016

Topic Title: SAFe

Initiator: Robert Kinnerfelt

Note taker: Stephanie Allen

Participants: Farrah, Sam Falco, Timothy Breckman, Stephanie Allen

Discussion / Key Concepts / Quotes / Revelations / Highlights
Brief overview of Scaled Agile Framework.
  • Larger organizations and programs of 60-120 ppl
  • Program level consists of teams, product management and different delivery functionalities
  • Valuestream level scales product management work on a higher level
  • One valuestream can have many programs
  • Portfolio level manages strategic themes and organizes valuestreams and programs
The concept of SAFe is systems thinking, lean principles and agile mentality.
Big plannings/PI plannings are large sessions where the entire program plans the next increment of 5-8 sprints normally.
In the end of a Program Increment (PI) there is a Innovation and Planning sprint where teams do innovative work and key players prepare planning event.

Reccomendations / Next Steps / Actions

Learn that SAFe is not devils invention. Use SAFe as a bootsrap framework to implement agile and lean methodologies and mindsets in the entire organization.
Train yourselves before deciding on wherther you want to go there..
Initiator: Nick

Note taker: Lakshmi Ramaseshan

Participants: 6-7 members

Discussion / Key Concepts / Quotes / Revelations / Highlights

 How do you track & estimate business value?
  1. How does a Management Team estimate business value? What models do you use for estimating?
  2. When developing new strategies or build on existing strategies having a business case is important
  3. Project Canvas or Lean Canvas is a simple way to understand the purpose/ROI of a project
  4. Measurable Success is important
  5. Having Stakeholders estimate bus. value using T-shirt sizing is appropriate just like developers estimate stories
  6. Relative Sizing/Estimating & having a baseline is a good way to bring about consistency with values over time
  7. It's helpful for developers to know the value of a feature
  8. OKRs are a good way to start
  9. Doing Earned value vs. Traditional Cost/Value Mtg can be used
  10. SMEs are not the best estimator of value - it's important to have them engage in conversations which not only determines value of an Epic/Feature, but also the Opportunity Cost of not being able to get it to Market at a certain time
  11. Build or Buy Decisions typically have a Business Value incorporated into the process since it's the starting point of trying to figure out whether a team would build or buy
  12. Executive Dashboard like Valpak is the ideal = Encourage Your company or Team to take a Tour (Contact Stephanie Davis)

Recommendations / Next Steps / Actions

Management 3.0

Title:  Management 3.0

Initiator:  Robert Kinnerfelt

Note taker:  George Spantidakis

Participants:  George Spantidakis, Mike Glasney, Anitra Pavka, Suzy Jackson, Anjali Leon, Dottye Steward, Dan Crowley, Adam Ulery, Ken Nordquist, Josh Fruit, Jason Knocks, Alexis Martin, Joshua Fiscent,


3 Books Available by Jurgen Appelo

  1. Management 3.0
  2. How to Change the World
  3. The Workout Book
Website:   http://www.management30.com

2 Day Workshop Available with Free 2 hour preview to companies
Workout - toolbox of 20 techniques that can be applied to organizations.

Management 3.0 Contains Different Stages of Environment

  1. Built to make people understand how to manage a system in a complex environment
  2. How people develop themselves
    • People vs. Artifact Management
    • Agile Shows us how to build the product, but doesn't tell us how to get there.
    • Teams need a brand, name, or logo to give identity
    • Identities energize people
      • Make people part of something they can build or change
  3. What have functional managers done to make teams feel ownership or go "cool" ?
  4. Knowing WHY you are doing something is energizing
  5. Delegation empowers and energizes (Tools exist such as delegation boards)
Primary Concepts of Managment 3.0:

Empowering Teams
  1. Share clear vision and objective
  2. Trust
    • Built by asking for help
    • Providing Safe environment - OK to fail
    • Let teams solve problems
  3. Lead the Chaos for team to become autonomous

Align Constraints:
  1. Manage Outer Boundaries of playing field
    1. Be Transparent
    2. Manage Objectives
Develop Competence:
  1. Manager's Responsibilities
    1. Agree on direction to move
    2. Can team satisfy direction ?
  2. It's HOW we do it that's essential
Grow Structure:
  1. Any system is driven by culture
    • Communication Channels
    • Information Letters
    • Weekly Meetings
  2. Easy to say that Agile teams are autonomous
    • Teach oursevles within organization
    • Breeding reductionism
    • Acknowledge that Tree is a trellis that can allow an organization to grow organically
  3. Pathway to Nirvana of compensation
    • Kudo Cards
    • "Cheers for Peers"
    • Day Off buttons
    • Impact Testimonial by customer
  4. Treat everyone as team members (FTE's + Contractors)
  5. Look for ways to build community with remote or geographically disbursed teams
    • Personas (Hobbies, photos, about me) to humanize team members
    • Have remote employees go first in standup meetings
Improve Everything:

  1. Continuously
  2. New course material for Management 3.0 has removed Agile and has shifted to contemporary
Differntiators of Management 3.0:

  1. Branding
  2. Guilds -   1 hour of work per week that leads to several hours of efficiency
  3. Parallel (Scaled) Agile and Management 3.0 are a good fit with each other
    • A bootstrap to expand
    • Answers to everyday issues
  4. Personal Maps
    • A tool to get teams to know each other

Telecommuting tools

Initiator/note taker: Vlad Filippov (Valpak)

Discussion / Key Concepts / Quotes / Revelations / Highlights

Challenges of telecommuting in Agile teams.

Recommendations / Next Steps / Actions

List of tools for team communication:

1. Lync / Skype / Skype for Business.
2. Slack.
3. WebEx.
4. Zoom.
5. Google Hangouts.
6. Blue Jeans.
7. Sococo.
8. Bria (VoIP client).

Life After Agile

Initiator:Leon Sarbarsky

Note taker: Salena Vitkovic

Participants: Rene, Travis, Susan, Jeff, Jill, Leon, Bryan, Ed, Mark, Farrah, Stephanie

Discussion / Key Concepts / Quotes / Revelations / Highlights

  • What will Agile coaches look like? Constantly Teaching
  • AI
  • Embrace Global Warming - Tech Opportunity
  • VR Agile Coach
  • Cognitive Computing - Developers
  • Bots - Deep Learning
  • Agile Genetics - (DNA)
  • Higher Programming Languages - There are 13 languages in the tech stack and to do this you have to go through this and to get to this you are required to do this...
  • Will languages be fighting it out? Go, Swift...
  • NO UI - Amazon Echo, Alexa, Google, Siri, Raspberry Pi
    • UI Moving to glass technology - ex. Teleprescence
  • Loyal to Service and not a company
  • Watson - IBM Controls your mind
  • Robotic Development - speak natural development
  • Would you put a chip in your head? Does it depend on what it can do for you?  Would you be willing to be a BETA for the greater good?
  • In a society of instant gratification Emotional Quotient/Intelligence value will go up.  The ability to demonstrate self-control will be a differentiator
  • Elder Care - Would be a hot market as people live longer, the technology/health care business value will be tremendous
  • Other possibility - will society/humanity take a step back and back off technology and move to more human interactions, because as we are freed up from day to day chores, higher order thinking will prevail and the drive for understanding and relationships will be the highest priority.


Recommendations / Next Steps / Actions
Initiator:Christina Alonso

Note taker: Christina Alonso


Discussion / Key Concepts / Quotes / Revelations / Highlights

 What are some great Ice Breaker ideas?

Recommendations / Next Steps / Actions

Main points:

  • Ice Breakers can flop. Ex. Star Wars exercise.
  • Don't assume people know movies, etc.?
  • Take culture into consideration when you are planning/selecting an ice breaker
  • If you can, learn about your team members and leverage that when selecting an ice breaker.
  • Ice Breakers don't always have to be "happy." They can be deep and thought provoking.
  • Ask open-ended questions to open up discussion.

Ice Breaker Ideas

  • Everyone shares a fun fact about themselves
  • Everyone states their moods in terms of the weather. i.e. sunny, cloudy, etc.
  • Everyone says 2 truths and 1 lie about themselves. The others try to determine which one is the lie.
  • Ask everyone to share: What animal would you be? (You can change animal to anything else you want.)
  • Bananagram using Agile terms
  • Marshmallow Challenge
  • Untangle
    • Line people up and have them all lift their right arms and reach over and grab someone else's right hand. Then have then lift their left arms and grab a different person's left hand. Now, they untangle themselves. You can time them and do it several times.
  • Do the Wave (like the wave done at a sporting event).
  • Have everyone create a mindmap of themselves and then share it with the others.
    • You can create mindmaps using: work, home, vales, where do you live?, and family
  • Rock/Paper/Scissors
  • Mafia Game
  • Create teams of 3. 2 people look at the 1 and infer as much information about the person just by looking at them.
  • If you have virtual teams, you can: share a common trait you all my share and talk about it. ex. food
  • What did you want to be when you were 5 yrs. old?

Resources you can use to learn about other Ice Breakers:

  • Managing For Happiness (Book)
  • Tastycupcakes.org
  • Try to look up "Summer Camp games" for kids. You would be surprised at learn that some games can be used.
Topic Title: AOF 2017

Initiator:  Mark Kilby

Note taker: John Scalzo

Participants: Several...

Discussion / Key Concepts / Quotes / Revelations / Highlights

Where will it be?  - Likely Orlando...usually moves every 2 years.

Attendees:  where are they from?  25% Orlando area, many from Tampa.  Analyze attendance to get the specific breakdown.

Information available:  AOF 2016 proceedings available online during the conf, compiled into a book format later.  Other Agile info/case studies available from sponsor sites such as AgileThought

Format:  new attendee expressed great satisfaction with the open format.  Others described the sessions facilitated "honest" communication on Agile topics and issues.

Agile games?  Suggestion to integrate some, it will depend on the facilities available.

Combine with Agile Coach Camp?  Make a weekend of it - Friday AOF2017, Sat & Sun Coach Camp.  Maybe integrate also an Agile Improv.

What will get "new" people here?  Advertise that its not only for Developers, include references to implementations by "real people" and that the conf will include those topics.
Other ways to appeal to non-IT Agile implementors?


Reccomendations / Next Steps / Actions
Topic Title:Dev Ops

Initiator:Hung Chen



Discussion/Key Concepts/Quotes/Revelations/Highlights

  •  Getting everyone together to work on one thing
  • DevOps originated with the cloud
  • Developers would push to the cloub, but standards were weak
  • docker makes it easier to deploy to many different place and the pipeline will be the same
  • Writing and deploying applications
  • PAAS vs Container solutions
    • Containers are "hot new" idea
    • Platform agnostic
    • Platforms lock you into vendors
  • Docker VS Chef VS Puppet
    • Docker is a container
    • Chef installs into OS
  • Documenation vs Code Docs
    • Some want documentation written
    • Level of documentation is flexible based on team knowledge needs
  • DevOps (tools vs culture)
    • How do you consider culture vs tools?
    • DevOps is to move away from siloed teams
    • Everyone needs to understand the tools/flow so tnot one person is responsible
  • What recommendations do you have to move a team to devops?
    • Get upper management buy-ins
    • There are advantages to make it easier to sell
    • there are day-long devops groups you can play to illustrate the point
      • Scripted events development and ops vs devops
  • Modularization can help containerize
    • Going from older system to containerized can be difficult
    • Better to try containerization on a new project
  • Traditional Vs Devops
    • Traditional is more siloed
    • create unnecessary blocks in the process
    • monitoring is important get getting feedback
  • CI - continuous integration
  • Quatliy First
  • Chaos Engineering (Chaos monkey from Netflix)
    • Developers think "How will this work in production?"
    • Devs responsible for fixing things
  • Monitoring Programs
    • Splunk
    • Sumo logic
    • AppDynamics
    • Application Insights
    • Dynatrace
    • sysdig
    • graphite/statsd
  • Reduce cycle time between events (site down) to the fix (site back up)
  • test early and often
  • feature flags + A/B testing

Life After Agile (AGILE LIFE)

  • What are you thinking about after Agile?
    • AI (West World)
    • Millennial running the world
    • Embrace Global Warming
    • True Virtual Agile Coach
    • Agile Genetics
      • Inject Agile principles into a person's DNA
      • Nurture vs. Nature
    • BOTs (clone development teams)
    • Agile is a higher level programming language 
      • So many languages are lower level that rolls up to a new higher level
    • No UI
      • Amazon Echo with RasberryPi
      • Glass technology
      • Speaking face to face with virtual device
    • Connect with your mind
      • Watson interface with your brain
    • No more waiting! (Millennials)
    • EQ (Emotional Intelligence)
      • Are we going to have more isolation?
      • Will there be a time when we don't talk to people?
      • Will you seek people who agree with you because so easy to find them and then ignore disagreement?
    • Is your best friend going to be a computer?
    • Maybe technology will pick up all of our work and people will not have to work and therefore will have more time for personal time, relationships and more social interaction.  This would be a complete full cycle turn back to a more social society.
    • Eldercare 
      • Put a chip in your body to administer medication
      • Identify diseases and cure before you
      • know them
      • Older aged people population explodes
    • When does our smart phone go away?
      • Will we have a smartphone in our head?
      • Lens in our eye
    • Future of security 
      • Look at 500 elements of you with biometrics (how you turn your head) - behavioral DNA

Evernote helps you remember everything and get organized effortlessly. Download Evernote.

Session 5: Integrating User Testing/User Research capability into cross-functional Agile development teams

Initiator: Daniel Hettrick
Note taker:

Discussion / Key Concepts / Quotes / Revelations / Highlights

  • Development Team is responsible for executing product vision
    • starts with high-level design (designer's mental model of how product/service will be used/experienced by end-user)
    • may involve creating "personas" which are representative of core demographic
    • Problem: traditionally, users are not engaged until late in development life-cycle
      • e.g. tweaks before launch OR A/B testing of final UI design
      • this is more a validation approach than an iterative design and development approach
  • User Testing/User Research domain encompasses multiple concepts and numerous types of testing including (but not limited to):
    • Usability Testing (identifies inconsistencies in UI design, differences in designers and users mental models, etc.)
      • Is critically important to do this as early as possible in development cycle
      • Can be done with small batches of users (~6), expert or heuristic evaluation
      • Seeking to quantitatively identify "Gulfs or Execution" or "Gulfs of Evaluation" where the user either did not know how to perform an action they wanted or could not understand what they were supposed to do next
    • "Playtesting" for entertainment products/experiences is similar to Usability Testing, but focuses on subjective engagement (how did the user feel) rather than the more quantitative focus of Usability Testing 
    • User Acceptance Testing (UAT) defines threshold criteria for success of key interactions
      • Using a development approach like ATDD (Acceptance Test Driven Development) may help to ensure team's focus remains on critical user interactions
      • This type of testing may be requirement for items being considered "DONE"

Recommendation / Next Steps / Actions
  • Advocate for creating shorter feedback loops between users/customers and development teams
    • Feedback early and often!
  • Embed User Testing skills within team (hire them or train some team members in User Testing design and facilitation)
  • Utilize resources such as
    • Online resources:
      • Usability Hub
      • usertesting.com
    • Consider engaging 3rd party companies such as WAC Research and Key Lime Interactive in FL to help structure, design, and facilitate user testing
  • Consider cultivating a database of testing candidates across multiple demographics to help ensure your tests get fresh insight (do not rely on convenience samples) 
  • Consider adopting ATDD or Behavior Driven Development (BDD) / Specification by Example to align the team's focus with system response to key customer interactions

Coaching Product Owner Teams - Tips, Techniques, etc.

Topic:  Coaching Product Owner Teams - Tips, Techniques, etc.

Facilitator:  Louis Torres - HSN

Discussion Notes:

* Be effective more than efficient
* List PO responsibility and present to the PO team
* Have PO's create a kanban board for their backlog items - 25% ready, 50% ready, 75% ready, etc.
* Don't take/allow stories that aren't 'Ready'
* Have strong Scrum Master interaction
* Add some metrics for stories that are missing information - what percentage of stories are not 'Ready'
* As a Coach, be a co-product owner until Agile behaviors are natural
* Have a PO that is performing Agile techniques well show other PO's
* Find/develop an Agile Champion within the PO group
* Encourage rapid brainstorming/add-on grooming sessions
* Have PO provide a daily dedicated 'Team Time'
* Have PO's do 2 grooming sessions per sprint, one at the beginning of the sprint focusing on large Feature stories needed down the road (2-3 sprints away), the other grooming session near the end of the sprint to groom stories coming soon.

Filling in the gap between self managing teams and traditional management

Initiator and Notetaker - Michelle Michael

Participants (some) Suzanne Daigle, Michael Okneski, Mark Hernandez,

Discussion/Key concepts

Self managing teams are high performing, don't need basic coaching, pro-active not reactive, engaged, highly communicative, adaptive leadership, set measurable goals, willing to take on any role, mentor each other , asks the right questions and push back appropriately.

Accountability has to become everyone's responsibility

PO doesn't become a bottleneck .  Have transparency with stakeholder

Separation between organizational management and administrative management

Conflict resolution resolved internally

Management and PO need to let go of control and let the team decide how to do the work,

Team has choice to decide how to do the work..freedom and choice

Business should focus on WHAT needs to be done

Value the skills/capabilities of individual team members

Mentoring each other gives all teams members a chance to work on the 'cool' technology.

Use cross-training and rotation so that teams don't get stale.  Beware of 'click' culture that might build.

' No one can exert control over another..Team members are accountable to each other


Research the filtering of applications for 'practical intelligence'

Apply some knowledge/best practices learned and link up/connect with others in the group

Tools Agile Blessing or Agile Devil

Initiator: Jens Ostergaard
Note taker: Jens Ostergaard

Session started with Jens explaining what he meant by the topic and that he wanted to focus project management tools.

Thereafter the group discussed and listed reasons why tools are positive and why they can be negative

Positive            Negative

Visibility          Does not fit needs
Audit                Trail Time Consuming
Notification     Impact Transparency
Integration        TME
Flexibility         Integration
Configurable    Flexibility
Metrics             Configurable
Savings            Metrics

We concluded that many of the things could be both positive and negative depending on the organization.

We the moved on to discuss what it meant to be forced to use a Tool

Positive                           Negative

Consistency                     Frustrating
Audit                               Lose creativity
Excited to Learn Tool     More time Updating
One Stop Shop                Loss of Motivation
                                        Creates more Process

We then concluded some things that can be valuable if you want to use a tool

Good for large organizations
Has to be the right tool
Mold tool to your organization, nit the other way
Involve end users
Feedback internally
Process way more important than tool
Get a tool team
Do research
Team flexibility in collection data for tool





Product Owner Domain vs Product Manager

Initiator: Farrah Miller
Note taker: same

Discussion / Key Concepts / Quotes / Revelations / Highlights
Product Owner Domain vs Product Manager
Complex large scenario, multiple product lines and teams

Recommendation / Next Steps / Actions
General setup is one product manager with multiple PO's.

Product Manager is responsible for Product vision and should supply a "one page" vision writeup for the PO to share with the team. Like Roman Pichler's product canvas. Team should get to see the vision. Creates and shares value proposition with PO.

PM also creates roadmap. Also create high level Epics/features they would like to see built with high level acceptance criteria.

PO should be brought into understand the roadmap at some point and be able to weigh in and build release plan.

If a business problem arises unplanned, the PM should include PO and analyze and scope/request to team to help solve.

The PO
Multiple POs might work under one PM.
PO - Owns the backlog, gets to prioritize the level below features and how to break down features and order work. They are responsible to bring the value proposition down to the team.

In a complex scenario with large volume and multiple PO's, the work needs to be split. There is not a clear way to do this. Maybe by application, product line or depending on skill set of each PO.

Tools agile blessing agile devil

Why is core agile so difficult

Why is Core Agile so Difficult

Initiator: Jens Ostergaard
Note taker: Darlene Pike

Session started with Jens explaining what he meant by the topic and used the ScrumGuide as an example.
Thereafter the group discussed and listed reasons why it is difficult. From that we voted and this is the Top 3 reasons why it is difficult to do core Agile.
  • Trust
  • Change
  • Fear
    We then took on the challenge of solving the top 3 reasons. Using the same process we again discussed and listed reasons to gain TRUST, and then prioritise.
  • Deliver Value
  • Shared Responsibility
  • Empowerment
    Moving on we did the same with CHANGE with the following result
  • Experiment
  • Reward – Benefit
  • Tiny change – Kaizen mind
    And finally for FEAR
  • Just Do It – Try
  • Celebrate Success
  • Training


    What are some techniques for retrospectives for dysfunctional teams?

    Initiator: Catherine Peck-Phillips
    Note taker:  Christina Alonso

    Discussion / Key Concepts / Quotes / Revelations / Highlights
    • The dysfunction
      • Dev teams are more interested or committed than other teams.
      • Transparency is important.
      • Some team members have a fear of process.
      • People use buzz words, but are not really doing "it"
      • Things get discussed at retro, but it doesn't get resolved.  Problems keep coming up retro after retro.
    • Metrics can be good, but stay in tuned with how they react to metrics.  If they like it, great!  If not, use pictures or some other way to inform them w/o making the team feel bad/
    • Know your team!!  Learn what they respond well to.
    • There are certain issues that should be addressed outside of retro--perhaps by the coach or manager only.
    • Resources
      • Retro wiki
      • Tastycupcakes.org
      • Strengthfinder assessment
      • Belbin (role based assessment)
      • Myers Briggs personality assessment
      • The Ideal Team Player (book by Patrick Lencioni)

    Recommendations / Next Steps / Actions

    • Things to keep in mind for Retros
      • Create action items and assign them to someone (Scrum Master)
      • Ensure there is actual value in the meetings
      • Make retros anonymous.  Let the environment be safe!
      • Team should select what they want to discuss or to find a solution for.
      • Mix up exercises to help the discussion and improve conversation.
      • Make sure to stay focused on the topic being discussed...and timebox discussions to ensure all ideas are covered.
      • Make time not just to complain, but to find a solution.
      • Create list of impediments throughout the sprint, so you don't forget them/
      • Have someone record all good/bad things that happen in order to ensure that the "bad" things are also discussed.
      • Review team improvements
      • Let the team lead the discussion.
      • Show data when Possible
      • Establish groundrules for the retro before the meeting starts. (technology down)
    • Retro techniques
      • Use tastycupcakes.org for retro ideas.
      • Take a walk, talk to someone new
      • Try "escape rooms"
      • Win, lose, or draw game
      • Have teams draw how they felt throughout the sprint, and review with team
      • Massage table--"massage" out issues
      • The team must follow through with action items.

    Using Agile Coaching as a Scrum Master

    Note taker: Alison Ramoy

    Discussion / Key Concepts / Quotes / Revelations / Highlights
    Good Times to Coach:
    -Ad hoc if possible. There is no need to wait.
    -Retrospectives at the end of a sprint.
    -Retrospectives on a specific topic.
    -Weekly alignment meetings with POs.
    -At refinement sessions. Get comfortable with the unknown.
    -More frequently with new teams, but mature teams need coaching too. 

    Good Coaching Techniques:
    -Teach (coach) teams to solve their own problems.
    -Ask powerful questions.
    -Substitute terminology for what the team is comfortable with.
    -Don't invalidate their previous experiences and successes by telling them how they used to do something (Waterfall) is wrong.
    -Use positive terminology (BEST that can happen vs, WORST that can happen)
    -It's about us vs. you alone
    -Reward system-snacks, lunch, fun activities
    -Competition as a motivator
    -Coach to change habits for self-improvement

    Recommendations / Next Steps / Actions
    Read Coaching Agile Teams by Lyssa Adkins

    When you're a change agent, coaching transformation, how do you recharge your batteries?

    Initiator: Nicole Travis
    Note taker: Heidi Araya
    Participants: Lori Townsend, Cristin Hernandez, Nirakar Saha, Shasidhar Kalahasti, Jason Nocly, Michael McGreey, Camille Guy, Ivonne Woodruff

    Discussion / Key Concepts / Quotes / Revelations / Highlights
    How to recharge if you're the agile champion/change agent.  Phone-a-friend, Meditate, Be healthy (mind, body, soul).  Ask yourself why is this important to me?  Be the best Scrum Master ever.  Keep perspective.  Identify your "why."  Understand who you are and your characteristics to recharge, introverts unplug and extroverts go out and socialize.  Seek learning, take a class/webinar or read a book.  Keeping people motivated.  If change is not possible, what then?

    Recommendations / Next Steps / Actions
    6 item checklist to recharge yourself:

    1. Get involved in the Agile community
    2. Treat yourself well
    3. "Reflectrospect"
    4. Take a step back, assess the big picture
    5. Sharpen your saw, add to your toolkit
    6. Consider an exit strategy

    Offshore Contracl Model is Agile

    Initiator: Sushil Bhattachan
    Note taker: Sushil Bhattachan
    Participants: 8

    Discussion / Key Concepts / Quotes / Revelations / Highlights
    Discussed about offshore contract model to better engage offshore team .

    1. It was agreed that as we move from waterfall to agile its even more important to have motivated offshore team members as we give more autonomy to offshore teams. And if team members are not motivated it could make productivity worse than water fall.
    2. In T&M contract model offshore management do not have high interest to motivate team to provide higher productivity and higher quality cause all they care is no of people are hired by their client. Offshore management mentioned that they have to pay more to keep people for multiple years in the same project as in T&M onshore client wants to keep same person for long. However they mentioned though they keep people for long by paying more the team members are disengaged being in same client company for long.  So they do not have leverage to bring new people as new people are more engaged for few early years. And they want a way to pay by performance rather than no of people and higher pay for retention of an employee. Fixed cost would be better but with Agile we can not do that as well.
    3. So we brain stormed to see if we can help change the contract model from T&M to something more incentive based so that offshore management is engaged to motivate their employees better.
    4. Topics we brain stormed with team.
    4.1 Penalty for not meeting SLA
    4.2 Reward for meeting sprint goals.
    4.3 Pay by velocity or incentive by higher velocity with base payment.
    4.4 Measure output by person.
    5. However we did not find good agile way to change the contract.

    Recommendations / Next Steps / Actions

    As we discussed many ways, we could not find good agile way to amend the contract. And team decided that it is really not contract issue, rather an engagement issue. And trying to amend contract might not help. So here are some recommendation to engage offshore team.
    1. Have Tech lead/ Proxy PO in Offshore team.
    2. Have complete team in offshore;  do not mix and match.
    3. Offshore team in one location.
    4. Use communication tool like Mumble, Discord etc.
    5. Incentive to onshore incharge for better output from offshore.
    6. Onshore team value work completed by offshore, that's where the main engagement energizer.
    7. Make offshore team provide full transparency of what they worked and how much they complete each day.
    8. Share vision from onshore executive to offshore team and make them feel part of the team. And not just once a quarter.Over market the vision.

    How Do You Integrate Web Design into the Scrum Framework?

    This session focused on how to incorporate the UI design work into the development scrum process and facilitate better communication and efficiency.

    Suggestions included:

    1. Have UX & Design spike stories within sprint
    2. QA approve acceptance criteria at the beginning of the sprint & Designer approve UX at the end of the sprint.
    3. Develop first then refine with the designer
    4. Dependency management is the key to building efficiency and collaboration between design and development
    5. Use SLACK (web app) for development team to collaborate and share their work with the design team during sprints
    6. Identify the core design elements needed by the development team at the beginning of the project - this will be the focus work for the design team
    7. Design lo-fidelity comps then hand off to the development team to build
    8. Work in 5-day Design Sprints then hand off to development team to build
    Agile Manifesto 2.0 - shall we slay the sacred cow?

    15 people

    Initiator and Scribe: 
    Curtis Michelson

    Session Notes:
    (see photos of white board)

    Conversation Outtakes:

    - we started with a collective "moo" sound, and we spoke with appropriate reverence about the "forefathers" who brought us the manifesto.  Acknowledging that what they created has remained relevant and powerful all these years (15 now?) and also realizing that the world they were speaking to (waterfall software development) has largely changed or dissolved. Today, the agile battleground moves to Management and into disciplines outside business per se; such as, education, government, science research, etc.

    - As a refresher, we reviewed the current manifesto and principles, then asked what about 'software' is hardwired into this document, and what would we need to change to remove that?
    Focused on,  "developer" becoming "innovator" or "creator".  And software becoming "realized business value".   In the principles we changed "technical excellence" into "excellent craftsmanship" or "high performance".

    - someone noted that there is aready a new manifestation of A.M. called 'modern agile'.  www.modernagile.org

    - they have a beautiful circular graphic that focuses on four synergistic principles:  "Make people awesome", "Experiment & Learn Rapidly", "Make Safety A Prerequisite", and "Deliver Value Continuously"

    - Curtis then introduced an "acceptance criteria" for the effectiveness of this new less software specific version:  "we should be able to speak the native language of anyone in organizations - school administrators, government beaurocrats, teachers, preachers, whoever works collaboratively to deliver value to a community.

    - As a "test" we focused on "Education".  Interestingly, some people have already begun to do this, and have taken agile principles into K-12 schools.  One woman said their company had 'adopted' a school and was actively working with them to bring kanbans into classrooms.  Others said it would be asesome to have "visibility" even into a classroom. Imagine a trello board that all parents could access and a backlog of items that teachers and students 'pull' from.  Whoah!  Others have already brought agile principles into their homes. One woman said they have a scrum board for the house which she calls the "vision board".

    - in the retrospective, everyone came away energized to take agile outside IT and to find places in their community to introduce the potential for greater goods that come from it.

    Create sustainability with trust in innovation

    Initiator: Robert Kinnerfelt
    Notetaker: Rene Clayton
    Participants!2 people, Parker, Rene, Justin, Margret, Tabith, Bhavini

    Discussions Key concepts
    How do you innovate.

    Innovation in tech teams:
    • Innovation sprints
    • Involvment in product definition
    • Delegation & Empowerment
    • Structured slack: Prioritizing the top 2 thirds of the BL for each sprint, and leave the rest of the sprint for innovations on refining the solutions. Live by "the amount of work not done is essential"
    Innovation on Product strategy
    Product management, product owners, receivers?users

    Use the same mentality as a team would. Look at the MVP and create a slack where you can plan new features that have evolved during the last couple of sprints.

    So how do we get there?

    Force the experiment
    Understand the business value
    Start prioritizing harder.
    Slim down your sprint backlog after the planning

    Solutions to remote work challenges

    Solutions to remote work challenges.

    Non-verbal communications missing
    • use web cam
    • use conference rooms where people present can read the body language of others in the conference room and add color/interpretations to words
    • have in-presence (everyone in the same place) team building activities to bond as a team so member understand each other better
    Why do we have remote workers?
    • available skill pool is increased
    • have people close to physical resources such as servers/data centers
    • better, more convenient time zone coverage
    How do we create presence for remote workers?
    • have remote workers create a compelling work space for themselves
    • create effective feedback loop for remote workers
    • bring team together physically for team building activities
    • establish continuous presence between remote workers and co-located workers
    • let remote workers share weather of local items of interest during stand-ups for connection purposes
    • encourage people to be who they are, to be authentic

    Sustainable Middle Management!

    Initiator: Robert Kinnerfelt
    Notetaker: Sarah Urriste
    Participants: Alvin Providence, Becky Herman, Prashanth, Jens Ostergaard, Wendy, Ivy, Anjali, Michelle Mitchell

    Collaboration Area: Ripen
    The problem is management starting as POs and SMs when a company moves to agile
    Participant: We're finding that another problem is PMs and Managers impeding the agile transformation because they have the most to lose
    Questions posed: Do we need middle management? Who is defined as middle management?

    Robert proposes that there should be Artifact Management and People Management

    Artifact Management: Anything you can put on a board and prioritize. The following people should perform artifact management:
    • Product Owner
    • Project Manager: Manage communication between teams and dependencies
    • Program Manager
    • Technical Lead
    • System Architect
    • UX Management
    • Requirements Mgmt
    • Release Management
    • Content Mgmt
    • Configuration Mgmt
    People Management: Manage the environment so people can grow and become better at their job. The following people should perform people management.
    • HR Issues
    • Guild Leaders
    • Should SMs be considered mgmt? No. SM should not have a "side"
    • This person has reportees?
    • Should the team self-manage?

    Recommendations/Next Steps

    How to create sustainability with middle management?
    • Training
    • Guild Leadership: Developing the craft & the people in that community (Artifact & People)
    • Find your own place in a scrum team
    • Create/guide the direction people should go
    • Support from upper C-level management
    • Help reports find their role
    • Motivate & Incentivize
    • Manage expectations
    • Coach: Assist in the decision making, but don't make the decisions for people
    Issue: Middle management can be absent and unaware of what's happening with their reports
    Possible Solution: Implement "Guild Leaders" that pop into standups and meetings, meet with their reports to see how things are going, meet with the POs & SMs to have a holistic understanding of how their reports are doing on the Scrum team

    Middle management should manage dependencies between different departments

    Making Sprint Demos exciting and productive

    Initiator: Kenneth Dick -Valpak

    Invite Everyone?
    Performing Demos by team benefits
    --Only certain stakeholders attend
    -- People that attend ask questions
    -- Actively connecting QA with stakeholders creates value
    -- QA aren't as interested in sprint Demo because they have seen it all sprint

    Conversation ideas
    -- Demo length is important
    -- The person who worked on it is the best person to present it.
    -- Everyone should have a business perspective for Demos
    -- Inclusive presentations give the team pride in their work and visibility to leaders
    -- Product owners should market sprint demo contents to stakeholders
    -- Support development time described using theme groups help communicate to leaders
    -- Sprint theme can be important when the theme equals the most important business deliverable
    -- Listeners don't always care about sprint themes unless it helps communication or is FUN
    -- Free food! People pay more attention out of gratitude
    -- Demos can be your last line of defense against faulty product delivery to customers
    -- Attendance rises with webex/other digital delivery

    Demo Slides Content Consensus
    -- What problem did you solve?
    -- Who did the fix?
    -- One screen visual summarys
    -- Major GUI designs planned for next sprint

    Cultivating KANBAN, Kanban vs. Scrum

    Topic Title: Cultivating KANBAN, Kanban vs. Scrum
    Initiator: Sarah Urriste - HealthSystems
    Note Taker: Reid Manchester

    Mary Carleton, William Davis, Asif Haque, Allison Ramoy, George Spanti..., Vicky Braun, Dan Crowley


    • Scrum struggle was that staff would sometimes be idle, stories would be too large, teams could not agree on points for features.

    Recommendations/Next Steps/Actions:

    • Velocity is measured in points delivered per sprint. This can still be used in kanban.
    • Still use refinement session in an ad-hoc fashion
    • Do hold retrospectives, but less process orientation and more of a team-building and prep for the upcoming sprint cycle
    • Still use a scrum/flow master
    • Implement a WIP limit. Some team members will resist sharing their WIP load for fear of receiving more work, but press them to communicate, don't let them get away with it
    • Some teams may find value in running Kanban within Kanban, further breaking up their work within the lane. 
    • It's still valuable to measure and track cycle time, to see that points delivered goes up or down and how long it takes to deliver that value
    • Ensure that WIP items being reported by the team are truly In Progress. If it's not being worked on right after the stand-up meeting, it's not In Progress. Falsely reporting items as IP creates waste and prevents others from working on that item
    • Use a Bi-weekly prioritization process that covers business value delivered and other metrics. Dimensions to be used could be things like: Business Value, standardization, complexity, compliance
    • Use an 'Expedite' lane on the board to cover customer supported tickets, and talk about those tickets first in the stand-up

    Topic: How to do Agile for Hardware Projects

    - Prototype the hardware using pipecleaners and marshmallows
    - Keep the teams doing agile prototyping (MVPs) for hardware and software separate
        - join them later using a Scrum of Scrums approach
    - For factory floor settings, build modular factories with the components of the assembly line reconfigurable.
    - Have the different parts of the manufacturing process work in the same open space in separate teams.
    - Have the testers and QA deal with the physical attributes early, how many times do we have a hotel lamp that is impossible to turn on/off

    Agile Telecommuting

    Telecommuting is not an evil. It can be a necessary part of maintaining a loyal, integrated, engaged team. A Microsoft study has found that fully distributed teams ( all remote workers) are more productive than hybrid distributed/collocated teams.

    Rules for Successful Distributed Agile Teams

    1. Communicate, Communicate, Communicate.
    • Not available? 
    • Issues with workflow?
    • Problems with tasks?
    Notify your team!

    2.Set up time for the team to just hangout. Encourage team members to share personal ideas and talk about non work ideas. They will get to know each other and build team camaraderie.

    3. Use virtual icebreakers. These are 1-2 minute games to reduce tension and increase opportunities for idea sharing.

    4. Try using mind maps to give people an idea of who you are. Each person can list things that is important to them. Sharing these gives the teammembers a way to connect.

    5. Treat your team like adults. If they are producing at an acceptable rate, you do not need to micromanage.

    Good Tools for Agile Telecommuting
    1. Zoom Meetings for video conferencing
    2. Slack for quick notifications and conversations
    3. Appear.in ( free video conferencing)

    Suggested Reading
    Collaborative Superpowers by Lisette Sutherland
    Topic: Modern Agile

    Initiator: Steven Sladoje #TLSS

    Notetaker: Shannon Nacua

    Participants: Mark Cruz, Fred Mastropasqua, Shannon Nacua, Adam Ulery, Christopher Duro, Wendy Vigre, Chase Robinson, Phil Zofrea

    Is Modern Agile being applied to team currently? This is such a new movement that Modern Agile is being applied but only in pockets.
    Modern Agile is a way to bring Agile from software and apply to non IT shops.
    Modern Agile is a 2.0 version of the Agile Manifesto. Modern Agile overlays the Agile Manifesto.
    Modern Agile talking points:
    Making People Awesome: Make the team awesome, make the customer awesome with proving a great product, etc.
    Deliver Value Continuously: Always deliver value of the product.
    Making  Safety a Prerequisite: Let teams voice an idea, is it ok for teams to fail,  a way to grow and experiment, make the customer feel safe by providing a great product, etc.
    Experiment and Learn Rapidly: Teams need new skill, how are they being fed new skills and technology, are we respecting and listening to new ideas no matter where they come from?

    How can I have Agility in non-IT Departments? combined with Agile Beyond Software: It is time to go mainstream?

    Rick Reguieire
    Suzanne Daigle

    Notetakers:  Alison Ramox an d Suzanne Daigle

    Participants: Dorothy Stewart, Christina Alonso, Catherine Peck-Phillips, Stephanie Coleman, Lynn Flannery, Mark Hernandez, Mira Welsh, ? DaSilva, Diana Flores, Curtis Michelson, Alexis Martin, Monique Hacker, Kenneth Ashley, John Long, Josh Fruit, Salena Vitkovic, Alison Ramox, Vicki Braun, Angela Adams

    Initiators describe the "why" behind their topic. 
    Rick indicates he's been with Agile for 6 years, now tasked to work with the business units to take it beyond technology. At the leadership level, often beat to a different drum, can be overwhelming when the organization is not familiar with Agile.  Want to hear lessons learned from others.

    Suzanne: deeply committed to Agile beyond Scrum. Has a business manufacturing background, Sees huge opportunity to bring Agile methodology and thinking to business thinking. Lots of waterfall in management. 

    Participants jump in to describe why they joined this topic:
    Not always receptivity at first, language is unfamiliar, we can appear to be talking above people's head. We need as a people to step back, make it relatable. For example drawing the parallels to waterfall. 

    Valpak rep talks about their company where every team is doing Kanban. "you'd be surprised to see how much people are taking it in" 

    Another individual working in a Fortune 100 company helping the organization transform. Been going slow due to size but describes that the business units are starting to see this as "interesting"; it's gaining traction.  Important to go in with  "invitation", not imposing. Nor should we be going in with solutions, best to get into the pain points and where we can help.  Helpful if we're describing patterns when visualizing the work, give 3-hour sessions. As IT, we have to become more comfortable with the diversity and creativity, to be ok with divergence from how we might be doing it.  Working towards building communities of practice. 

    Mark comes from strictly technology.  In approaching others he suggests 4 approaches to take: 
    1. Create Empathy..show that this can work
    2. Use a common language
    3. Get leadership to buy in
    4. Develop habits, patterns of behaviors, look for opportunities to inject new ways of doing
    The challenge remains with leaders...not being open. To illustrate, one participant mentions telling a VP in a coaching way that people were afraid of him. The response was "Good". 

    A former GE colleague with depth of experience on project management and great convictions around the benefits of Agile was working with a company interacting at the C-suite level as the only female and being told that she is not to talk at the meetings, also being told by the execs in so many words to dummy down her communications.  At a certain point she said, you have to know when to "unhitch your wagon"... she left the company. 

    A participant working in Operations describes how people in that sector have no clue what Agile is. Her approach is to relate it to issues they are experiencing, for example solving a staffing problem.  Also agree to let people come to it on their own terms, to relate it to internal/external pain points 
    Sell Agile by what it can do for them; 

    That said there might be limits to meeting people where they are, These times may call upon us to take a bigger leap.  Another idea is to recruit allies (high performers in the organization, don't necessarily need to go to the top.

    Don't have to go all the way, benefits to going forward with small tweaks, introducing Kanban to start the conversation (so many applications for it). Promote the value of visibility and transparency.

    Take "small win" approaches. It works.  in the Fortune 100 company referred to previously, have seen major change, we're still figuring it out but there is major progress. Expose the wins; adopt and trasnform. 

    Suggestion to use language of "experiment". Choose an issue, ask for a team for 6 months, you're lowering the risk.

    Having skunk teams with diverse members working on projects showing wins can have a huge impact. A more grassroots approach rallying together high performers at different levels of the organization.  Invite younger generation to be the communicators of the success stories. Leaders will be floored and will be impressed especially if these stories can speak the business issues, progress and results. 

    Pay attention to how your work environment looks, to the physical space in your work area. Using your computer on bean bags. Coloring books (helps to make your mind think).  That's what one company did. Did not happen overnight but it's getting noticed.  People will say: what's happening in IT, becomes cool, piques curiosity with people being attracted and asking "What are you guys doing?" 

    Others words of wisdom: 
    There is no end to change.  It's be uncomfortable. What does disruptive change mean? 

    Make friends with folks in IT  - often there's a divide between them and other sectors. It's a two way street, we need to bridge this divide. 

    Scrum is going mainstream. It's still below the radar though. Time for it to bubble up to the surface. Present successes to the C-Suite, speak in terms of  ROI. Increased visibility in the leadership world (Harvard Business Reviews and other business media) showing the power of Agile. Leaders will soon start realizing that they don't want to be left behind.  It's up to us to mention books, articles and Ted-Talks that are out there. Teds are good for the short attention span. 

    Recommended reading: 
    Radical Management by Steve Denning
    Team of Teams 
    Ted Talk : Simon Sinek "The Power of Why"

    Plea for Valpak to do their own Ted Talk.  Many attendees have heard of or have visited Valpak. Huge value seeing it directly, makes it more real and relavant with stories on how it can be done and is being done. 

    Agile not just a process.  Use Agile and become Agile, lead by example.  Scrumming, it's a verb

    Humorous family story: "Mom," says a young daughter "You're scrumming me again."  

    Agile Florida:  WE should create a movement around Agile beyond Software. A lot of dynamic 
    things happening in Florida.  We need to spread the word, build on what's happening. Check Daniel James Scott. Connect and partner with Universities and Colleges (good stuff happening).  

    Closing Call to Action:  Let's make Florida Agile... We become the Silicon Valley of Agile.  Go beyond being a beach or retiree community. 

    What to Choose To Work On To Be Effective + Client Communication

    1. Get it into customer hands ASAP - user testing.
    2. Use metrics (KPIs) to make decisions about what to build next.
    3. Make sure you have a dedicated product owner.
    4. Have a clarity on vision. The why. Make sure all members have visibility into the roadmap.
    5. Have a highly visible release schedule and how sprint performance affects that schedule.
    6. Set expectations with the client up front about when/how to communicate, how/what to measure KPIs, that the roadmap will change.
    7. Track ROI and evaluate ROI up front
    8. Add "Black Hole" column to Kanban for when you are expecting feedback from the client.
    Title: Tracking Pre-code development activities (Plow session 2)
    (or, how do we track a feature before it is ready for code)

    Initiator: Isaac Kimball, AAA National Office

    Notetaker: Isaac Kimball

    Business Analysis and UI Design can be examples of activities that are part of software development, including Agile software development. Stakeholders desire to know what is being planned to work on, but during analysis and discovery, 'we don't know what we don't know.' Tracking activities in pre-scoped buckets creates the risk of either constraining the outcomes of analysis and design, or else, the buckets have to change in size, description, content or number as analysis proceeds.

    Solution 1: Don't do it. Leave these activities out of tracking systems such as JIRA until this level of work is complete; in other words, the end of analysis is when work items are eligible to enter into JIRA etc.

    Solution 2: Begin tracking once a level of solidity is reached. Once enough about a unit of work such as a feature is known, to roughly estimate it and meaningfully talk about it, then it may be entered into a tracking system.

    Solution 3. Track items at varying levels of scope and solidity as they move through the backlog; closer to the top is more certain in scope and requirements. This implies that the backlog contains a variety of sizes of tracked items.

    Solution 4. Abandon tracking issues at the same level across professions; track highly specified, reliably scoped issues in development at story level; track fuzzy, conceptual ideas through analysis/discovery at a higher Epic or Feature level and don't worry about syncing them.

    Solution 5. Product Owner introduces a high-level concept, which can be tracked through iterations as it is defined and distilled by team including any of BA, QA, Dev down to the codable level of definition. However, the final item will be broken into smaller, tighter units that need to be tracked at a finer grain than the initial concept item could have been.

    Conclusion: The initial attempt that spawned this topic is impracticable in its original form. All solutions agreed on that. Most ideas and practices mentioned by participants involve separate tracks for tracking discovery/analysis and coding efforts. Most stakeholder needs, however, can still be met through a two-track solution.
    Topic Title: Managing Sales & Portfolio with Agile Delivery
    Initiator: Anitra Pavka (@apavka)
    Notetaker: Kim Solomon (@ksolomon)
    Participants: Shannon Hausey, Ken Nordquist, Stephanie Allen, Timothy Brockman, Dan Gowley

    Discussion / Key Concepts / Quotes / Revelations / Highlights:
    • Important to have foresight to look ahead and see what's coming up
    • What did sales promise vs. capacity vs. client flexibility in order to determine priority on Kanban board
      • Weigh these 3 components and look at all holistically
      • If you look at each individual thing, you won't maximize throughput i.e. if you increase capacity by simply hiring more people, what will end up happening is sales will just increase the projects
      • Assess team to determine what can be done to increase throughput
    • Not only must the delivery be agile but also the sales process. Each "aspect" owns their own Kanban board
    Recommendations / Next Steps / Actions:
    • Tools Recommended: JIRA Portfolio, Trello, VSTS
    • Incorporate an MVP (Minimal Viable Product) to keep things from staying in hold status
      • This also helps set expectation about when the product can be delivered and forces client to prioritize features
      • Make a delivery commitment on the MVP first but not a specific date, only x amount of months post signature
      • Announce to other clients once someone has signed to set expectations that their delivery date may have been impacted
    • Read Mythical Man Month
    • Incorporate a WIP limit on certain columns i.e. In Progress, On Hold.
      • Consider limiting not just the quantity of items but also the size
    • Use Kanban board to identify and analyze key metrics for business decisions
    • Helpful Kanban Columns: Proposals, Decision Pending, Sold!, Ready, In Progress (broken down into more columns at the team level), Hold (do root cause analysis here if project comes to standstill), Done, Removed (root cause analysis)
    • Incorporate a "Deal Desk" or "Council" during the pre-sales phase where a lead developer must accompany sales agents and the project stakeholders to discuss project, determine key features for the MVP and future iterations, as well as provide estimations and build out the Epics

    Outcome Oriented Agility

    Aligning teams and metrics with outcomes:

    1. Clarify business outcomes - where do you want your business to go? Outcomes must be measurable, define the value.

    2. Form teams based on the outcomes - teams must be cross-functional and sustainable. Teams will deliver based on the outcomes

    3. Metrics - start measuring things that will change people's behavior

    4. Incent - incent the teams based on the metric

    Repeat the above cycle - one outcome at a time!

    When teams understand the business outcomes and know what/how they are being measured, they will start to perform!

    You know outcome oriented agility is working when teams start talking about the outcomes instead of technical things.

    Topic: Role of Software Testing in Agile: Manual Testing v/s Automated Testing

    Initiator: Aakanksha Seetha
    Discussion: On various manual testing practices in and before the sprint, automated tools, where does manual testing comes in a sprint flow
    Quotes: Manual testing is exploratory testing and reveals the bugs/issues that functional testing may not and automated testing can never. Automated testing saves a lot of time of testers by relieving them from doing repetitive testing.
    Revelations: Agile promotes continues integrations which creates pressure on team to move towards automation but nothing can replace manual testing.
    Highlights: QA contributes towards the story creation process to refine and write user acceptance criteria and QA tests. Story discussed in grooming session should have QA feedback. When a story is in sprint Dev should write unit tests for the test cases defined in story as much as possible and QA performs rest of the manual/exploratory testing and regression and functional testing (if not automated)
    Recommendations: Exploratory and session testing is key to manual testing. Scripting is key to automated testing. Using tools such as Specflow helps manual tester to transition from manual testing to automated without going deeper at programming levels.

    How to implement scrum in a marketing department

    Pitching the Agile Antagonist

    Brian Burke

    Curtis Michelson

    Abbie, Adam, Rene, Salena, Mary, Steven, Curtis, Nicole, Vicki, Shashidhar, Tammy, Steven

    Discussion / Key Concepts.etc.:

    Talked about how the problem occurs, what happens when we encounter "the antagonist".  usually someone that has been "burned before" by a failed agile project, or have heard of bad failures at other companies, sometimes they present passive/aggressive behavior, and they want to hear the "business case" for this change.

    the pictures of the white boards capture a lot of the key takeaways from the sessions.  Here are a few more...
    - reverse engineer processes, target naysayers, voluntary attrition, set up a space for self-realization, leave the door open for exits. (but what if these naysayers are your best talent?) Be ready to let your top talent go, otherwise they hold you hostage. maybe we can create a longer adoption curve to ease them in, be sure to always show flexibility in approach (not Scrum Nazis). Agile can have many different expressions and animations. Dig into the past failures, tell culture stories, seek first to understand, model demonstrate wins, walk the talk

    Recommendations / Next Steps / Actions:
    Boiled down the ideas above into a 7 part checklist.

    1) Listen for culture, hear the pain

    2) Get an open-ended conversation with "how might we?" or "how could we improve?"

    3) Define the key problems to get 'alignments' with leadership and other objectives

    4) Crystallize those alignments in their own language.

    5) Find a way to 'demonstrate' or model an agile success in their context.

    6) Get a commitment, even if a small one, a next step

    7) Leave the exit door open (fall thru case).. allow them to leave gracefully

    Final retrospective on the session:
    great session, well facilitated, nice to have concrete list to land on. and great to have a real antagonist amongst us (thank you Mary!)

    Topic title: How to implement scrum in a marketing department
    Initiator: Dan Crowley
    Note taker:  Alison Ramoy

    Participants: Travis Serevich, Dottie Stewart, Chelsea Costerg(?), David Hoggk, Monica Murphy, Farrah Miller

    Discussion -
    History of implementing scrum in marketing at ConnectWise
    • Started with web development team building websites
    • Website development ended up with 2 teams:  Enablement (heavy template development and backend processing) and Content Population (webpage copy, design, creating pages from templates, digital optimization)
    • Additional implementation on non-website projects (product launches, sales campaigns, etc)
    • Not all scrum ceremonies enforced (too many concurrent projects, individuals not dedicated to teams)
    Key Concepts
    • Hard to implement "potentially shippable increment"
    • Difficult for teams to be "self organizing" due to multiple team assignments
    • Last minute requests (sales enablement) makes planning difficult
    • How to break away from "master piece campaigns" and move to more iterative campaigns using testing to feedback to the planning process
    • Use test results to allow creative teams to be more autonomous on deciding what next to do
    Recommended Resources
    • The Phoenix Project
    Recommendations / Next Steps
    • Potentially use different frameworks for different types of teams
      • Website template development (Scrum)
      • Website content population (Kanban)
      • Product Launches (Lean)