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.
  

Back to Basics

While I have been working exclusively for one company since my last posting, I have been watching the industry, attending Scrum Gatherings, following people I've known over the years, listened to a lot of webinars, and generally tried to keep track of what's been happening.  I am more and more convinced because of this, and the independent consulting I did for years before my current job, that too many people who have become engaged in some form of Agile transition, were either not shown the meaning of the Agile Manifesto's Values and Principles or quickly bypassed them in favor of practices ("doing Agile").

It's not that I'm claiming to be some magnificent authority on the Values and Principles, but you need not be a genius to recognize behaviors that are clearly antithetical to those ideas.  Without understanding those Values and Principles, it's just too easy to "tailor" recommended practices in such ways that either clearly miss the point  or so rigidly "interpret" them as to exclude useful implementation.  So I'm going to even more firmly structure my future coaching and training very strongly toward why before any what and how.

I know people want the latter things a lot and I am not averse to telling them about good examples of practice that I have observed.  However, I'm going to resist working with those who want to skip the why.

“People Don’t Shop for Organizational Change”

I was talking about coaching experiences yesterday with Skip Angel.  I said that I try to get management who feel they want to implement Agile practices to understand that, before too long, they will need to face organizational, not just team practice, changes.  At one point in our discussion, Skip said the phrase that is the title of this blog and he is quite right. When management starts to look for improvements in their product development efforts, they usually do not put out RFPs for organizational change.  Someone normally decides, based on peer discussion or reading, that some method, technique, practice, etc. seems to be working for some other folks and that it might be what they need, so they ask for something along those lines.  Something like Agile, for example.

In this regard, Agile “transformations” are no different than the organizational efforts in the 80s and 90s to implement ISO 9001, CMM, ITIL, COBIT, etc.  That is, small changes at individual or team levels are possible, but the real benefit of pursuing any of these is to look at their impact organizationally.  Even when companies do this, there seems to be the feeling that the desired improvement will occur with minimal impact, i.e., with little actual change required.

This usually results in attempts to immediately “tailor” the chosen approach and produce a “hybrid” version of what has been selected.  The reasons for this are varied, but seem to boil down to organizational (un)readiness for the change the approach asks be pursued when it expands beyond team/functional area impacts.  This, in turn, is often manifested by team level training that focuses on practices and techniques without conveying what I believe to be an understanding of the values and principles behind the practices.  The resulting tailoring and hybrid practices can then miss the point of the originally recommended practices, often losing the impact intended.  At some point, people begin to wonder why the desired improvements are not happening or happening fast enough or at the level of impact desired/expected.

I think one reason organizations ending up in this situation is that they, indeed, didn’t start out “shopping for organizational change.”

The Agile Manifesto as "Immutable, Sacred Text"*

Periodically, over the past 6-7 years, the issue of whether the Agile Manifesto** requires changing comes up and a variety of points are made suggesting/justifying why it seems this is needed. Recently, some of the new and repeated points have been:

• Surely learning has taken place in the almost 10 years since the Manifesto was created which would influence a different set of ideas to be stated now than then.
• The work being done by people before the Manifesto existed wasn’t about “agility” but was about more effective, productive software development.
• By the very nature of Agile ideas, we should be prepared to change the Manifesto and not keep it the same since that was just a point in time perception and both perceptions and needs change.
• Most of the ideas in the Manifesto can be found elsewhere, especially in Lean ideas, so they should not be regarded so permanently.
• The Value statements are so easy to agree with that they are, essentially, “content-free.”
• The Principles are redundant in many aspects (indeed one basically repeats a Manifesto Value) and could be reduced to a much smaller set without losing any meaning/effect.
• Misunderstanding/misuse of the Manifesto (as stated) is now an impediment to new people learning about Agile ideas so we should move away from it as a focal point.

And the list can go on and has at various times.

There are, of course, lists of actual suggestions for changes/additions to the Manifesto which are even longer and, in themselves, certainly contain useful, important ideas. One just has to look at the early material on each method that was around at the turn of the century to see how many values, principles, ideas, etc. existed which are not explicitly mentioned in the Manifesto. So it was even obvious back in 2001 that the Manifesto did not say everything one could be expected (to need) to know on the subject.

Among others, Ron Jeffries has said that the Manifesto is a point in time statement of belief by a specific group of people. After years of experience and interaction with one another, they came to feel that they wanted to say something about ideas they shared which were, as suggested above, just a subset of the ideas they held.

I don’t believe the people at the Snowbird meeting where the Manifesto was created thought it was some document that should be amended, extended and always be the authority for thinking on the subject of better software development. I do believe they felt the ideas were a solid set of guidance, an effective starting point for changing how software development was being done, for the most part, up to that time. And, if groups/organizations pursue a new approach to development, the Manifesto’s elements can be looked upon as useful touchstones for comparing chosen techniques and practices to ideas those people in 2001 felt held important guidance for doing so.

