Agile 2017 Session Notes (and thoughts)

Thoughts on volunteering and how that directed some sessions I attended

For the first time, I went to an Agile conference as a volunteer.  I’ve been a speaker in the past, but never a volunteer, so I wanted to see what the experience would be like.  I enjoyed it quite a bit.  It helped bring some coherence to what can be a very disconnected experience of going from talk-to-talk, room-to-room because there were daily meetings of the volunteers and an opportunity to get to know people a bit better through daily meals together.  It also resulted in my attending some sessions I probably would not have on a couple of the days had I just picked from the program.

My plan going in was to work the weekend helping to set up the area and materials for packing bags and then doing the packing.  That was a busy experience that helped the 6am-2pm time I was there go by quickly.  I left open the Monday and Tuesday daytime sessions as I’ll explain below and then worked all day Wednesday (including that night) and Thursday (both so I could keep Monday and Tuesday open).  Since my goal was to attend all the Stalwarts sessions I could (described below) this approach worked well.

On Wednesday, I had hoped to attend the last of the Stalwarts sessions by working that room.  This worked for the morning, but someone else really wanted that for the afternoon, so I switched rooms and went to the Audacious Salon (covered below) that afternoon and then all Thursday.  Though I missed hearing Lisa Crispin and Jeff Patton at the Stalwarts sessions, I got to listen in to some interesting workshops in the Audacious Salon room which allowed me to meet some people I will follow up with as well as hear some ideas I am glad I was present to hear.

I also attended the Monday and Wednesday keynotes by David Marquet and Jez Humble.  I skipped the Friday keynote speaker to get caught up on emails as I had recently viewed the Youtube video of her June 16 talk in Oslo on the same subject.

While I am not sure if I can make Agile 2018 yet due to some possible scheduling conflicts, I will seriously consider volunteering if I can attend. [August 30, 2018 update: even volunteering, the room cost for Agile 2018 was prohibitive from my perspective. Agile 2019 is in Washington, DC at the Gaylord National Resort and Convention Center which does not appear to be near any other housing options or any Metro line.]

The Monday Keynote

Monday, the keynote was given by David Marquet, a former US Navy submarine Captain.  He spoke about his experience taking the lowest rated sub in the fleet at the time and turning it into the highest rated by giving up control.  A key factor in this decision was that he had been well-prepared to command a sub that he had learned everything about (through nearly a year of training).  He was then given a totally different sub to command where he knew little about how it operated.  However, he went in and tried to apply top down order giving since it was what he had been trained to do and those serving under him expected.  He related various situations he faced where this approach clearly failed in the face of what little he knew about the sub, including ordering a 2/3 speed when this new sub had no such speed.  (You can see his whole presentation on the Agile 2017 website for this and other anecdotes.)

