Wednesday, February 8, 2017

Day 1, 10:30-11:20: Organizational Agile Transformation with Aki Namioka

Aki and the group brainstormed the issues that they have encountered as organizations have transitioned to Agile.  We also discussed what we'd recommend that people do and what they don't do.




Issues

  • Mandated Agile

  • "Agile means faster, right?" --Leadership

  • Management Buy-In

  • C-Level understanding

  • Lack of exec. Support

  • Chasm between "management" and teams

  • Credibility of "new" method

  • Conflict between Agile process/planning and organizational demand to know when everything will be released

  • "Look, we're agile now.  Why can't you tell me exactly when you'll be done?"

  • All in or incremental

  • Thinking it's an IT-only problem

  • Company-wide adoption understood

  • What (or if) areas are important to implement consistently (rules vs. guidelines)

  • IT is ahead of business on Agile projects.  How to onboard/transition business to Agile?

  • Not starting with people

  • Not understanding why they are going Agile

  • Make all changes at once?

  • Functional managers do not have clearly determined roles going forward...they start becoming blockers

  • Doing Agile vs. Being Agile

  • Just focus on rituals

  • Seems like a lot more meetings

  • No consistency of individual processes

  • Not changing how (agile) projects are funded

  • Defining the role of "formal" training

  • Teams want to start before they are ready - how to slow down to speed up

  • What's my new role - How does it map?

  • Underestimating culture change needed and impact


Don't

  • Measure agility by more throughput only

  • Go big or go home

  • "Big Bang"

  • No decision power

  • Force feed

  • Just jump in (Plan, instead)

  • Keep Sprints the same as the release schedule

  • Try to combine roles (Scrum Master/Developer, Product Owner/Scrum Master, etc.)

  • Assume that people will remember what you said in a conversion

  • Assume that people will read you emails and understand them

  • Create mandates (especially using metrics as "hammer")

  • Punish or reward based on Agile metrics ("velocity", etc.)

  • Fully utilize

  • Compare velocities between teams

  • 25-person Scrum of Scrums on the phone


Do

  • Teach effective retrospective techniques

  • Use multiple forms of communication (written, oral, etc.)

  • Explain and pitch

  • Bring business along from start

  • Rollout by teams

  • Capture why? the change is being made

  • Clear expectations at all levels of organization

  • Continuous communication and transparency

  • Keep people talking (individuals and interactions)

  • "Try it" for 'N' weeks

  • Be organic and open...not big ban/rigid

  • Use Agile to create Agile

  • Incremental change

  • Start with less teams

  • Incorporate many functions into the "Dev" team (customer support, QA, business, etc.)

  • Teach effective retrospective techniques

  • Treat change agency as seriously as you treat Agile and technical practices

  • Acknowledge inherent differences between old way and Agile

  • Ensure people have foundational training

  • Educate

  • Training: why/how much?

  • Set expectations that your processes will evolve as you learn

  • Get developers talking to business people

  • Share personal stories

  • Put everyone through same training, speaking same language

  • Level-set/establish baseline enterprise/org-specific "agile"

  • Go all in (reduce mixed methodologies between teams)

  • Engage IT and business simultaneously so entire Project Team is aligned and understands Agile process (Buss & IT in lock step!)

  • Implement an Agile Center of Excellence

  • Start cross-functional project communities of practice

  • Make failures, learning, and successes visible


--
David Whitlock
Adjunct Lecturer
Portland State University

1 comment:

  1. Thanks David. This session was posted twice - and I put my notes in the other posting. But your pictures and notes are great. Thanks much!

    ReplyDelete