So when calls to change (or even abandon) the Manifesto are made, while I am interested to hear what people would offer as changes, additions or replacements to/for the Manifesto, I have not seen anything that, to me, materially alters what is there.*** Much of the impetus to change the Manifesto sometimes sounds as if, to get other ideas accepted, the Manifesto must be reduced in importance in some way or shown to need “fixing.” Perhaps the strong attraction to the Manifesto just shows that the ideas can ring very true to many people.

If the fear is that latching onto the Manifesto (and misunderstanding it) holds people back and prevents new learning from taking place, perhaps that is our problem to solve, not by trying to change the Manifesto in some way, but in more effectively presenting and explaining it to those new to it while extending the knowledge that can be associated with it. I do not believe we can blame the Manifesto for people not “getting it” because it seems to me that this happens to every idea once it breaks out into the mainstream of awareness.

If something has any validity, it will attract people, but they will surely try to adapt it to what they feel is their need. Much of that adaptation is always a divergence from what the original ideas intended. I don’t think it is possible to expect this not to occur unless one produces a document as ponderous as much formal legislation, standards, etc. material. Of course, even when you try to do that, the interpretation is still going to be there, sometimes worse than before you started.

So, by all means don’t stop at the Manifesto, but don’t assume it is somehow the problem or the impediment to growth.

[* The title is derived from a Tweet by Jason Yip.]

[** When I say “Manifesto,” I include both its explicit Values and the associated 12 Principles that followed unless a distinction is otherwise made.]

[*** Efforts such as the Manifesto for Software Craftsmanship and the APLN’s Declaration of Interdependence seem to me to be good examples of making the point about other important ideas without suggestion the Agile Manifesto’s are now flawed or necessarily passé.]

Letting Them Figure It Out

A few days ago, there was a brief exchange on Twitter about the Scrum advice to let teams figure things out for themselves where there isn’t explicit Scrum guidance on a topic. Since there isn’t explicit Scrum guidance about a lot of things teams encounter that leaves a lot of “figuring out” for teams to do, including adopting practices from other Agile approaches like XP, Crystal, DSDM, etc.

There seemed to be an initial implication that leaving teams to do this could be wasteful, perhaps even detrimental, given the assumption that they really don’t have a good answer for their situation and might not, by consensus, come up with one. I suggested that “guiding" teams to figure things out seemed to me a useful way for a coach/ScrumMaster to fulfill that role than just "letting" the team figure it out. If the coach/SM sees a possibly useful direction for the team to go in, guiding the team that way through the “right” questions would be an appropriate approach.

Given that, I said I didn’t mind teams figuring things out for themselves, just not doing so by expecting them to reinvent all knowledge to accomplish that. Thus, if the coach/SM knows of techniques/practices that have worked for other teams, suggesting those ideas and asking the team what they think about them still seemed to be allowing teams to make their own decisions while still being helpful in a non-directive manner.

So that’s gotten me thinking about the subject of doing this sort of thing as a coach/SM as it has been my way of performing these roles. Indeed, it has been my way of teaching people about things for decades, even before I was involved in software development. I’ve always associated this with employing the Socratic Method, i.e.,