Marquet’s early comments, interspersed with his anecdotes, addressed what he called “red work” and “blue work” doing/performing vs thinking/ deciding, noting how his training as an officer was based completely on a “red work” approach where the leader was expected to know it all and direct others to do the correct thing.  Indeed, the navy leadership manual at that time said: “Leadership can be defined…as directing the thoughts, plans, and actions of others…so as to obtain and command their obedience, their confidence, their respect, and their loyal cooperation.”  One goal of this approach was to reduce variability in outcomes, but it could lead to outright disastrous results as illustrated by one of his anecdotes regarding the loss of a (non US) ship.  (He mentioned a less disastrous example:  the “all hands” meeting usually intended to build consensus and reduce variability.

In the face of his early (though not disastrous) failures to be able command this way given his lack of familiarity with the sub, Marquet decided to give up control and focus on asking the crew to think, not merely do.  One early statement he in his talk made was: “Intent engages thinking and creates a bias for action.”  Therefore, he asked the crew to state/show their intent to do something and, hearing nothing to contradict this from their immediate superior, go ahead to do that.  In this way thinking led to doing, moving from “tell me what to do” through “I see,” “I think,” “I’d love to” to “I intend to.”  He did say that true self-organization, however, requires competence and clarity and that “being good crowds out getting better.”  (The latter reminded me of the Japanese quality philosophy that improvement does not come from satisfaction.)

Later in the day, at the evening social,” Marquet was signing copies of his book (Turn the Ship Around) at a vendor booth.  The book was selling much lower than retail and he was there, so I bought a copy right away.  I was going to go to Amazon and have it home when I returned anyway (along with the accompanying workbook, Turn Your Ship Around).  I’m glad I did since I started reading it later that night and at various times during the week.  Like his talk, the book does a good job of illustrating Marquet’s approach with many more examples/anecdotes about what was happening on the sub and why he decided to do what he did.  Context is always helpful when organizational change is involved.

The Monday Stalwarts Sessions

The sessions were held in rooms restricted to about 100 attendees with the speakers sitting in the middle in a “fishbowl” structure.  That is, the whole approach was without presentation or formality.  People would come up to 2-4 chairs by the speaker and ask a question which the speaker would answer.  One chair was always to be open such that, when a new person came up to occupy it, one of the people who had already asked a question would be expected to leave, opening a chair for the next person.  A couple sessions this time did have people write their questions ahead of time which the moderator(s) would look through to find common themes then just have the speaker(s) answer.  One session moderator even had attendees pair up and discuss possible questions, then used a randomization approach to choose what questions got asked.  (I don’t think people really liked either one of these moderator-curated approaches compared to the traditional fishbowl approach.)

As I mentioned previously, the Stalwarts sessions were my major focus for the Conference.  The speakers were to be people I have known/heard over many years and have always found interesting to listen to during that time.  They always had something to say which, while perhaps not “new,” was said in a way that I felt worth noting and considered an interesting approach to explain a point to others in my training/coaching opportunities. My personal goal at this Conference was to ask every speaker one question: “What are the key things you feel people should understand about Agile right up front when approaching it for the first time.”  I got interesting, and all different, answers, sometimes without even asking the questions myself.

Monday’s speakers were Ron Jeffries and Chet Hendrickson, Steve Denning, and Dean Leffingwell.

Ron and Chet

I didn’t actually get to ask Ron and Chet my question, but they seemed to answer it in answering other questions.  One thing Ron said right at the outset was to emphasize frequent working software.  Also consider how you make diverse groups of people work well together Chet noted that having called it “Agile” made it something everyone wanted to be, suggesting, had it been called (I think he said something like) “glurb,” perhaps not as many companies and their management would have thought they had to try to do it.

When asked about “Dark Scrum,” Ron stated that it was about pressure (to go faster, to perform in some pre-defined way, to hit some targets).  They both agreed that “time-boxes are your friend.”  Organizationally, Ron felt the way to get non-IT parts of the organization (e.g., finance, PMO) engaged effectively was to get them involved in problem-solving, not rule-setting.  I think he felt that, if you brought together the right people, what happens would be(come) the right thing.  And when asked about cross-organizational dependencies, Ron stated that communicating across teams with acceptance tests was a very visible way to highlight where the bottlenecks are in dependencies.  That should motivate Product Owners to work to eliminate impediments.

Regarding Product Owners, and where they saw that role going, it was noted that some companies were eliminating the traditional PO role in favor of becoming Product Champions (Disney for one).  They’d get the funding, but turn over a lot of the product to the teams.  Ron stated that Kent Beck once said the biggest mistake in XP was the dichotomy between the team and customer (or PO in Scrum).  That was a flaw because of how it set up silos, making it harder to think of the customer and developers being on one team.  (I am reminded of Menlo Innovations in Ann Arbor, MI who like to have a customer sit with them as they develop what the customer wants.  At the end of each week, the customer does the weekly demo of what the team accomplished.  If the customer struggled to do that, they felt they had failed.  Go read the CEO’s book entitled Joy; it has a lot of interesting information about how Menlo Innovations operates.)

Steve Denning

Steve’s answer to my question was indirectly the following three things based on Agile’s evolution since 2001): (1) do everything in small teams (2001-2010); (2) deliver value to customers (2011-1016); have the whole organization Agile (2017 - ?).  Regarding the latter, he encouraged us to think of “managers as enablers” rather than commanders.  He also asked us to consider the dynamics of people sitting around a table and having a [formal] discussion compared to moving things around on the wall/board together.