A pedagogical technique in which a teacher does not give information directly but instead asks a series of questions, with the result that the student comes either to the desired knowledge by answering the questions or to a deeper awareness of the limits of knowledge. [From http://www.answers.com/topic/socratic-method.]

I don’t go as far as “Socratic irony” with this. That is, I don’t feign/pose ignorance. Indeed, after using the Socratic approach a bit, I’m fairly certain the students/teams I’ve been engaged with don’t believe that’s the case.

But this raises the following questions:

1. How much information about techniques and practices might a team need before they start working together so that there are not too many open issues to “figure out”?
2. Indeed, how many open issues are “too many” for them?
3. How many times or how seriously should a coach/SM allow a team to “fail” in such decision-making (since allowing teams to fail, a bit, is typical advice given to coaches/SMs/managers in an Agile context)?

On the latter point, one thing I can say is that learning through even a little failure can be stressful when teams are up against deadlines. I also think, given such deadlines, both teams and people around them seem much less inclined to accept the “fail a little” approach.

Now the kind of “deadlines” I am thinking of are not the kind the team commits to themselves through reasonable estimation and planning. I’m thinking of the all too common situation where an Agile approach is taken in the context of already fixed schedules and, more or less, fixed functionality expectations.

Not only is this kind of situation inherently a major impediment to learning through some failure, even though a Socratic approach, it is an impediment to the whole idea of teams “figuring it out” for themselves whether serious failure would be involved or not.

With fixed schedule and functionality (as well as fixed staffing) usually comes 100% “resource utilization” assumptions as the way those outside the team(s) assume planning and estimation will be done.

I believe every team I have ever been involve with, Agile-based or not, has been somewhat astonished at my suggestions that

1. they only presume a 6, not 8, hour productive day in their estimation, so a 30, not 40, hour week;
2. within this 30 hour week they commit to less than 100% of that in functionality terms, especially when they are new to this approach;
3. they do not presume to commit overtime at the outset as a way to deal with the fixed schedule and functionality.

The first point is something I learned doing estimation over 30 years ago. The second has been influenced by my Agile training/experiences. The last is also a nearly 30 year old belief based on watching teams do this, implicitly, if not explicitly, and coming up with unreasonable commitments as a result.

So, it seems to me that trying to let teams figure things out for themselves isn’t something that will be successfully achieved outside the context of having some other things in place that give the teams the “space” in which to believe they can/should expect to do this. Otherwise, they are going to look for someone else to solve the problem (and hang the result on) given their very natural perception that they don’t have the time to take for much team reflection and a Socratic type of guidance.

Deadlines, But No Tempo

I have only recently started to present the idea I comment upon below when I teach classes and otherwise discuss development work with people. I’m not sure why it took me so long to recognize this comparison between the traditional phased-sequential (i.e., waterfall) and Agile approaches to development. But it seems an important point.

Traditional phased-sequential approaches to development have many deadlines/milestones as targets for work, but specify no expected tempo for getting work done between those milestones. Agile methods show considerable concern for establishing a work tempo which replaces most of the date-driven milestones in traditional approaches.

To me, the focus on milestones is less desirable than a predictable tempo because distance between milestones will vary from project to project based on the overall size of the work to be done by the final project delivery milestone. Agile’s main milestone is the iteration which is always (supposed to be) the same length. So teams get used to producing some defined result, regularly, at this tempo.

In traditional milestone-driven projects, the weekly/bi-weekly status meeting might be viewed as establishing some sort of tempo, but what is expected to be done between such events is not a delivery of value/product. So I do not view status meetings as having the same tempo impact as iterations.

A predictable tempo seems to me to encourage more of a team approach to work. Milestones allow more individual work expectations using milestones as coordination points. Of course, the time between such coordination points allows a lot of work to be done before coordination occurs and, as noted above, the time between such points will not necessarily be consistent within or between projects. I believe the inconsistency, extended time periods, and individual task focus work against effective coordination.

At least, it places greater burden on individuals to establish coordination behavior ad hoc. On the one hand, coordination is expected to occur. On the other, individuals view any work tempo to be personal. Coordination efforts in this context seem more difficult because they are not collaboration within an agreed upon tempo, but negotiation between individually accustomed to tempos. In such negotiation, some people are almost guaranteed to feel they have “lost”. (And, truthfully, this may be why some people find moving to an Agile approach problematic. The tempo of an iteration is not their natural one and, though it is not the other team members who have imposed the iteration concept on them, someone has.)

This leads me to believe that some talk about individual work styles and tempos is an important part of the “forming” stage for a team. Everyone much fit into the iteration length’s tempo. Discussing how to support and help one another do that, then, seems to me to be an important aspect of team-building in an Agile context.

I don’t hear people talk about this much, but I do believe I see consequences of it in daily work discussions, ability to deliver on commitments, etc. Because there are consequences for not overtly recognizing this, I think it should be discussed when teams are getting started. And certainly think the concept of milestones vs tempo is important for an organization to discuss when deciding to embark on an Agile approach to their development.

Last Quotes From Twitter

Not because folks aren't saying great things still, but I think I've run this idea into the ground and doing this last, very short, set will be a way to start my blog up again after several months of regrettable inactivity.

@FunnyOneLiners - A mighty oak is the result of a nut that held it's ground.

Abraham Williams - Sometimes I write a letter on paper with a pen then burn it laughing about how Google must be crying over information it will never index.

Albert Einstein (via Jason Yip) - The formulation of a problem is often more essential than its solution...

Albrecht & Zemke (via @ASQ) - People do not just buy things, they also buy expectations.

Bob Marshall - Agile successes - or not; echoes of Rashomon?

Dale Emery – The values (then the principles, then the practices) stand at the brink and wave goodbye as the name moves on. Michael Bolton - I said a couple years back that Agile hasn't crossed the chasm; it's mostly fallen in. But the name made it across.

David Joyce - Toyota manager induction doesn’t take place in a room but instead 12 weeks are spent in the work being coached on how to solve problems.

G. K. Chesterton (via Jason Yip) - There are two ways to get enough: One is to continue to accumulate more and more. The other is to desire less.

Glyn Lumley - The manner in which employees treat customers is determined, in part, by the norms for handling internal conflict and frustration.

James Bach - If you don't have a clear goal in life-- then watch out!-- you might wander and learn cool things that no one anticipated. Payson Hall (replied with this from Tolkien) - Not all those who wander are lost.

Jay Arthur - At one time, customers wanted you to be better, faster and cheaper. Now, they want everything free, perfect and now.

Michael James (actually from a mailing list talking about Scrum and Kanban) - I'm not sure it matters too much whether someone edits with vi or emacs, as the real challenge is what's in the file.