In answer to a question about Agile having jumped the “chasm” and not being pursued by large traditional companies, he noted that it’s worth the effort to save large organizations rather than “let the dinosaurs die” which had been an attitude of many in the Agile community very early in its growth.  However, he did suggest one should “go with the champions” and ignore the laggards in organizations. 

A final point he made was to take the traditional “Iron Triangle” topics (Cost, Schedule, Scope) and recast them as Value, Flow and Flexible Scope.

Dean Leffingwell

I do not know Dean.  I know of him having read much about SAFe and having reviewed a video series he did several years ago.  My encounters with some people practicing SAFe, including speakers at a couple conferences I’ve attended, have not endeared me to SAFe.  However, I have greatly appreciated hearing Dean speak.  He has clearly though a lot about making Agile successful in larger contexts than individual (or just a few) teams.  So I wanted to hear him speak further in response to people’s questions, expecting someone to raise the issue of what so much “hate” toward SAFe.  That eventually came up.

However, the questions started with specific ones about implementing SAFe and what drives Dean’s belief in what SAFe asks of people. It started with a question about the length of the Planning Increments, to which he responded that 6-12 weeks seems right (with 2-week iterations).  He felt they would be too much overhead in less time and too long a feedback delay for making substantive changes in the other direction.  Feedback was important and he spoke of feedback compared to what he called “assumption-driven development.”

He was clear that a lean/Agile transformation will not work without everyone being on board.  He asked, can people plan, work, and demo together – the latter being important for customers since “people like their own stuff” and want to see it working.  In SAFe, responsibilities are much the same, but the way they are implemented is different.  SAFe’s main assumption is that many teams are working together to accomplish something big.  Hence, as he put it, the “goal isn’t for the teams to Sprint alone, but for the system to Sprint.”

When the question was asked why so much SAFe “hate,” Dean said SAFe was “disruptive to the marketplace.”  This suggested a lot of the “hate” was coming from other established approaches and their proponents in the face of SAFe’s success.

The Tuesday Stalwarts Sessions

Tuesday’s speakers were Arlo Belshee, Kupe Kupersmith, Linda Rising, and Alistair Cockburn.

Arlo Belshee

The first time I met and heard Arlo speak was at an early Agile Roots conference in the Salt Lake City area.  We ended up together doing some impromptu sessions for a company from that area which has sent several of his managers to the Conference.  Before heading back to the airport at the end of the Conference he and I and a couple others had a meal together and, as I was interested in getting back to some coding work (even if just for myself) after not doing any in many years, I asked him what languages he would recommend I start with.  His advice was C# and Python, both of which I’ve had some chance to work with since.  Given my past interaction with Arlo, then, I expected a lot of technical discussion, but his answers to people’s questions led more toward organizational hierarchy, team interaction, and personal norms/beliefs.  This was not what I had expected from him (or the people asking him questions), but I was very interested and happy to hear what he had to say.

But, first, I should mention a couple “technical” comments he made during his talk and when we sat together for Alistair’s talk later in the afternoon.  First, he recommended mobbing, pairing, and refactoring even more than testing as important practices (which to me meant QA over QC as the key quality focus).  Second, he felt that one needed a stronger evidence than testing can provide when refactoring.  I need to look into this latter point more for the greater sophistication his answer provided than I can relate here.

He began with a comment harkening back to the keynote address by David Marquet by discussing a team he had worked with that was “a delivery engine [red – do & deliver], not a thinking one [blue – think & decide].”  A team needs to “own its own destiny,” i.e., its process, as much of the product as it can, etc.  This, to me, connected to his comment about having “powerful teams” not “empowered” ones since the latter implies they do not have, but must be given, the right to self-manage/organize.  Somewhat related to this, he said that “a company that has employees is not being served well” which I found a most interesting way to think about the relationship between a company and the people who work there.

Some other comments he made regarding teams and individuals were: (1) consider the potential impact of internal (usually unstated) norms (of each individual) getting in a team’s way and (2) if teams are judged by things outside their control, it leads to micromanagement by those managing the team (presumably so they feel more comfortable about how the team behaves in the face of those things the team cannot control).

There was another series of questions related to organizational hierarchy.  “Hierarchy,” Arlo said, “is how you scale authority-driven decision-making.”  Therefore, trying to make changes by just dismantling the structure (i.e., the hierarchy) just drives the visibility of the decision-making process underground, but does not really change anything.  A flattened structure is just a variation on hierarchy as opposed to what he called a “co-op” approach.  In a hierarchical structure, two things are important: (1) look for where the “unsafeties” are and deal with them and (2) “a culture of experimentation” can produce change in an otherwise hierarchical structure.

(Regarding hierarchy, I need to check into something Arlo said about its roots in the Prussian military.  He said there were two issues it and the associated command and control associated, solved:  desertion and weak information flow.  The former, he said, was addressed by telling the lowest officers to shoot any deserters or be shot themselves by the next rank above them.  The latter had to do with written orders delivered on horseback which meant information was often very late, so having officers issue orders (even wrong ones) seemed better than the chaos of no orders at all.)

Arlo ended with a roleplay using volunteers from the audience. He started by asking “What rights do you think you have?  What happens if you honor others’ rights but ignore yours? What if you honor yours and ignore others’?  What if you honor both –how can you do that?” He talked a bit about taking various stances in engaging with other people: aggressive, non-assertive, and assertive.  In the former you assert your rights more than others.  In the next you honor others’ more than yours.  But the latter results in honoring yours and theirs.  He then asked a person adopt one of the stances while another took one of the others and had them discuss a situation:  a manager comes to a developer and states that a deadline they both expected to be a week off has to be met by the end of that day.  After they took their positions for a short while, he stopped them and asked how they both felt about the interaction.  Since different people had different reactions, I won’t go into everything said, but it seemed like a very interesting exercise for a variety of training situations.

[In looking at my notes I was surprised at the length of them for Arlo’s session compared to most of the others.  A lot got packed into 75 minutes.]

Kupe Kupersmith

Kupersmith was the one speaker I really knew next to nothing about, though I had heard the name.  His session turned out to be all about connecting to other people (i.e., networking in a positive sense not when done to “get something” out of another).  He began by asking us to form ourselves into four corners of the room in response to two questions he asked.  Turns out, this divided us into the 4 main types in the DISC personality profile.  There was some lengthy discussion about what this meant for connecting with other people.

Soon after that he made a comment about both working and trying to keep up with change: “We’re never fast enough.”  Which suggested to me, at least, that focusing on trying to be faster might be distracting too much from other things.  And is the pressure to be faster based on what’s really needed or simply lack of trust that people will manage time well on their own.  A lot of micromanagement I’ve seen certainly comes from a lack of trust in this regard as teams are “kept busy” or given “stretch goals.”  (I’ve seen teams do this to themselves, but it’s their choice and they know what pressure they want to apply to themselves and when not to do so without someone else deciding it for them.)

Regarding networking, Kupersmith said that we add value when we are connected to many people and can draw on that network to get information when we do not have that ourselves or give it when others need it.  Suggested we improve our networking in one way by listening for “offers,” i.e., opportunities to make connections.  One live example was a person who asked about applying Agile ideas to education.  Kupersmith responded that, in fact, he knew David Marquet had some contacts in that area and would put this person in touch with Marquet regarding that topic.  [I’ve been in touch with Kupe and he provided me with contacts already on that topic including the agileineducation.org website.]

A couple final things from his session related to what he felt in meeting people would take you beyond asking them “Where are you from?” and “What do you do?” especially in a conference-like setting.  One was something from Steve Denning: “What is keeping you up at night?” Or something like “What drives you?”  [I’ll start using this latter one besides, or in addition to, my “Tell me something [a hobby, former job, someone you know, interesting place you lived/visited, etc.] about yourself other people might not know?”  A second thing was an improv-like role-playing he did called “Repeat the Repeater” where you repeat the last thing the other person said then say “and” followed by your addition – the next person then repeats your addition as the last thing you said and continues.  He had us all pick one other person and try this for about 30 seconds.

Linda Rising

I had not heard Linda speak in quite a while and never in a fishbowl type of session.  I was amazed to be reminded about how calmly and peacefully she could be “assertive” (using Arlo’s term).  She started by singing, and having us join in with, “When You Wish Upon a Star,” turning it around on us by discussing Gabrielle Oettingen’s rethinking of positive thinking and her WOOP (wish – outcome – obstacles – plan) approach to achieving goals.  Linda said that Oettingen’s work suggested passion and wishing make it less likely we’ll succeed rather than more so[…sorry Jiminy].  WOOP was Oettingen’s suggestion for how to increase the likelihood of success.

Another question prompted Linda to mention Gary Klein’s “premortem” idea in which a team envisions two things about the future of their project (rather than, at the end, discuss what happened).  One was “What made your result awesome?”  The other was “What made your result disappointing?”  Then, of course, you consider how you can make the first true and eliminate what will make the latter true.  Yet another exercise I can make use of in my own work though I have a couple similar things but they involve looking back, not forward, then applying the lessons forward.  This is a kind of root cause approach.  Linda recommended “small experiments,” rather than root cause, to improve.  [Several of the Stalwarts speakers used the word “experiment” during their sessions in one way or the other.]

One note I took from Linda (which reminded me of the good vs better theme Marquet mentioned) was that even things that are working well could probably work better – you must continually improve.  I mention this in coaching when teams feel things went very well during their iterations and they don’t feel there’s anything to talk about at a retrospective, i.e., nothing to “fix.”  I remind them retrospectives are about improving not just fixing things.  There are so many ideas from the early Japanese quality movement, including from Deming that address this idea of improvement, e.g., improvement is not mandatory, but, of course, neither is survival. 

A few other final thoughts were: (1) if people “hate” Agile, can you find out what they felt they lost in practicing it, i.e., what was precious and comforting that was taken from them; (2) that the word “companion” comes from French meaning someone with whom you break bread, i.e., share some essential; and that (3) people cannot begin with insight.

Alistair Cockburn

It was the Agile Development Conference in Salt Lake City in 2004 when I first met/heard Alistair.  I had read several things he and Jim Highsmith had written and was eager to hear them speak.  Most of that early Conference (and several to follow) were strongly Open Space structured, but there were some more presentation-style sessions.  Since then, I think I’ve read all of Alistair’s books and many of his articles and blog posts.  I’ve also heard him speak many times since then and even been in some workshops with him as another attendee.  Like all the other Stalwarts speakers, I don’t recall any occasion when he did not say several things I noted down.  This session was no exception.

Alistair started with an analogy about focusing on the muscles in one’s arm compared to your finger tips and the thing they are reaching out to touch.  See his blog about this with some interesting twists to how one’s focus can change: http://alistair.cockburn.us/Blindfolded+at+the+Table/v/slim. This also somewhat related to a next bit of discussion about work not started (considered as a hypothesis about what it could become) moving into delivery which is the place many teams stop.  Alistair suggested we should consider we are not “Done” until we know the impact of that delivery.  A significant gap between those last two will diminish the learning teams experience.

When someone, later in the session, pointed out Alistair’s passion for Agile, he said he no longer had passion for Agile but for better collaboration between people.  He said his next book would be called Team Work, noting the space between the words emphasizing how teams work together more effectively.  (As some may know, Alistair has pursued the core ideas he felt were represented in Agile, calling it the “Heart of Agile”: Collaborate – Deliver – Reflect – Improve.  In conjunction with this he spoke of three “doors” to Agile: Shu (from Shu-Ha-Ri), play, and Kokoro (heart).  The latter is also described as “a Japanese word connecting mind, body, and spirit … also driving scientific discovery.”  A related question led to an example of learning to do something by “practicing the basics over and over until [one] can do the move” as opposed to trying to practice the move itself, i.e., trying the move, failing, and going back to basics (perhaps over and over) until the move can be done.

The subject of scaling Agile was raised and Alistair noted a concern about scaling Agile from where it fits to where it really has nothing to offer.  He said Scrum, for example, was defined at the RI (mastery) level where teams might work it differently.  Scaling often necessitates conformity and consistency which is not what Agile was intended to address.  He gave some examples of small team situations (even up to 600 people), then very large efforts (like Telstra with 10,000 people), then the concerns of C-level people (which Agile simply does not address and which doesn’t speak to their issues).

Regarding another question, Alistair spoke of the push-to-pull (Theory X vs Theory Y) “umbrella” separating the autocratic leadership style of control from the “guest” leadership style of permission.  Check his recent presentation on the Heart of Agile at http://alistair.cockburn.us/get/3645.

One of the people who can up and asked a question was Arlo Belshee.  Several things were discussed with Alistair pulling more from Arlo, including going back to Arlo’s three stances (aggressive, non-assertive, assertive).  Besides the stances Alistair has Arlo talk about emotional self-checkin as an aspect of reflection and the “learning demo,” i.e., where one demos the increment for the iteration to show what the team learned.  Arlo stated that product demos could occur all along the way so the customer/PO would see what was happening incrementally with no surprises at the iteration demo.

Finally, Alistair responded to a question by noting how he described Scrum to Ken Schwaber (who he said liked the explanation).  Alistair said Scrum is about: (1) delivering every Sprint, (2) the people on the team decide, (3) inspect and adapt every day, (4) “it’s a good idea if someone has the capacity to run down impediments,” and (5) one person to articulate priorities and (business rule) policies.

Part 5 of 7: The Wednesday Keynote

Jez Humble was the speaker at this keynote and, since his topic was continuous delivery, compared to Marquet’s presentation on leadership, Humble went in a decidedly more technical direction, at least until the very end of his presentation. (You can find a version of his slides for the first part of his talk at https://www.slideshare.net/jezhumble/continuous-delivery-sounds-great-but-it-wont-work-here and a video of him giving the talk using these slides at https://vimeo.com/193849732.  A version of the talk from Agile 2017 isn’t up on the Agile Alliance site as Marquet’s is, at least when I am writing this.)

Humble started by stating that continuous delivery was about people being able to deliver “safely, quickly and in a sustainable way,” the latter meaning that no one should ever have to work weekends again for a release to happen.  This led to the key points of his talk which addressed the reasons people give for not being able to achieve continuous delivery: (1) four that people often give and (2) the two real ones - the organization’s culture sucks and/or its architecture does.  Humble began with the first four: (1) we're regulated, (2) we’re not building websites, (3) too much legacy, and (4) our people are too stupid.  (He really didn’t address the “real” reasons directly but through examples, especially in addressing the fourth “excuse” about people.

As to the first (we’re regulated), Humble talked about what was being done in the Federal Government, pointing to Could.gov as a source of material on tools and approaches.  He also noted that Amazon had regulatory considerations and they were deploying (on average during the week) every 11-12 seconds with up to 10,000 hosts getting each deployment simultaneously eventually with up to 30,00 hosts receiving each deployment.

As to the second (we’re not building websites), he noted how HP had gone from 5% to 40% of their cost/time focused on new features for their printer firmware, partly through some key architecture decisions that, on one level cost them more but made it far easier to reduce support costs and implement new features.  One challenge he mentioned was convincing developers to work in small batches which he said was hard to do.  So, he said, build a system where this is the “rewarded” way of working, i.e., it’s easier to build and test small pieces than large(r) ones.

Humble addressed the third (too much legacy) with an example of a mainframe system using a video from Australia’s largest insurance company showing some mainframe “green screen” “GUI” testing as they are fast and “durable” for testing.  The video talked about “creating 10,000 policies in a short time to do such testing.  Another example had to do with creating service-oriented applications to talk to the legacy system which eventually would be surrounded and “strangled” by the smaller applications.  This is how Amazon restructured their architecture according to Humble.

The final stated reason (are people are too stupid) was addressed by starting off saying “Well, whose fault is that?”  He told the story of a Netflix executive who, when asked, “Where do you get your amazing people?” simply stated, “I get them from you.”  Humble then talked about the Nummi Toyota plant which was a joint venture between Toyota and GM and how the worst GM plant was closed then reopened and was turned into their best rehiring and using the same people.  Humble noted that you cannot succeed by changing people’s minds but by changing what they do [and let them figure out changes needed to achieve higher quality].

One other thing I want to note that he said was: time invested in estimation was inversely related to level of trust in an organization.

At the end of his presentation, Humble changed his topic to address the Google employee memo on workplace diversity which had just made the news.  Since that’s been covered a great deal in many places, I’ll just say he had a great deal of support shown during and after what he said for including this in his keynote.

 Part 6 of 7: The Wednesday Stalwarts Session

After the keynote, the one Stalwarts speaker I heard (as the volunteer in the room) was David Hussman.  Like several other Stalwarts speakers, I first heard David many years ago and remember his comments linking Agile work to attitudes and communication styles used in improv theater.  This time, questions posed to him went in a different, though equally interesting, direction which, to me, was a series of “one-liners” with a lot of (implied) impact, so I’ll just list them, one at a time, and you can decide what they imply to you:

Stop delivering late and blaming other people.

Stop lying to one another (about the testing that’s been done).

You’re not a good soccer team because you know the rules.

If nobody’s touched [some piece of] code in 6 months, delete it [, i.e., do we really need it then?]

IT & business vs product & customer(s)

Netflix represents 30% of all internet traffic; they have no PO “team” and no test team(s); a few engineers and a manager own their product space.

We need people able to work across [organizationally] not just vertically [within their silos].

Learning inside vs outside the code.

“Shut up and play the guitar” – show, not tell [David used to work for Prince.]

Cultures change when people see success.

Investment in software products isn’t a given return.

Produce meaningful evidence.

Part 7 of 7: The Audacious Salon Sessions

Wednesday afternoon and all day Thursday, I was in the room where the Audacious Salon sessions were held.  These sessions were described by the chairs (Lyssa Adkins and George Dinwiddie) as “Geared toward veteran Agilists, Audacious Salon sessions are the beginning of deeply explorative conversations, not the entirety of them.” “The Audacious Salon is a place where strongly held ideas are discussed in civility, where dialog leads us places we've not yet dreamed. It’s a place to compare experiences and expand our own with the richness of others. It’s a place to offer insights and hear how they fit for others. It’s a place to hear others' insights and test our own beliefs against them.”

Some topics were a single session in length, others took two.  Topics earlier in the week were: #NoEstimates, Making Products without Words, Polarizing Topics, Moving from “technical debt” to “technical health,” Innovation Killer Among Us.  When I was present, the topics were: Agile’s Role in Social-Political Movements, Good news About the Agile Movement from Agile Veterans, Ethics & Innovation in Software Development, How Agile can Data-Focused Teams Really Be.

I have just a few notes, partly because (1) I was by the entry door which was away from much of the discussion, (2) much that went on was individual brainstorming and small group discussions, and (3) each session had a “what’s said here stays here” presumption.  A couple things I did overhear and feel confident repeating without concern for privacy, etc. are the following:

Assume good intent – no bad people, but people can do really bad things (which they may truly feel is the right thing to do in the situation).

In discussing race and gender, it’s important to get away from “scientific” definitions if you want to really connect with people and have a discussion.  People of an outward-seeming similar "race" might consider their marriage "interracial" because of their very different cultural backgrounds.

Improv means to “Offer your ideas and opinions in a manner that increases the opportunities for others to do the same.”

“These are choices made by an organization, not laws of physics.  You can make other choices.”

Conclusions

Well, I leave that mostly to you based on what ideas stuck you as useful.  My own conclusion is that it might be the most valuable Agile 20xx conference I have attended.