tag:blogger.com,1999:blog-2249283985137038502024-02-08T00:31:39.830-05:00Agile Software QualitiesSome things old, some things new, some things borrowed...
Combining an agile approach and classic quality concepts.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.comBlogger60125tag:blogger.com,1999:blog-224928398513703850.post-53718881103851482142017-08-14T11:22:00.000-04:002018-08-30T06:04:21.719-04:00<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div align="center" class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Agile 2017 Session
Notes (and thoughts)<o:p></o:p></span></b></div>
<br />
<div align="center" class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Thoughts
on volunteering and how that directed some sessions I attended<o:p></o:p></span></b></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">For the first time, I
went to an Agile conference as a volunteer.<span style="mso-spacerun: yes;">
</span>I’ve been a speaker in the past, but never a volunteer, so I wanted to
see what the experience would be like.<span style="mso-spacerun: yes;"> </span>I
enjoyed it quite a bit.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.</span><br />
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"></span><br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>That was a busy
experience that helped the 6am-2pm time I was there go by quickly.<span style="mso-spacerun: yes;"> </span>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).<span style="mso-spacerun: yes;"> </span>Since my goal was to attend all the Stalwarts
sessions I could (described below) this approach worked
well.</span></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">On Wednesday, I had
hoped to attend the last of the Stalwarts sessions by working that room.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.</span><br />
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"></span><br />
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"></span><span style="font-family: "arial" , sans-serif; font-size: 10pt;">I also attended the
Monday and Wednesday keynotes by David Marquet and Jez Humble.<span style="mso-spacerun: yes;"> </span><span style="font-size: 13.3333px;">I skipped the Friday keynote speaker to get caught up on emails as I had</span> recently viewed the Youtube video of her
June 16 talk in Oslo on the same subject.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.]</span></div>
<div align="center" class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">The Monday
Keynote <o:p></o:p></span></b></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Monday, the keynote was
given by David Marquet, a former US Navy submarine Captain.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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).<span style="mso-spacerun: yes;"> </span>He was then given a totally different sub to
command where he knew little about how it operated.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>(You can see his
whole presentation on the </span><a href="https://www.agilealliance.org/agile2017/"><span style="color: #0070c0; font-family: "arial" , sans-serif; font-size: 10pt;">Agile 2017 website</span></a><span style="font-family: "arial" , sans-serif; font-size: 10pt;"> for this and other
anecdotes.)<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>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.”<span style="mso-spacerun: yes;"> </span>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. <span style="mso-spacerun: yes;"> </span>(He mentioned a less disastrous example:<span style="mso-spacerun: yes;"> </span>the “all hands” meeting usually intended to
build consensus and reduce variability.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;">
</span>One early statement he in his talk made was: “Intent engages thinking
and creates a bias for action.”<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.”<span style="mso-spacerun: yes;"> </span>He did say that true
self-organization, however, requires competence and clarity and that “being
good crowds out getting better.”<span style="mso-spacerun: yes;"> </span>(The
latter reminded me of the Japanese quality philosophy that improvement does not
come from satisfaction.)<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Later in the day, at
the evening social,” Marquet was signing copies of his book (<i style="mso-bidi-font-style: normal;">Turn the Ship Around</i>) at a vendor
booth.<span style="mso-spacerun: yes;"> </span>The book was selling much lower
than retail and he was there, so I bought a copy right away.<span style="mso-spacerun: yes;"> </span>I was going to go to Amazon and have it home
when I returned anyway (along with the accompanying workbook, <i style="mso-bidi-font-style: normal;">Turn Your Ship Around</i>).<span style="mso-spacerun: yes;"> </span>I’m glad I did since I started reading it
later that night and at various times during the week.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>Context is always helpful when organizational
change is involved.</span></div>
<div align="center" class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">The Monday
Stalwarts Sessions <o:p></o:p></span></b></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">The sessions were held
in rooms restricted to about 100 attendees with the speakers sitting in the
middle in a “fishbowl” structure.<span style="mso-spacerun: yes;"> </span>That
is, the whole approach was without presentation or formality.<span style="mso-spacerun: yes;"> </span>People would come up to 2-4 chairs by the
speaker and ask a question which the speaker would answer.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>One session moderator even had attendees pair
up and discuss possible questions, then used a randomization approach to choose
what questions got asked.<span style="mso-spacerun: yes;"> </span>(I don’t think
people really liked either one of these moderator-curated approaches compared
to the traditional fishbowl approach.)</span><br />
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><o:p></o:p></span><br />
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">As I mentioned
previously, the Stalwarts sessions were my major focus for the Conference.<span style="mso-spacerun: yes;"> </span>The speakers were to be people I have
known/heard over many years and have always found interesting to listen to
during that time.<span style="mso-spacerun: yes;"> </span>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.”<span style="mso-spacerun: yes;"> </span>I got interesting,
and all different, answers, sometimes without even asking the questions myself.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Monday’s speakers were
Ron Jeffries and Chet Hendrickson, Steve Denning, and Dean Leffingwell.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<i style="mso-bidi-font-style: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Ron and Chet</span></i></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">I didn’t actually get
to ask Ron and Chet my question, but they seemed to answer it in answering
other questions.<span style="mso-spacerun: yes;"> </span>One thing Ron said
right at the outset was to emphasize frequent working software.<span style="mso-spacerun: yes;"> </span>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.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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).<span style="mso-spacerun: yes;">
</span>They both agreed that “time-boxes are your friend.”<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>I think he felt that, if you brought together
the right people, what happens would be(come) the right thing.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>That should motivate Product Owners to work
to eliminate impediments.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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).<span style="mso-spacerun: yes;"> </span>They’d get the
funding, but turn over a lot of the product to the teams.<span style="mso-spacerun: yes;"> </span>Ron stated that Kent Beck once said the
biggest mistake in XP was the dichotomy between the team and customer (or PO in
Scrum).<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>(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.<span style="mso-spacerun: yes;"> </span>At the
end of each week, the customer does the weekly demo of what the team
accomplished.<span style="mso-spacerun: yes;"> </span>If the customer struggled
to do that, they felt they had failed.<span style="mso-spacerun: yes;">
</span>Go read the CEO’s book entitled <i style="mso-bidi-font-style: normal;">Joy</i>;
it has a lot of interesting information about how Menlo Innovations operates.)</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<i style="mso-bidi-font-style: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Steve Denning</span></i></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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 - ?).<span style="mso-spacerun: yes;"> </span>Regarding the latter, he encouraged us to
think of “managers as enablers” rather than commanders.<span style="mso-spacerun: yes;"> </span>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.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>However, he did suggest one should “go with
the champions” and ignore the laggards in organizations.<span style="mso-spacerun: yes;"> </span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<i style="mso-bidi-font-style: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Dean Leffingwell<o:p></o:p></span></i></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">I do not know
Dean.<span style="mso-spacerun: yes;"> </span>I know of him having read much
about SAFe and having reviewed a video series he did several years ago.<span style="mso-spacerun: yes;"> </span>My encounters with some people practicing
SAFe, including speakers at a couple conferences I’ve attended, have not endeared
me to SAFe.<span style="mso-spacerun: yes;"> </span>However, I have greatly
appreciated hearing Dean speak.<span style="mso-spacerun: yes;"> </span>He has
clearly though a lot about making Agile successful in larger contexts than
individual (or just a few) teams.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>That eventually came up.</span><br />
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"></span><br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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).<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>Feedback was important and he spoke of
feedback compared to what he called “assumption-driven development.”</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">He was clear that a
lean/Agile transformation will not work without everyone being on board.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;">
</span>In SAFe, responsibilities are much the same, but the way they are
implemented is different.<span style="mso-spacerun: yes;"> </span>SAFe’s main
assumption is that many teams are working together to accomplish something
big.<span style="mso-spacerun: yes;"> </span>Hence, as he put it, the “goal
isn’t for the teams to Sprint alone, but for the system to Sprint.”</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">When the question was
asked why so much SAFe “hate,” Dean said SAFe was “disruptive to the
marketplace.”<span style="mso-spacerun: yes;"> </span>This suggested a lot of
the “hate” was coming from other established approaches and their proponents in
the face of SAFe’s success.</span></div>
<div align="center" class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">The
Tuesday Stalwarts Sessions </span></b></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Tuesday’s speakers were
Arlo Belshee, Kupe Kupersmith, Linda Rising, and Alistair Cockburn.</span></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><br />
<more added="" be="" soon="" to=""></more></span><br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><i style="mso-bidi-font-style: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Arlo Belshee</span></i></span><br />
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><i style="mso-bidi-font-style: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;"></span></i></span><br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">The first time I met
and heard Arlo speak was at an early Agile Roots conference in the Salt Lake City
area.<span style="mso-spacerun: yes;"> </span>We ended up together doing some
impromptu sessions for a company from that area which has sent several of his
managers to the Conference.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>His advice was C# and Python, both of which
I’ve had some chance to work with since.<span style="mso-spacerun: yes;">
</span>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.<span style="mso-spacerun: yes;"> </span>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.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>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).<span style="mso-spacerun: yes;">
</span>Second, he felt that one needed a stronger evidence than testing can
provide when refactoring.<span style="mso-spacerun: yes;"> </span>I need to look
into this latter point more for the greater sophistication his answer provided
than I can relate here.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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].”<span style="mso-spacerun: yes;">
</span>A team needs to “own its own destiny,” i.e., its process, as much of the
product as it can, etc.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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).</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">There was another
series of questions related to organizational hierarchy.<span style="mso-spacerun: yes;"> </span>“Hierarchy,” Arlo said, “is how you scale
authority-driven decision-making.”<span style="mso-spacerun: yes;">
</span>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.<span style="mso-spacerun: yes;"> </span>A flattened structure is just a variation on
hierarchy as opposed to what he called a “co-op” approach.<span style="mso-spacerun: yes;"> </span>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.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">(Regarding hierarchy, I
need to check into something Arlo said about its roots in the Prussian military.<span style="mso-spacerun: yes;"> </span>He said there were two issues it and the
associated command and control associated, solved:<span style="mso-spacerun: yes;"> </span>desertion and weak information flow.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.)</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Arlo ended with a roleplay
using volunteers from the audience. He started by asking “What rights do you
think you have?<span style="mso-spacerun: yes;"> </span>What happens if you honor
others’ rights but ignore yours? What if you honor yours and ignore others’?<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;">
</span>In the former you assert your rights more than others.<span style="mso-spacerun: yes;"> </span>In the next you honor others’ more than
yours.<span style="mso-spacerun: yes;"> </span>But the latter results in honoring
yours and theirs.<span style="mso-spacerun: yes;"> </span>He then asked a person
adopt one of the stances while another took one of the others and had them
discuss a situation:<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>After
they took their positions for a short while, he stopped them and asked how they
both felt about the interaction.<span style="mso-spacerun: yes;"> </span>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.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">[In looking at my notes
I was surprised at the length of them for Arlo’s session compared to most of
the others.<span style="mso-spacerun: yes;"> </span>A lot got packed into 75
minutes.]</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><i style="mso-bidi-font-style: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Kupe Kupersmith</span></i></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Kupersmith was the one
speaker I really knew next to nothing about, though I had heard the name.<span style="mso-spacerun: yes;"> </span>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).<span style="mso-spacerun: yes;"> </span>He began by
asking us to form ourselves into four corners of the room in response to two
questions he asked.<span style="mso-spacerun: yes;"> </span>Turns out, this
divided us into the 4 main types in the DISC personality profile.<span style="mso-spacerun: yes;"> </span>There was some lengthy discussion about what
this meant for connecting with other people.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;"></span><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Soon after that he made
a comment about both working and trying to keep up with change: “We’re never
fast enough.”<span style="mso-spacerun: yes;"> </span>Which suggested to me, at
least, that focusing on trying to be faster might be distracting too much from
other things.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.”<span style="mso-spacerun: yes;"> </span>(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.)</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>Suggested
we improve our networking in one way by listening for “offers,” i.e.,
opportunities to make connections.<span style="mso-spacerun: yes;"> </span>One
live example was a person who asked about applying Agile ideas to
education.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>[I’ve been in touch with Kupe and he provided
me with contacts already on that topic including the agileineducation.org
website.]</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>One was
something from Steve Denning: “What is keeping you up at night?” Or something
like “What drives you?”<span style="mso-spacerun: yes;"> </span>[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?”<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>He had us all
pick one other person and try this for about 30 seconds.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><i style="mso-bidi-font-style: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Linda Rising</span></i></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">I had not heard Linda
speak in quite a while and never in a fishbowl type of session.<span style="mso-spacerun: yes;"> </span>I was amazed to be reminded about how calmly
and peacefully she could be “assertive” (using Arlo’s term).<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>Linda said that Oettingen’s work suggested
passion and wishing make it less likely we’ll succeed rather than more so[…sorry
Jiminy]</span><span style="font-family: "arial" , sans-serif; font-size: 10pt;">.<span style="mso-spacerun: yes;"> </span>WOOP was Oettingen’s suggestion
for how to increase the likelihood of success.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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).<span style="mso-spacerun: yes;"> </span>One was “What
made your result awesome?”<span style="mso-spacerun: yes;"> </span>The other was
“What made your result disappointing?”<span style="mso-spacerun: yes;">
</span>Then, of course, you consider how you can make the first true and
eliminate what will make the latter true.<span style="mso-spacerun: yes;">
</span>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.<span style="mso-spacerun: yes;"> </span>This is a kind of
root cause approach.<span style="mso-spacerun: yes;"> </span>Linda recommended “small
experiments,” rather than root cause, to improve.<span style="mso-spacerun: yes;"> </span>[Several of the Stalwarts speakers used the
word “experiment” during their sessions in one way or the other.]</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>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.”<span style="mso-spacerun: yes;"> </span>I remind them retrospectives are about
improving not just fixing things.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;">
</span></span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><i style="mso-bidi-font-style: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Alistair Cockburn</span></i></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">It was the Agile
Development Conference in Salt Lake City in 2004 when I first met/heard
Alistair.<span style="mso-spacerun: yes;"> </span>I had read several things he
and Jim Highsmith had written and was eager to hear them speak.<span style="mso-spacerun: yes;"> </span>Most of that early Conference (and several to
follow) were strongly Open Space structured, but there were some more
presentation-style sessions.<span style="mso-spacerun: yes;"> </span>Since then,
I think I’ve read all of Alistair’s books and many of his articles and blog
posts. <span style="mso-spacerun: yes;"> </span>I’ve also heard him speak many
times since then and even been in some workshops with him as another
attendee.<span style="mso-spacerun: yes;"> </span>Like all the other Stalwarts
speakers, I don’t recall any occasion when he did not say several things I
noted down.<span style="mso-spacerun: yes;"> </span>This session was no exception.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>See his blog about this with some interesting
twists to how one’s focus can change: <a href="http://alistair.cockburn.us/Blindfolded+at+the+Table/v/slim"><span style="color: #333333;">http://alistair.cockburn.us/Blindfolded+at+the+Table/v/slim</span></a>.
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.<span style="mso-spacerun: yes;">
</span>Alistair suggested we should consider we are not “Done” until we know
the impact of that delivery.<span style="mso-spacerun: yes;"> </span>A
significant gap between those last two will diminish the learning teams
experience.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>He said his next book would be called <i style="mso-bidi-font-style: normal;">Team Work</i>, noting the space between the
words emphasizing how teams work together more effectively.<span style="mso-spacerun: yes;"> </span>(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.<span style="mso-spacerun: yes;">
</span>In conjunction with this he spoke of three “doors” to Agile: Shu (from
Shu-Ha-Ri), play, and Kokoro (heart).<span style="mso-spacerun: yes;">
</span>The latter is also described as <span style="color: black; mso-themecolor: text1;">“a Japanese word connecting mind, body, and spirit … also driving
scientific discovery.”<span style="mso-spacerun: yes;"> </span>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.</span></span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="color: black; font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>He said Scrum, for example, was
defined at the RI (mastery) level where teams might work it differently.<span style="mso-spacerun: yes;"> </span>Scaling often necessitates conformity and consistency
which is not what Agile was intended to address.<span style="mso-spacerun: yes;"> </span>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).</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="color: black; font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;">
</span>Check his recent presentation on the Heart of Agile at <a href="http://alistair.cockburn.us/get/3645"><span style="color: #333333;">http://alistair.cockburn.us/get/3645</span></a>.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="color: black; font-family: "arial" , sans-serif; font-size: 10pt;">One of the people who can up and asked a question was Arlo Belshee.<span style="mso-spacerun: yes;"> </span>Several things were discussed with Alistair
pulling more from Arlo, including going back to Arlo’s three stances (aggressive,
non-assertive, assertive).<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;">
</span>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.</span></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="color: black; font-family: "arial" , sans-serif; font-size: 10pt;">Finally, Alistair responded to a question by noting how he described
Scrum to Ken Schwaber (who he said liked the explanation).<span style="mso-spacerun: yes;"> </span>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.</span></span></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "times new roman"; font-size: small;"></span></span><br />
<div style="text-align: center;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "times new roman"; font-size: small;"><b style="mso-bidi-font-weight: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Part 5 of 7: The
Wednesday Keynote</span></b></span></span></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><span style="font-family: "times new roman"; font-size: small;">
<div style="text-align: center;">
</div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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 <a href="https://www.slideshare.net/jezhumble/continuous-delivery-sounds-great-but-it-wont-work-here"><span style="color: #333333;">https://www.slideshare.net/jezhumble/continuous-delivery-sounds-great-but-it-wont-work-here</span></a>
and a video of him giving the talk using these slides at </span><span lang="EN" style="font-family: "arial" , sans-serif; font-size: 10pt;"><a href="https://vimeo.com/193849732"><span style="color: #333333;">https://vimeo.com/193849732</span></a>.<span style="mso-spacerun: yes;"> </span>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.)</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>Humble began with the first four: (1) </span><span lang="EN" style="font-family: "arial" , sans-serif; font-size: 10pt;">we're regulated, (2) we’re not building websites, (3) too much legacy, and
(4) our people are too stupid.<span style="mso-spacerun: yes;"> </span>(He
really didn’t address the “real” reasons directly but through examples,
especially in addressing the fourth “excuse” about people.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span lang="EN" style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>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.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span lang="EN" style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>One challenge he mentioned was
convincing developers to work in small batches which he said was hard to
do.<span style="mso-spacerun: yes;"> </span>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.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span lang="EN" style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>The video talked about “creating 10,000
policies in a short time to do such testing.<span style="mso-spacerun: yes;">
</span>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.<span style="mso-spacerun: yes;"> </span>This is how
Amazon restructured their architecture according to Humble.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span lang="EN" style="font-family: "arial" , sans-serif; font-size: 10pt;">The final stated reason (are people are too stupid) was addressed by
starting off saying “Well, whose fault is that?”<span style="mso-spacerun: yes;"> </span>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.”<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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].</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span lang="EN" style="font-family: "arial" , sans-serif; font-size: 10pt;">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.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>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.</span></div>
<div align="center" class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt; text-align: center;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><br />
<b style="mso-bidi-font-weight: normal;"><span style="mso-spacerun: yes;"> </span>Part 6 of 7: The Wednesday Stalwarts Session</b></span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">After the keynote, the
one Stalwarts speaker I heard (as the volunteer in the room) was David Hussman.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>This time, questions posed to him went in a
different, though equally interesting, direction which, to me, w</span><span style="font-family: "arial" , sans-serif; font-size: 10pt;">as 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:</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Stop delivering late
and blaming other people.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Stop lying to one
another (about the testing that’s been done).</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">You’re not a good
soccer team because you know the rules.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">If nobody’s touched
[some piece of] code in 6 months, delete it [, i.e., do we really need it
then?]</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">IT & business vs
product & customer(s)</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">We need people able to
work across [organizationally] not just vertically [within their silos].</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Learning inside vs
outside the code.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">“Shut up and play the
guitar” – show, not tell [David used to work for Prince.]</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Cultures change when
people see success.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Investment in software
products isn’t a given return.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Produce meaningful evidence.</span></div>
<div align="center" class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Part 7 of 7: The
Audacious Salon Sessions <o:p></o:p></span></b></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Wednesday afternoon and
all day Thursday, I was in the room where the Audacious Salon sessions were
held.<span style="mso-spacerun: yes;"> </span>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.”</span><br />
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"></span><br />
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"></span><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Some topics were a
single session in length, others took two.<span style="mso-spacerun: yes;">
</span>Topics earlier in the week were: #NoEstimates, Making Products without
Words, Polarizing Topics, Moving from “technical debt” to “technical health,”
Innovation Killer Among Us.<span style="mso-spacerun: yes;"> </span>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.</span><br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>A couple things I did
overhear and feel confident repeating without concern for privacy, etc. are the
following:</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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).</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">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.<span style="mso-spacerun: yes;"> </span>People of an outward-seeming similar "race" might consider their marriage "interracial" because
of their very different cultural backgrounds.</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Improv means to “Offer
your ideas and opinions in a manner that increases the opportunities for others
to do the same.”</span></div>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">“These are choices made
by an organization, not laws of physics.<span style="mso-spacerun: yes;">
</span>You can make other choices.”</span></div>
<div align="center" class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="font-family: "arial" , sans-serif; font-size: 10pt;">Conclusions<o:p></o:p></span></b></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">Well, I leave that
mostly to you based on what ideas stuck you as useful.<span style="mso-spacerun: yes;"> </span>My own conclusion is that it might be the
most valuable Agile 20xx conference I have attended.<o:p></o:p></span><br />
</span> </span> </div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">
</span>
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<span style="font-family: "arial" , sans-serif; font-size: 10pt;"><br /></span></div>
<span style="font-family: "arial" , sans-serif; font-size: 10pt;">
</span><br />
<div class="MsoNormal" style="line-height: normal; margin: 0in 0in 6pt;">
<br /></div>
</div>
Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-60887238214090304852016-02-15T16:57:00.000-05:002017-08-14T18:50:11.895-04:00Back to Basics<div dir="ltr" style="text-align: left;" trbidi="on">
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").<br />
<br />
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.<br />
<br />
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.</div>
Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-2613982718339484792011-09-28T13:28:00.000-04:002011-09-28T13:28:09.429-04:00“People Don’t Shop for Organizational Change”I was talking about coaching experiences yesterday with Skip Angel.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>Something like Agile, for example.<br />
<br />
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.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.<br />
<br />
This usually results in attempts to immediately “tailor” the chosen approach and produce a “hybrid” version of what has been selected.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>The resulting tailoring and hybrid practices can then miss the point of the originally recommended practices, often losing the impact intended.<span style="mso-spacerun: yes;"> </span>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.<br />
<br />
I think one reason organizations ending up in this situation is that they, indeed, didn’t start out “shopping for organizational change.”<o:p></o:p>Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com6tag:blogger.com,1999:blog-224928398513703850.post-24031749693523133062010-11-27T11:18:00.001-05:002010-11-27T12:16:29.438-05:00The 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:<br />
<br />
<ul><li>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.</li>
<li>The work being done by people before the Manifesto existed wasn’t about “agility” but was about more effective, productive software development.</li>
<li>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.</li>
<li>Most of the ideas in the Manifesto can be found elsewhere, especially in Lean ideas, so they should not be regarded so permanently.</li>
<li>The Value statements are so easy to agree with that they are, essentially, “content-free.”</li>
<li>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.</li>
<li>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.</li>
</ul>And the list can go on and has at various times.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
So, by all means don’t stop at the Manifesto, but don’t assume it is somehow the problem or the impediment to growth.<br />
<br />
[* The title is derived from a Tweet by Jason Yip.]<br />
<br />
[** When I say “Manifesto,” I include both its explicit Values and the associated 12 Principles that followed unless a distinction is otherwise made.]<br />
<br />
[*** 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é.]Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-20813901795505000152010-11-26T07:18:00.001-05:002010-11-26T07:20:43.746-05:00Letting Them Figure It OutA 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.,<br />
<br />
<em>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 <a href="http://www.answers.com/topic/socratic-method">http://www.answers.com/topic/socratic-method</a>.]</em><br />
<br />
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.<br />
<br />
But this raises the following questions:<br />
<ol><li>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”?</li>
<li>Indeed, how many open issues are “too many” for them?</li>
<li>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)?</li>
</ol>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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
I believe every team I have ever been involve with, Agile-based or not, has been somewhat astonished at my suggestions that<br />
<ol><li>they only presume a 6, not 8, hour productive day in their estimation, so a 30, not 40, hour week;</li>
<li>within this 30 hour week they commit to less than 100% of that in functionality terms, especially when they are new to this approach;</li>
<li>they do not presume to commit overtime at the outset as a way to deal with the fixed schedule and functionality.</li>
</ol><br />
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.<br />
<br />
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.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-33248356938561490202010-11-04T10:43:00.000-04:002010-11-04T10:43:09.004-04:00Deadlines, But No TempoI 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.)<br />
<br />
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.<br />
<br />
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.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-73006984997891899352010-11-04T08:05:00.000-04:002010-11-04T08:05:42.513-04:00Last Quotes From TwitterNot 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.<br />
<br />
@FunnyOneLiners - A mighty oak is the result of a nut that held it's ground.<br />
<br />
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.<br />
<br />
Albert Einstein (via Jason Yip) - The formulation of a problem is often more essential than its solution...<br />
<br />
Albrecht & Zemke (via @ASQ) - People do not just buy things, they also buy expectations.<br />
<br />
Bob Marshall - Agile successes - or not; echoes of Rashomon?<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Glyn Lumley - The manner in which employees treat customers is determined, in part, by the norms for handling internal conflict and frustration.<br />
<br />
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.<br />
<br />
Jay Arthur - At one time, customers wanted you to be better, faster and cheaper. Now, they want everything free, perfect and now.<br />
<br />
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.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com2tag:blogger.com,1999:blog-224928398513703850.post-17058907993885218422010-06-28T16:39:00.001-04:002010-06-28T16:40:37.441-04:00Gad...Yet More Quotes from TwitterBeen too long since I posted anything. But, fortunately, I have been very busy with work and still digging out from under a move to a much smaller place. I said it a few months ago, but I hope to turn posting to this blog into a more regular habit.<br />
--------------------------------------------------------------------------------------<br />
<br />
@funnyoneliners - When asked "What would you bring with you to a deserted island", how come no one ever replies, "A boat."?<br />
<br />
Alan Cooper - Art always contains craft, but not vice versa.<br />
<br />
Bob Martin - Any meaningful certification must be hard to acquire with a significant chance of failure. I wonder what the CSD failure rate will be...<br />
<br />
Bob Martin - Once any word, like "agile" or "Object" or "Structured" becomes synonymous with "Good" it has lost all meaning.<br />
<br />
Bob Martin - Second law of meetings: Meetings are for decisions. If you don't know what's to be decided, don't go. If no decision is proposed, leave.<br />
<br />
Brad Burt - In the 'Art of the Effect' in magic, less is almost always MORE. It has to do with purity and thus the ease of a watchers acquisition of what has happened. Amazement is knowledge of a kind.<br />
<br />
Brian Marick - The original sin of Agile is that small nimble companies don't pay consultants enough, so all the attention is to the lumbering dinosaurs. James Shore - Such truth in @marick's tweet. Explains "Agile" plan tools, watering down of Agile, desire to "scale" mediocrity. Not only reason, natch. [Brian noted “original sin” term not right one. Other noted consultant focus wasn’t real point, it was “dinosaur” focus.]<br />
<br />
Brian Marick (at goosgaggle ) - design happens in writing the test - implementation is just stenography.<br />
<br />
David Hussman - Many companies need to slow down to get more done.<br />
<br />
Dawn Cannon - The purpose of planning is not to prevent uncertainty, but rather to plan how to deal with uncertainty.<br />
<br />
Esther Derby - managers are designers of the experience of work.<br />
<br />
Esther Derby - Resistance = "Other people are not doing things I want them to do w/ the speed or enthusiasm that I desire."<br />
<br />
FunnyOneLiners - It's not easy taking my problems one at a time when they refuse to get in line.<br />
<br />
Hannu Kokko - Partial conditions of satisfaction for a demo: understandable, valuable for customer, wow-factor, shows progress<br />
<br />
Hillel Glazer (heard at SE{G NA) - Proposal to add a new value to manifesto: "we value improvement over compliance"<br />
<br />
Ian E. Savage - Certifications are only as good as the certifying agency. Got it. Let’s move on, shall we.<br />
<br />
James Bach - A lot of my choices are about arranging life so instead of having to control my anger, I don't have anger that needs controlling.<br />
<br />
James Bach (at #accu2010 via Tom Gilb) - 'it is Testers Job to not be fooled by What is fooling everyone else'. 'testing is about discovering the significance of the requirements'. ‘The spec is a rumor! Wouldn't you like to know what the code ACTUALLY does before you ship?’<br />
<br />
James Bach (at StarEast via Matt Heusser) - "bad rigor is following instructions without understanding them", or "pathetic compliance"<br />
<br />
Jared Richardson – Overheard: Jenga development. You're not sure which piece will bring it all down, so you resist any changes no matter what.<br />
<br />
Jason Gorman (via Hannu Kokko & Kent Beck) - Knowledge of languages and APIs no more makes you a developer than knowledge of anatomy makes you a doctor.<br />
<br />
Jerry Weinberg - When managers don't understand the work, they tend to reward the appearance of work. (long hours, piles of paper, ...)<br />
<br />
Joseph Angel Alcala - Apologizing always doesn't mean you wrong and others right...means you respect relationship more than your ego.<br />
<br />
Ken Schwaber (in a recent podcast, reported by Tobias Meyer) - Scrum is less a silver bullet and more an enema.<br />
<br />
Kent Beck (via Jon Udell) - There's no difference I can see but there's obviously a difference the computer can see. I hate that.<br />
<br />
Marcus Ahnve (via Lasse Koskela) - Feedback without conversation is criticism.<br />
<br />
Mark Levison (re: Agile retrospectives) - I ask "what needs improvement" and focus is on discovering issues. Next I ask "What does team have energy to improve". Then they create action plan.<br />
<br />
Michael Bolton - The *number* of test cases that are passing or failing has no more meaning than the *number* of ideas you had in the shower.<br />
<br />
Michael Feathers (via Jurgen Appelo) - If you don't give your software a shape, it's going to get a shape anyway. The reason most of our code sucks is that we don't take ourselves seriously as users of our code. Constraints drive design. TDD is an example of a constraint (testable code), and design thrives in constraints.<br />
<br />
Morrell (via Jesse Fewell at InfoTech2010) - your team doesn't care how much you know, until they know how much you care.<br />
<br />
Naresh Jain - Little things make big things possible. Close attention to fine details brings out excellence in your craft.<br />
<br />
Payson Hall - Pondering process improvement/decay cycle oscillation: +Pain > +motivation > +rigor > -pain > -motivation > -rigor > +pain... (repeat)<br />
<br />
Peter Scholtes (via Glyn Lumley) - Explaining why change is important will not make the change happen.<br />
<br />
Phillip G Armour - and testing is also about finding out how to find out something you don't know you don't know.<br />
<br />
Stephen King (via Peter Murphy) - If you don't have the time to read, you don't have the time or the tools to write.<br />
<br />
Stephen Mann (via Anna Nachesa) - Love the old management saying ... meetings - where minutes are saved and hours are lost.<br />
<br />
Tom Kealey - Instead of asking the question "how agile are we?" try "how are we agile?" The difference is profound.<br />
<br />
Woody Williams - The absence of failure is not an indication of success.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-57326446786008270112010-03-14T11:20:00.001-04:002010-03-14T11:20:50.707-04:00Newer Set of Quotes from TwitterMany things happening over the past couple of months, including becoming a grandfather. But also preparing for what looks to be a lengthy Agile/Scrum coaching assignment. So here's yet another set of quotes from Twitter posts in, again, alphabetical order by first name.<br />
-------------------------------------------------------------------------------<br />
<br />
Alan Cooper - Lean is related to "efficiency" which seems to me an industrial age concept. Bob Marshall - Imo Lean is much more about *effectiveness* than efficiency, hence my #rightshifting campaign, not least.<br />
<br />
Alan Shalloway - if your team is populated by heroes your process will require them.<br />
<br />
Alan Shalloway - sometimes being heroic is just another way of avoiding prioritization. Scott Duncan - Or is a sign of not recognizing the need to prioritize?<br />
<br />
Ash Maurya - Build [features] in response to a signal from the "customer", and otherwise rest or improve.<br />
<br />
Bob Martin (on liking one-week iterations) - "not much can go wrong in a week"<br />
<br />
Brian Foote (in response to Alan Shalloway - There is a big difference between eliminating waste & not creating it in the first place.) - Fasting vs. Sanitation<br />
<br />
Brian Marick - If you have one really great idea and express it together with many dumb ideas, the dumb ideas get a free ride in ppl's minds. This is bad.<br />
<br />
Brian Marick - It's swell to be compulsive about "delivering value" but let's realize that "value" isn't a real thing out there in the world. "Value" is not an objective fact. It is a prediction, made by some people, about reactions of other people, over some time. George Dinwiddie - I think "value" is a subjective fact. It, of course, begs the question of whose value takes precedence. Brian Marick in response to Mike Hill - different words have different favorite tricks. "Value"s favorite is making opinion look like measurement. Brian Foote - "value" shines at not sounding like a waste of money. "business" too. Whereas, anything with "re-" in front of it sounds like a wasteful do-over. Refactor, Revise, Repair, Reengineer. Mike Sutton - re-birth, re-new, re-'why can we compete with the latest blah?' revisiting the old is a fact of life, we should embrace it.<br />
<br />
Carlton Matthews - when you are not living the life you dreamed you tend to envy the lives of others.<br />
<br />
Daniel Elliott (via Bob Martin) - Cope suggests a surgeon who has washed his hands still needs to concentrate on the scalpel (or architecture in our case!)<br />
<br />
Dave Nicolette - Velocity is a measure of a team's capacity to deliver, not a measure of activity. But velocity depends on having fixed-length time-boxed iterations. For a continuous flow process, I prefer cumulative flow.<br />
<br />
David Hussman - I find it interesting that software people tend to talk about "training" where educators talk about "teaching". Your thoughts are welcome. Ron Jeffries - training is possible, teaching is not. neither word is good. one can, at best, provide an occasion where learning is possible.<br />
<br />
Delavigne & Rob (via Glyn Lumley) - "We want to get Deming off the quality shelf and have him recognised for his contributions to a unique philosophy of life"<br />
<br />
Derek Wood - Any accommodation we make to doing Scrum well is indicative of an impediment that will need to be resolved at some point.<br />
<br />
J.B.Rainsberger - Irony alert: Most organizations learning Scrum are actually practising Waterfall in a manner quite similar to what Royce intended.<br />
<br />
Jeff Patton - Is the "definition of done" actually a "definition of built"? "Built" is when I get software, "done" is when I get benefit.<br />
<br />
Jonathan Bach - As a manager, my mantra always is: "You may report to me, but really, I work for you."<br />
<br />
Jonathan Bach - Scrabble analogy #1: Rarely can your most valuable test ideas (letters Q&Z) be easily put into words. Scrabble analogy #2: Sometimes a test (a word) has more value when it's placed on the boundaries (triple word score). Scrabble analogy #3: You get a bonus if you use all 7 letters to form a word (diverse techniques in one test is powerful).<br />
<br />
Jonathan Bach - There are no certified musicians, but we know skilled ones from unskilled ones. Still, execs just want sheet music, not the sound.<br />
<br />
Joshua Kerievsky - Faster velocity != better software development. Velocity metrics are a powerfully distracting illusion. Story point estimation is a confusing waste of time. Discussion, feature fat removal, bargain hunting are way more useful.<br />
<br />
Jurgen Appelo - Separating process (Scrum) from development (TDD etc) is a fine example of loose coupling. Developers should appreciate that.<br />
<br />
Mark O Oakes - A company's ability to collectively learn faster than its competitors may be only sustainable competitive advantage<br />
<br />
Mary & Tom Poppendieck (from Leading Lean Software Development) via Jason Yip – It is the overhead incurred to enable auditability that induces the waste, not the standards themselves.<br />
<br />
Mary & Tom Poppendieck (from Leading Lean Software Development) via Jason Yip – Randomly giving patients medication until they get better would not even be considered. And yet, we randomly give our work processes medicine, adding on more and more 'best practices,' until the processes seem to get better.<br />
<br />
Mary & Tom Poppendieck (from Leading Lean Software Development) via Jason Yip – The advantage which a commander thinks he can attain through continued personal intervention is largely illusory. By engaging in it he assumes a task that really belongs to others, whose effectiveness he thus destroys. He also multiplies his own tasks to a point where he can longer fulfill the whole of them. (actually a quote from Helmuth Von Moltke)<br />
<br />
Matthew Heusser - my Fathinlaw, a quality engineer at Ford, once told me the quality engineering discipline existed to product cmpny from execs<br />
<br />
Michael Bolton - Often enough, bugs aren't mistakes. Sometimes they're differences of opinion, discoveries, dilemmas, etc.<br />
<br />
Mike Sutton - i just got reminded of something that i forgot - thank you @netparr - agility is *not* about getting everything right, but being able to respond to them quickly and correctly when they go wrong.<br />
<br />
Nancy Duarte (via @johnnieb99, via Brian Stallings) - "If a slide contains more than 75 words, it has become a document."<br />
<br />
Naresh Jain - Increasing velocity is one thing and making your team more productive is another. Don't confuse one for another.<br />
<br />
Naresh Jain - Instead of asking how much its going to cost & how long its going to take, ask with 2 ppl for 2 months what can I get?<br />
<br />
Rosabeth Kanter - Change is a threat when done TO people, an opportunity when done BY them.<br />
<br />
Scott Adams (via David Hussman via maiasylba) - Creativity is allowing yourself to make mistakes. Design is knowing which ones to keep.<br />
<br />
Steve Jobs (via Scott Williams) - Your time is limited, don’t waste it living someone else’s life.<br />
<br />
Steven M. Smith - Effort chases measurement. Measurement chases the discussable. Core org diseases aren't discussable. Diseases elude cure (effort).<br />
<br />
Tim Ottinger - Axis: simple<---->complex is a count of structural parts & linkages, unaffected by naming, syntax, obviousness of solution. Axis: clear<----->perplexing is a measure of how easily one may comprehend the solution, aside from structural parts/linkages. A very brief routine may be simple and clear, or may be simple and cryptic. A long routine may be complicated and clear, or may be complicated and impenetrable. We find a certain synergy working in our favor in short, clear, simple routines. I would go so far as to say that brevity with clarity = elegance.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com3tag:blogger.com,1999:blog-224928398513703850.post-69279159686200036262010-01-14T10:19:00.000-05:002010-01-14T10:19:24.599-05:00Even Newer Set of Quotes from TwitterBeen far too long since I lasted posted anything, but there was a lot of moving going on in December and some other things so far in January. More moving is left, but I am going to promise to post more often. However, as I have another collection of quotes from folks on twitter, I thought I'd put them out before the list gets too long:<br />
<br />
Alan Shalloway - a process tells you to fix your problems is different than a process that gives you information on how to fix it.<br />
<br />
Alan Shalloway - There is a big difference between eliminating waste & not creating it in the first place.<br />
<br />
Alistair Cockburn (reported by Biran Marick) - Remember talk from about "micro-techniques". If I recall right, he said his observation of ppl like @kentbeck and @wardcunningham was that they gained great speed by doing many small things extremely well and quickly. Alistair Cockburn - Right & I could never develop that idea because micro-techniques come in xtremely context senstitive bushel-basket-loads not onezies.<br />
<br />
Bob Marshall - Imo Red Bead is profound because it has many layers; vain hope; delusions (all round); (false) pride; introspection; etc. Don Reinertsen - Profound and possibly dangerous. It intentionally creates a situation where the player's actions have no effect on outcome. Bob Marshall - Yes. But that's kinda the point, really? From Deming's perspective... Don Reinertsen - To some extent players are taught to accept variation rather than improving the process. (e.g. batch size reduction) Bob Marshall - Yes. But that's reality for most orgs and most workers. Variants on Red Bead can explore more "enlightened" scenarios. Don Reinertsen - The game certainly proves the methods Deming dislikes won't work. It also incorrectly shows SPC doesn't help outcomes. I think it would be more profound if outcomes had both controllable and variable components. Teach the middle way... Bob Marshall - For me, Red Bead is very Zen, in that it's point is left for the participants and audience to draw out themselves. I concur Red Bead fails to show benefits of SPC: In coaching, "ARC" reminds us Awareness -> Responsibility -> Commitment. I participated in an enlightening 15min workshop at Agile 2008 with teams and dice that could show SPC well (!RedBead). Karl Scotland - Red Beads useful to change thinking on purpose/demand/outcomes. Intentionally exaggerated scenario is powerful.<br />
<br />
Bob Martin - humans test creatively. Machines test reliably. Both are vital. Confusing the two is disaster.<br />
<br />
Carlton Matthews - overheard someone use this quote, "Don't ask me to cook dinner if I can't buy the groceries"<br />
Daniel Lapin (via Carlton Matthews) - The complacent are always conquered by the committed and the diffident are always defeated by the determined.<br />
<br />
Dave Rooney - Fair enough... knowledge is indeed power. Scott Duncan - And applied knowledge is powerful. I think more people know what to do than do it. How to transmit belief plus knowledge?<br />
<br />
David Anderson - in next decade aim to change focus to "manage rules of game" not "manage work" or "manage people" - Deming system design.<br />
<br />
Don Reinertsen (on “value”) - Economic view also allows Gilb's subjective dimension. A thirsty man will pay more for what is objectively the same water.<br />
<br />
Gary Hamel (from a retweet by Bob Marshall) - "In the absence of purpose, only thing that will disrupt the status quo is pain." <a href="http://tinyurl.com/yjes5zn">http://tinyurl.com/yjes5zn</a><br />
<br />
Jeff Bezos (via Jason Yip) - There are two kinds of companies, those that work to charge more and those that work to charge less.<br />
<br />
Jochen Schuchardt - We sometimes equate project mgmt with the visible planning artifacts. But the heart of it is people and relationships.<br />
<br />
Johanna Rothman (from her blog, ptd to from Twitter) - good interviews should make a candidate (and an interviewer) think, not sweat [preceeded by “Good interviews do not surprise people. Good interviews build rapport with a candidate, learn about a candidate, preferably with behavior-description questions and auditions. Maybe with hypothetical questions. Maybe with a meta-question.”<br />
<br />
Jon Bach - FB is an album for friends, Twitter is a coffee shop for colleagues.<br />
<br />
Kent Beck - there's a world of difference between telling me what to do and helping me learn by telling me what to do.<br />
<br />
Max Planck (via Michelle Sliger) - A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.<br />
<br />
Michael Feathers - I still think the best way to predict the future is to have friends in time zones ahead of you.<br />
<br />
Michael Feathers - If you want to learn from experts listen to their questions more than their answers.<br />
<br />
Ralph W Emerson (Via Alan Shalloway) - "As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble."<br />
<br />
Ramsey Show (via Carlton Matthews) - "Savings has to be done on purpose. Debt can just happen."<br />
<br />
Rob Myers - so the msg could be "slow down for quality & use quality to speed up"<br />
<br />
Ron Jeffries - If we write a great tester's tests before even writing the software, and ship when they run, have we found or prevented defects?<br />
<br />
Ron Jeffries - It is becoming clear that w sufficient disrespect, sarcasm, recalcitrance, we can stop any/t good from ever happening again.<br />
<br />
Roy Atkinson (via Noami Karten) - If each of us holds up a little bit of the world, it will weigh none of us down.<br />
<br />
Scott Duncan - Change may be hard as 1 change often causes/requires another, then another. What looked like absorbable change cascades.<br />
<br />
Scott Duncan - I think we can/should talk about both what is valuable to do & how best to do it. Being clear about what both mean. Don't see a need to create a dichotomy between the what & how as long as we realize the latter serves the former. Perhaps an uber-value [is] "We value being clear about what is important to accomplish over how we achieve that end"?<br />
<br />
Seth Godin (not from, but pointed to from, Twitter) - Organizations thrive on their ability to allow individuals to remain faceless. It permits them to act badly, not in the interest of their customers.<br />
<br />
Skip Angel - Decided that bug repositories are evil. Gives teams excuse 2 defer defects not show-stoppers. Don't all bugs cause workarounds 4 team/users?<br />
<br />
Skip Angel - While #scrum is based on empirical sys 4 learning, u must have values & principles 2 guide ur learning. Agile Manifesto does that. Chris Sterling - agreed. I am more interested in teams learning & changing rather than being "right"; a team will get better when focused on both.<br />
<br />
Stephen Parry (via Grant Rule) - "If you measure your business using averages, don't be surprised to find yourself running an average business.” <br />
<br />
Tobias Mayer - IMO waste is defined as 'work that adds no value for any stakeholder' (others restrict to 'for customer'). Much refactoring is waste ie rework.. due to commiting too early. Lunch breaks are not work, hence not waste.<br />
<br />
Tobias Meyer - Are agreements the same as rules, & if not, what's different? I've always found group rules to be unnecessary, in fact detrimental. Dale Emery - Agreements come from people who agree. Not all rules come from (explicit, negotiated) agreement.<br />
<br />
W. Edwards Deming (Via Glyn Lumley) - 'Examples teach nothing unless they are studied with the aid of theory. Most people merely search for examples .. to copy them'<br />
<br />
Ward Cunningham - Estimating is the non-problem that know-nothings spent decades trying to solve.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-82121013989608255902009-12-02T06:35:00.002-05:002009-12-02T06:37:24.701-05:00New Set of Quotes from Twitter[Been occupied with packing and moving since my last post until a couple days ago, though more packing and moving needed. Hopefully I'll get on a daily posting schedule before too long.]<br />
<br />
As with the others, this list of Twitter tweets is sorted by first name. (Hmmm...a thought just struck me. By posting these collections, am I engaging in mass retweeting? Guess not since it isn't on Twitter. But there must be a name for this...or should be, I guess.)<br />
<br />
Alan Shalloway - people are often confusing predictability with control. if you do, you won't believe you can control your dev process. being in control is not a bad thing. being controlled by someone else is.<br />
<br />
Alan Shalloway - the more i work w/ lrg orgs (300+ devs) the more i believe that any approach that focuses solely on the team or is bottom up is doomed. top down does not mean top down control. but rather top down enabling of working on the right things in the right way.<br />
<br />
Alan Shalloway (series of quotes) - Issue isn't "when does agile work?", rather "how agile can i be?" This implies a continuum. Going to iterations is a break. Scrum is evolutionary in perspective but revolutionary in implementation (making it hard). Kanban is revolutionary in perspective but evolutionary in implementation. Many (most?) people in Agile community think Agile==Scrum. So when Scrum won't work they think Agile won't. At conferences people say "we're doing agile" when they mean they are learning scrum.<br />
<br />
Andreas Boes at XP Days Germany 09 on “The New Industrialization” (via Alistair Cockburn) – “Industrialization" converted subjective process to objective process (remove individual's capabilities). Taylor reduced 'processes' to invidual activities and actions. Taylor was a micro-methodologist (studied microtechniques). Alistair Cockburn - I think modern agile ppl are doing Taylorist work: study top performers, decompose, teach to others. That's exactly what we're doing! (I disagree with [Boes] - he says programmers are black box. but nano-TDD opens that box. I think agilists are whitewashing a secret Taylorist agenda, and it worries me.) what does he mean with “separate subjectivity from individuality”? I need a translation of Taylor’s 3 ground rules. Boes - agile brings in "living process"; which also lean brings in, too. diff : Taylor = optimize before announcing the process; Lean = optimize after deploying the process. Agile brings self-organization; Lean brings repeatable processes. Agile = collective learning & knowledge capture; this makes the "objectivity" and visibility needed. What does agile mean for the average worker? we haven't thought through it (bad things to follow?) Alistair Cockburn - Boes/audience Taylor tried to diminish the human, sw tries to augment (I worry that parts-replaceable programmers goes the wrong way.<br />
<br />
Bob MacNeal (more on being self-directing) - 1) Responsibility - given or takes responsibility for results and 2) Autonomy (free to determine, plan & schedule activities).<br />
<br />
Chris Sterling - scrum is a learning system; modify tools, practices, & process when your team learns something.<br />
<br />
Dave Rooney - Agile is a collection of those 'things that work' put together in a synergistic way... whole is greater than sum of parts.<br />
<br />
David Anderson - Kaizen done right is statistically based systems analysis often using SPC. Diana Larsen - Retros done right get at diff probs than SPC - esp human issues & + deviance. Well-run retrospectives incl subjective & objective data, as relevant to retro focus, + analysis & action. David Anderson - retros tend to project level focused. higher maturity orgs will have an organization level focus across teams/projects. This is not guidance or opinion. This is field reported cases. You need to be open to ask why? and challenge your beliefs. Paul Dyson (via Rachel Davies) - Like all agile practices (or practices in general), there is a risk of 'cargo cult execution' with retrospectives.<br />
<br />
Gerald Weinberg - Definition of Bureaucracy: Each thing is in control, but everything is out of control.<br />
<br />
James Bach - Saying ISTQB certification makes a tester better is like saying a chefs hat makes you a good cook. I had a woman in my class who studied for two years to be a baker. Then she studied for a few days to get a tester certification. Why are donuts worth two years of school, and testing worth no training at all? Because testing is easier to fake than donuts.<br />
<br />
Jason Yip - Crisis is required to provoke deep change only if top management has a monopoly on setting strategy.<br />
<br />
Jean Tabaka asked about 100-130 chars to describe Kanban and some responses were: Karl Scotland - Map value stream, visualize, limit WIP, establish cadence. Reduce WIP to improve value flow & individual fulfillment. David Anderson - visualize flow, limit WIP to encourage evolutionary change towards lean outcome, high maturity culture.<br />
<br />
Jurgen Appelo - Introverts are not shy. Introverts just prefer low-noise communication. [Added by Dave Rooney in a retweet - Introvert == shy is common misconception]<br />
<br />
Karl Scotland - If your process is designed to expose dysfunction, what do you do when your process becomes the dysfunction?<br />
<br />
Karl Scotland (asked) - Are retrospectives a form of Schewart/Deming Cycle? David Anderson (replied) - I find most retrospective guidance to suggest subjective, anecdotal feedback rather than objective data-based Deming style info. SEI classifies OID based on subjective, anecdotal evidence as low maturity even though OID is a ML5 process area. Deming's method would be considered high maturity OID/CAR ML5 by the SEI. Typical retros are a low maturity precursor to PDSA. meanwhile, @kjscotland and I are only reporting facts from field. High maturity kanban teams tend to drop retros as waste.<br />
<br />
Vasco Duarte - Ppl talk a lot about business value, but they forget that for most people business value is totally subjective! (i.e. unquantifiable)<br />
<br />
Vince Lombardi (via Jason Yip) - Perfection is not attainable, but if we chase perfection we can catch excellence.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com1tag:blogger.com,1999:blog-224928398513703850.post-43789422532953092082009-11-22T10:02:00.002-05:002009-11-22T10:05:03.234-05:00"The System," "They" and "Policy"This was such a funny/weird situation involving communication with a customer that I just had to pass it along.<br />
<br />
First, some setup information. In August of 2008 we changed cell phone company to fit in with the last job I had. So no contact from the prior provider since then. That is, until two days ago...<br />
<br />
A 4-page (2 sheet) bill from the provider (one of the big four) shows up saying its from the Oct 10-Nov 9 Bill Period with a Nov 13 Bill Date. First page shows<br />
<br />
Oct 13 Tax Adjustment ............................................. -$1.81<br />
New Charges ........................................................... $1.81<br />
Total Due $0.00<br />
<br />
On the payment remit slip is says "DO NOT SEND PAYMENT. This amount will be credited to your next bill. $0.00."<br />
<br />
On page 4 (after 2 pages of legal stuff and ads for buying more services) it says<br />
<br />
Charges<br />
Toleance.................................................................. $1.81<br />
Total $1.81<br />
(and that is the only thing on the page except the "4of 4" page number, the company logo, and billing acct number and dates).<br />
<br />
Now the fun begins since I wanted to know what this was all about after 14 months of not being with this provider. So I call the customer service number from the first page of the bill and explain all this to the person who answers. I tell them I'm trying to find out why I got this and what it means given I have not been a customer since August of 2008.<br />
<br />
The person was quite nice but said her records of our account doin't show any such credit/charges. But she said we didn't owe anything, so just ignore it. But, again, I asked why did I get this and what does it mean. Since she seemed to feel I should not care, I asked for a supervisor.<br />
<br />
The customer service supervisor was also quite nice, but could not explain it, i.e., nothing showing on any records she could see. She guessed it was a credit left over after we closed the account. So why, I asked, did it take 14 months to contact us and why what was the charge for that cancelled out the credit. She did not know and put me on hold a few times trying to find someone who might know. Finally, she sent me to their finance/accounting folks.<br />
<br />
That person, also very nice, suggested "they" must have noticed this credit recently so "the system" sent me a letter letting me know. I said, it wasn't a letter, it was a bill and asked what a "Tolerance" charge was. I never got an answer to that last question. But it seems, since we closed the account and paid the final bill, somehow "they" decided we were owed a $1.81 for some overpayment of tax. However, it is the provider's "policy" not to send out checks for less that $5. But the finance person could also not really explain much beyond this and did not show anything in their records either specific to this "bill" being sent.<br />
<br />
So, apparently, to clear the account, "the system" or some "they" decided to send a bill to acknowledge the credit and the charge in that credit amount to make the account $0 since it was not the provider's intent to actually reimburse the credit amount given it was under $5.<br />
<br />
This silliness, of course, was to satisfy some legal and accounting rules that I didn't know or care about.<br />
<br />
But a couple things struck me about all this, besides the silliness:<br />
<ol><li>None of the people could access any system of information that would allow them to find out what this was all about. (The Finance person was basically guessing what happenbed based on "policy" rules, not based on any information about the actual account.)</li>
<li>I wonder if this was something that was done to many people to clear out old accounts, i.e., the cost to do this and then to deal with people like myself calling up to find out why, if so, would clearly be a substantial waste of time, money and company credibility.</li>
<li>It would be interesting to know how much the provider makes each year keeping all credits under $5 (and what legal loophole makes this possible) since they waste the postage and time sending out silly $0.00 balance bills anyway.</li>
</ol>Like Arsenio used to say, makes you wanna' go "Hmmmm."Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-84164261620728304702009-11-16T13:34:00.000-05:002009-11-16T13:34:01.296-05:00Expectations Around UncertaintyBack in September (10th), Mike Cottmeyer posted “Managing Expectations about Uncertainty” and noted that traditional project management views it as important to “manage uncertainty out of the project.” On the other hand, Agile efforts “[r]ather than managing OUT uncertainty” choose “managing FOR uncertainty.” I like that phrasing of the Agile approach. Mike did point out that “both worldviews have a place depending upon your context and problem domain” and that it is “up to us [as Project Managers] to recognize the nature of the projects we are working on and choose the strategy most likely yield a desirable outcome.”<br />
<br />
I am inclined to say that "uncertainty" early in a project can be divided into (a) things we cannot (now) know and (b) things we should be able to know. I believe the more traditional approach takes the latter as its view. That is, the traditional view is that “due diligence” should be able to reduce uncertainty to nearly zero, leaving few (or no) things unknown. Thus, Agile’s approach to "embrace uncertainty" suggests irresponsible risk-taking in the traditional view because insufficient effort is expended to eliminate all the uncertainty possible. In this view, uncertainty is lack of knowledge that should be corrected by better initial effort. I believe the Agile approach looks at (a) as its view of early uncertainty. That is, there are things we really cannot know early on, may not be able to know until work has been done and feedback collected, or may not end up needing to know by the time we get there.<br />
<br />
Now the word “uncertain” suggests being aware of something but not totally sure about it. If you are totally unaware of something (or it is something that is truly unknowable), talking of being “certain” or “uncertain” makes little sense. The traditional view of “uncertainty” carries a lot of weight, then, within that worldview if it means things we are aware of but do not understand deeply enough. Consider the large number of lists of potential project risks and failure causes that have been compiled over the years. In effect, they say, “Look, all of these things have been noted in the past and could impact your project. You need to explore them and become ‘certain’ about whether or not they have meaning/impact on your work.” Hence, “due diligence” involves being thorough about considering all these factors since we can and “should have known” this early on during planning for our project.<br />
<br />
The Agile view is that it is wasteful to try to drive out all uncertainty early because it cannot be done. This appears to the more traditional view as irresponsible for the reasons noted above. An Agile approach relies more on short delivery cycles, than detailed up front planning, to address uncertainty. As with many other things, an Agile approach advocates an incremental, iterative way of addressing uncertainty, increasing detail as the events requiring it loom closer and moving from an implication of "early" to merely "before." From an Agile perspective, “due diligence” includes avoiding wasteful anticipation of risks/problems as much as responsible consideration of them.<br />
<br />
This is not to say all early consideration of risk/uncertainty is to be avoided. However, from an Agile perspective, the details regarding how certain issues should be addressed can be delayed until more knowledge is available to the project. Agile projects move ahead with what is known while information on what isn’t known is developed.<br />
<br />
In the end, of course, if an Agile project goes bad because of an unplanned for issue, the traditional view can say “See, we told you.” Equally, if a traditional project never encounters issues it expends effort to make plans for, the Agile view can say “See, we told you.” I am reminded of a talk Kent Beck gave at XP2006 in Oulu, Finland where he discussed “responsible development.” I think “certainty” and “due diligence” are things which walk that line of what is and is not “responsible.”Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-50295777924776851682009-11-12T19:43:00.003-05:002009-11-12T19:50:03.643-05:00Notes on the ASQ Software Division’s ICSQ 2009Each year, the Software Division of the American Society for Quality (ASQ) holds their International Conference on Software Quality. This year, it was held at the Hilton in Northbrook, Illinois on November 10-11 (with a tutorial day on the 9th).<br />
<br />
What follows are my notes on the sessions I attended and the Agile “debate” in which I represented the “pro” Agile side. Other than keynotes, sessions were run in parallel with 4 tracks going on at the same time. My notes, therefore, represent the one session I attended of four going on simultaneously.<br />
<br />
One thing to be aware of is that attendees at ICSQ’s are often from regulated industries and firms doing government related contracting where formal, standards-driven quality approaches are the rule.<br />
<br />
<strong>Tuesday, November 10, 2009</strong><br />
<br />
<em>Keynote – Bill Curtis on “Quality in Multi-Tiered IT Applications”</em><br />
<br />
Bill Curtis has been a researcher, practitioner and chief scientist in software methods and individual performance for many decades. He has worked at ITT, MCC (Austin, TX research consortium), SEI (as head of the Process program), TeraQuest (process assessment and improvement), and now at CAST Software. I have known Bill over the years during his time at MCC, SEI and TeraQuest, in particular coordinating (and applying the results of) his research activity in software design expertise for the company where I was working at that time.<br />
<br />
Curtis started saying, “We’re moving beyond just what smarts and knowledge can handle.” By this, he meant the systems and their interactions have evolved (and continue to evolve) to where product (code) quality ideas are not enough to manage the desired results. Expertise in application level quality, i.e., how all the components interact, is what has the largest impact on system quality today. Quoting an ACM article (Jackson, “A Direct Path to Dependable Software,” CACM v. 54, no. 4), “The correctness of code is rarely the weakest link.”<br />
<br />
Curtis pointed to problems with design choices that “pass (functional) tests,” but are (at best) inadvisable practice when scaled and must address non-functional production requirements. Presaging the end of day keynote by Joe Jarzombek, Curtis said that we need to be able to make dependability, assurance, etc. “cases” about our systems. That is, we should be able to provide evidence to support arguments that justify belief in claims about such non-functional requirements.<br />
<br />
Curtis offered a few other ideas such as:<br />
<br />
<ul><li>addressing people’s ability to understand a system when changes must be made since he said 50% of the change effort in maintenance is devoted just to figuring out what the system, not an individual module, is doing;</li>
<li>allowing (and training) testing groups to do true QA, indeed do Quality Engineering, which would require a broader involvement of personnel from testing organizations in the full lifecycle of work as well as not regarding test groups as “entry-level” positions;</li>
<li>understanding the COO’s view on the need to standardize ways of doing things an organization does not compete on.</li>
</ul>Finally, Curtis mentioned the Consortium for IT Software Quality “sponsored by a partnership between the Software Engineering Institute (SEI) at Carnegie Mellon University and the Object Management Group (OMG) to combine their industry-leading strengths in developing software-related standards and appraiser licensing programs.” As one of its activities, Curtis said, it will work to create more operational definitions of software (non-functional) quality characteristics (i.e., the “ilities”). The ISO 25000 series, which supplanted ISO 9126, has definitions, but the CISQ’s work suggests they are not viewed as operational enough.<br />
<div><br />
</div><div><em>Tom Roth – Psychology of Software Quality</em><br />
</div><div><br />
</div><div>Roth’s background is in embedded avionics software quality assurance where he is in charge of overseeing reviews, internal audits, testing, etc.<br />
</div><div><br />
</div><div>Roth started by saying we should “think of QA as people trying to influence the behavior of other people developing software.” Hence, his talk was about influencing people with regard to quality and the importance of QA knowing how to develop trust in developers since not everything can be reviewed. (Interestingly, an article in the ASQ’s main magazine, Quality Progress, for this month, is entitled “Trust, But Verify.”) But Roth cautioned against “enjoying the power you have” as an arbiter of quality, using knowledge of psychology to establish a collaborative relationship with development groups/management.<br />
</div><div><br />
</div><div>In discussing inspections and reviews, Roth noted that software engineering formalities, such as Fagan inspections, impart a level of discipline and, potentially, a group sharing of responsibility, which may not exist with individuals alone. Indeed, inspections turn the deliverable being inspected over to the group and the individual does not bear the full brunt of making sure quality is present in that deliverable. From an Agile perspective, I was thinking that, after a while, such discipline should become more internalized and less dependent on external rigor.<br />
</div><div><br />
</div>Some of the things Roth touched on were how:<br />
<br />
<ul><li>in relationships, differences often attract while similarities comfort, but trying to force sameness can destroy the attraction;</li>
<li>inappropriate habits exert tremendous influence on further (and, perhaps even worse, expanded) inappropriate behavior;</li>
<li>we are not 2, 3 or 4 different people, despite external appearances under different social circumstances, i.e., there is a congruence in behavior which, especially under stress, will reveal itself;</li>
<li>people working alone can spend 2/3 of their time evaluating alternatives and 1/3 implementing a chosen alternative while two people working together reverse the balance, effectively quadrupling the productivity of one person alone;</li>
<li>behavior [engineering] leads attitude [morality] - you can tell people what to do but not how/what to think, so work on behaviors/practices and allow the thinking to come along on its own.</li>
</ul>The last two struck me as quite interesting, of course, from an Agile perspective.<br />
<div><br />
</div><div><em>Ed Weller – Getting Management to Listen</em><br />
</div><div><br />
</div><div>There are many talks that have been given over the years about how to talk to management. Ed Weller covered some of the same terrain in terms of speaking from a cost/dollars perspective. However, he did offer some specific ideas related to managers who are:<br />
<br />
</div><ul><li>used to technical “change agents” (1) underestimating the cost of implementation, (2) overestimating improvement benefits, and (3) introducing risk management is not comfortable with;</li>
<li>faced with “Problem Saturation”, i.e., “consumed solving today’s problems” with “no time for next week’s (month’s/year’s) problem.”</li>
</ul>Weller’s suggestion was to focus on data on the cost of rework, pre/post ship defects, and, in general, poor quality. From a lean/agile perspective, this means showing management how they can reduce waste in the software process.<br />
<div><br />
</div><div><em>Rebecca Staton-Reinstein – Using A Cost of Quality Model to Drive Improvement</em><br />
</div><div><br />
</div><div>This was a fairly standard talk on CoQ models elements. Some of the audience interaction and comments were of interest, especially regarding the difficulties in doing CoQ calculations:<br />
<br />
</div><ul><li>collecting data accepted as “accurate” enough to truly prove/show improvement ROI is very difficult for an organization that does not have some level of process discipline and decent data capture capability;</li>
<li>such models, on the cost avoidance side, are talking about things that haven’t happened, yet, requiring (accepted) historical data to show prior trends that could be reasonably extrapolated to the future;</li>
<li>belief in quality as a matter of personal “morality” or “will” (i.e., we have problems because people just don’t try hard enough to do the job “right”) rather than something addressable through an engineering approach;</li>
<li>being able to take quality data and relate it to schedule and budget impact.</li>
</ul>Then, at some point during the talk, the following thought struck me: if you do things with urgency, you won’t have to do them in a rush.<br />
<div><br />
</div><div><em>Keynote – Joe Jarzombek, National Software [Security] Assurance effort from DHS</em><br />
</div><div><br />
</div><div>Joe Jarzombek directs the Department of Homeland Security’s program on Software Assurance and has been doing this, with little budget, for over 4-1/2 years. I met Joe through my activities on the IEEE Software and Systems Engineering Standards Committee when he was still consulting within the Dept. of Defense. (Before that, he was an active duty Lt. Colonel with the Army serving at the Pentagon.) Joe’s job is to promote an interest in and work actively toward securing the infrastructure of the USA from cyber attack. To do this over the years he has brought together academic institutions, government agencies (DHS, Dept. of Commerce, Dept. of Energy, and DoD), non-profit agencies, and commercial organizations to work on a variety of efforts in tools, techniques, guidance, educational programs, standards (working with IEEE and ISO), etc.<br />
</div><div><br />
</div><div>Joe’s talk is one I have heard over his many years with DHS. He updates it regularly with the latest status on the efforts noted above. And, in case it is not otherwise obvious, the “assurance” focus of this work is on writing secure software and securing infrastructure computing.<br />
</div><div><br />
</div><div>As most of the printed materials which arise from the efforts of the participants he has brought together are produced under government funding, they are freely available at the Build Security In website under the “DHS SwA Web Site” link. Another good source of material on Software Assurance is articles from issues of Crosstalk (the Journal of Defense Software Engineering) which are also freely available. And, though a few years old, a July 31, 2007 “State of the Art Report on Software Security Assurance,” is also available.<br />
</div><div><br />
</div><div><strong>Wednesday, November 11, 2009</strong><br />
</div><div><br />
</div><div><em>Keynote – Edy Liongosari “Everything’s Elastic”</em><br />
</div><div><br />
</div><div>Liongosari directs work at Accenture Technology Labs and spoke about the changing landscape of computing as it moves from traditional computers to mobile devices. Most of the trends he noted (e.g., cloud computing) were not new, however, some of the implications and data were interesting.<br />
</div><div><br />
</div><div>For example, 30% of “smart” phones are owned by people with family incomes at or below $30,000. For them, this was their computing platform in the sense that they did their “computing” through internet access to sources of information, data, and applications. (On the latter point, Liongosari noted that there were some 100,000 iPhone applications available.) From a third-world perspective, Liongosari noted that, despite wide-spread cell-phone use in the developed countries, cell technology was even more prevalent in the third-world where land-line phones, computers, bank accounts, etc. were not at all common or available. Indeed, there were places, he said, where people “barely able to feed themselves” had cell phones.<br />
</div><div><br />
</div><div>Liongosari also spent some time talking about how large organizations were beginning to use cloud capability to get work done in fractions of the time it would have taken them to set up in house infrastructure to handle the same level of computing. He even noted an insurance firm (unnamed) that uploaded data to the cloud, performed massive analysis and downloaded the data and results a few hours later, “renting” the time and resources.<br />
</div><div><br />
</div><div>From a social computing perspective, he talked about how companies were starting to use such ideas (if not the most well-known social sites) in “harnessing the power of the crowd” to collect ideas and trends. Some examples were IBM’s Bluehouse, Adobe’s Cocomo, and Dell’s Ideastorm.<br />
</div><div><br />
</div><div>Another point made was how people in the workforce from teens to late twenties had a view of free access to computing resources and what this means when they are in company environments. Liongosari also noted the relative lack of concern people in this age group have for the idea of privacy, which is a concern (and mentioned in Joe Jarzombek’s talk) with regard to cloud computing.<br />
</div><div><br />
</div><div>While I listened to this keynote, another thought came to me: IT is moving from meaning “institutional” to “individual” technology, even more than the PC represented such a move since, it is not just owning your own computing resources now, but having an individual “right” to information that is starting to dominate thinking.<br />
</div><div><br />
</div><div><em>Tim Olson – Lean Principles and Process Models</em><br />
</div><div><br />
</div><div>Tim Olson has considerable background in process (improvement) consulting, having worked at the SEI early on in the CMM program, being involved with the Juran Institute, having Six Sigma experience, and, most recently, working with Lean.<br />
</div><div><br />
</div><div>Olson started by relating to an example from Deming about the danger of trying to replicate success by others through simply copying their apparent behavior without understanding the context and principles behind the practices. This resonated greatly with me because it is an issue I have seen with Agile adoption when companies learn practices and techniques without an understanding of Agile Values and Principles.<br />
</div><div><br />
</div><div>For the most part, Olson’s talk was about basic Value-Stream and Value-Stream Mapping ideas. However, he noted the lack of automated tools to make the mapping easier. He did note that, in discussion with Toyota, that they used walls and boards, without automated tools. But Olson noted that his process definition approach, focused on diagrammatic, rather than textual, process description has led him to apply process modeling/mapping tools to value-stream work.<br />
</div><div><br />
</div><div>He did caution, however, that simply trying to transplant Lean manufacturing ideas to software has been a problem in various cases since this has resulted in removing “non-value-added” activities such as configuration management.<br />
</div><div><br />
</div><div><em>Siegfried Zopf – Pitfalls in Globally Distributed Projects</em><br />
</div><div><br />
</div><div>Zopf is from Austria and discussed issues and problems he has observed working in multi-national, multi-cultural project situations.<br />
</div><div><br />
</div><div>Zopf began by making a distinction between distributed and outsourced situations, then, between minimally and large-scale outsourcing. Overall, it seemed as though he was emphasizing awareness of the level of appropriate control to apply to the different combinations of situations. For example, in a minimally responsible outsourcing situation – the work is confined to low-level design and coding – risk is low and pulling the work back in-house is not a problem, but the financial savings are lower. On the other hand, there is great financial advantage in outsourcing greater parts of the work, but much more local project management required in the outsourced locations. Zopf suggested allowing for 15-20% cost for such a “beachhead” operation.<br />
</div><div><br />
</div><div>Zopf also, in connection with any larger outsourcing effort, noted how planning must account for extra costs in project management, communication, travel, documentation, and knowledge transfer that would not exist in a fully local project. Thus, a company cannot take an estimation done assuming in-house work, then simply portion out parts of the work, “transplanting” the estimate and plans without adjusting for the differences.<br />
</div><div><br />
</div><div>And, for distribution matters in general, whether outsourcing or not, there are still issues related to national and cultural differences regardless of whether or not it is the “same” company. A couple examples of what he discussed are:<br />
<br />
</div><ul><li>two groups, for each of whom English is a second language, and the problems they can have trying to communicate using English which are not the case when at least one group is native English speakers;</li>
<li>monochronistic and polychronistic cultures where the former view time as linear, compartmentalized, and value punctuality and the latter view time as more fluid, schedule multiple things at the same time, and even expect people/things to be late.</li>
</ul>One final point in distributing work (with or without outsourcing) is process mismatch. Specifically when working with a high maturity (using the CMMI scale, Level 5) organization, that organization will find it difficult working with another organization that is not at least Level 3. In the reverse direction, a low maturity organization may find it frustrating working with the expectations and pace of a high maturity one.<br />
<div><br />
</div><div><em>Ron McClintic – Performance Testing</em><br />
</div><div><br />
</div><div>Ron was the “con” side in the Agile “debate” (which I describe below) and has a lot of years of testing/QA experience working for and in the GE Capital environment. He currently works with applications that collect and analyze data on truck fleets using a combination of hardware, embedded software, and more traditional application software. However, the multiple vendor networked environment he works in matches quite well with the multi-tiered issues Bill Curtis discussed.<br />
</div><div><br />
</div><div>His talk could be considered a “case study” since he went into detail about the various points for performance testing that his efforts need to address, from the lowest levels of (vendor-supplied) software doing network and database optimization and capacity adjustments to customer GUIs and response expectations. On the latter he noted work done to determine thresholds for response time from the minimum one would ever need which matched the time for a person to perceive a screen change up to the upper limit before a customer would abandon a (web) application and go elsewhere. It turns out the latter is about 4x the tolerated time frame. The problem is that, for different client situations, the tolerated times vary.<br />
</div><div><br />
</div><div>As an example of a difficult performance/response issue to address, one client reported significant performance problems before 10am each day, but which seemed to go away at or about 10am. After a few weeks of probing and testing, it was discovered that 10am local time was when the company’s European offices, mostly in the UK, ended their day, a fact not previously revealed to Ron’s group. The moral being not all issues are really technical ones even though they have technical impacts.<br />
</div><div><br />
</div><div>One statement Ron made rang very true to me, especially in light of one of the points Bill Curtis made, and that had to do with using testing and test tools in an “investigative,” rather than ”reactive,” manner. I think, overall, this is an important way to view the real value testing and test staff can have to an organization as opposed to the, often, “last ditch” quality control function often performed. QA (testing and other true QA functions) should be to supply information to the rest of the organization about the status of progress and quality of work.<br />
</div><div><br />
</div><div><strong>The Agile “Debate” – Ron McClintic & Scott Duncan</strong><br />
</div><div><br />
</div><div>The other talks/keynotes described above occurred in the order I’ve listed them. This “debate” actually occurred Tuesday afternoon just before Joe Jarzombek’s keynote. I’ve saved it for last since I am commenting on my own (and Ron’s) session. Ron had proposed this and I had been recommended to him by the Conference Chair, Mark Neal, whom I have worked with before on Software Division activities.<br />
</div><div><br />
</div><div>We started the session with me going over, briefly, the Agile Values and Principles and stating that I felt this is what “defines” Agile. Since the various methods preceded the Snowbird meeting, the term “Agile,” applied to software development, occurred at that meeting and with regard to the Vs & Ps. So, for me, that means the Vs & Ps are what define “Agile” while practices and techniques are examples of possible implementation approaches. Ron had no real problem with this as he noted he agreed with these ideas. His objection to Agile came from two sources, he felt:<br />
<br />
</div><ul><li>it resulted in overall “suboptimization” of a project because it focused only on optimization of the development piece, and</li>
<li>it did not focus on actually profitability of a company that sells to the marketplace, defining value as just the delivery of the working software.</li>
</ul>Thus, his argument was that a more traditional approach to projects that accounted for the full product lifecycle, including longer-term maintenance and support costs, was more appropriate. He also felt there had been no appropriately trials of similar project situations that had collected data to show the benefit of a well-conducted traditional effort compared to an Agile one.<br />
<div><br />
</div><div>He and the audience had stories to tell about “purist” insistences from consults arguing against the responsibility for Agile teams to be concerned with such issues as they were matters for the business beyond the development team. What I was hearing were stories of:<br />
<br />
</div><ul><li>“teams” without appropriate business collaboration or all the skills needed to do the work or</li>
<li>projects where the organization, itself, isolated groups outside of development from trying to pursue/accommodate an Agile approach, insisting on more formal handoffs or</li>
<li>developers insisting that going back to fix work not done completely or well in the first place constituted “refactoring” or</li>
<li>the usually litany of refusal to document, measure, and/or plan.</li>
</ul>Indeed, in one case that Ron noted, developers were writing code without requirements. I had to ask him how they got the okay to be developing anything with “no requirements” and, then, suggest this was an “Agile” approach.<br />
<div><br />
</div><div>A couple audience members also brought up the book “eXtreme Programming Refactored” and its claims of failure for the C3 project.<br />
</div><div><br />
</div><div>What I found was that people were exceedingly receptive to an explanation of the Values and Principles and accepted practices, seeing how wrong it was to characterize many of these behaviors as “Agile,” rather than merely ad hoc.<br />
</div><div><br />
</div><div>Of course, throughout the Conference, there were stories and discussions about this same sort of thing happening to other ideas once they had “crossed the chasm.” Mark Paulk, for example, was there discussing various process improvement ideas as well as his research work at Carnegie Mellon University with Scrum. He and I sat at lunch with a number of people who were at this “debate” or had other Agile contact and discussed how similar things were after a while for the CMM (and now for the CMMI) with people ascribing “requirements” status to guidance material and pushing their own idea of process “rightness” in assessing companies.<br />
</div><div><br />
</div><div>So I have left this “debate” topic until the end, and am not going into great detail about what was said because, overall, it demonstrated the attraction the Manifesto’s Values and associated Principles have for people. It also demonstrated, to me at least, the need that exists for people to understand how practices are intended to implement those Vs & Ps and not simply copy (or think they are copying) them without such understanding.<br />
</div>Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-58060617400504924932009-11-09T09:38:00.001-05:002009-11-09T09:39:08.314-05:00And Still More Quotes from TwitterAlan Shalloway - Scrum's power lies in its collaboration, co-location & feedback. thinking it lies in its practices is what ossifies/limits it.<br />
<br />
Alan Shalloway - The Leader must be pulling the org thru the change process, not pushing it thru. When a leader is pushing, the org's, people don't know if they are being pushed toward something better or off a cliff- they do not have the concern if leaders are out in front and pulling.<br />
<br />
Alistair Cockburn - Crystal = frequent delivery + close communication + reflective improvement => self-awareness; Ladder: techniques -> principles -> metaskills<br />
<br />
Bob MacNeal - Maybe "self-direction" is one characteristic that distinguishes a team from a group. Scott Duncan - Collaboration would be another. Been in group's that related well, but each did their own thing and were structured that way.<br />
<br />
Carl Sagan (via Kevlin Henney) - Intellectual brilliance is no guarantee against being dead wrong.<br />
<br />
Chris McMahon - to improve performance, what is THE ONE THING we can do right now? Ron Jeffries - they already know the one thing. Everyone does.<br />
<br />
Dale Emery - Passion and respect are not inherently at odds, though they can seem to be if you don't know how to express both at once.<br />
<br />
Daryl Kulak - Project estimating is just wishing to two decimal places.<br />
<br />
Dave Ramsey (via Carlton Matthews and @E-Mealz) - When your outgo exceeds your income, your upkeep becomes your downfall.<br />
<br />
David Hussman - Sometimes Twitter seems like the world first and largest virtual fortune cookie.<br />
<br />
Elizabeth Hendrickson - It is hard to Speak the Truth, and speak it diplomatically enough to be heard, when people want Comforting Lies.<br />
<br />
Elizabeth Hendrickson (reported by Chris Sterling at PNSQC) - "The definition of Agile is in the results" (deliver value frequently at sustainable pace) "Flexibility is a side-effect of being agile."<br />
<br />
Glyn Lumley - Anybody's job should not merely be to "do it right" but to do it better.<br />
<br />
Hillel Glazer - Real engineers *do* like GOOD processes. Those that don't are posers. If you made it through college/university w/out any processes you probably weren't in an engineering school. Check your diploma.<br />
<br />
J.B. Rainsberger - I find it hard to value Customer Collaboration without valuing whatever the customer decides is value.<br />
<br />
Jacob Yip - Stop the line != stop and fix. Stop and contain. Fix when you understand why, which may require longer analysis.<br />
<br />
Jason Yip - A car is a system; individual parts are not. Extreme Programming is a system; individual practices are not.<br />
<br />
Jason Yip - Paradoxically, if you truly value people, you tend to focus on the work, not on the people.<br />
<br />
Jeff Patton - agile people: is iteration process iteration- repeat the same steps in cycles, or product iteration: reconsider and rework prod decisions?<br />
<br />
Jeff Patton - Agile-resistant teams hate all the meetings. Experienced agile teams love all the collaborative work.<br />
<br />
Jeff Patton - Requirements are the boundary between what I get to decide and what you get to decide. It's a fuzzy discussion, or DMZ.<br />
<br />
Jim Highsmith - Agility is the ability to think and learn rather than blindly following a recipe. Brian Marick - No, agility is not "the ability to think and learn rather than blindly following a recipe". Let's not equate "agility" with "good". The ability to think and learn is part of Agile and 8 zillion other things. Joshua Kerievsky - @marick You've focused on the think/learn part while the important part is not "blindly following a recipe." (even an Agile one). Brian Marick - @JoshuaKerievsky I suppose it needs saying. But I think it would be good if Agile thought leaders thought more about software.<br />
<br />
Jim Knowlton (at PNSQC via Matt Dressman) - "date, but don't marry, your framework."<br />
<br />
John D. Cook (actually from his blog pointed to by Jurgen Appelo) - I’ve said that someone has too much time on their hands, but not since I read Meyer’s post. I see now that the phrase is often a sour grapes response to creativity. I don’t want to do that anymore.<br />
<br />
John Goodsen - Iterations are the dogma and waste of Agile. Flow and pull make iterations irrelevant. Are you certified to manage waste?<br />
<br />
John Seddon (via Bob Marshall) - Less of the wrong thing is not the right thing.<br />
<br />
John Seddon (via Bob Marshall) - Measure what is important to customers, not auditors.<br />
<br />
Mike Sutton - The larger the organisation the thinner the thread that connects work to value.<br />
<br />
Naresh Jain - Code is not an asset its a liability. Tacit knowledge gained building the product is the asset.<br />
<br />
Nat Pryce - New manifesto: while we value valuing things other than value, we value valuing value more.<br />
<br />
Pat Reed (via George Dinwiddie) - Projects fail at the beginning, not at the end.<br />
<br />
Payson Hall - On reflection, key takeaway from #Risk Conference last month was definition of #project risk as "Uncertainty that matters".<br />
<br />
Peter R. Scholtes (via Glyn Lumley) - Why do you hire dead wood? Or, why do you hire live wood and kill it! (From The leader's handbook: making things happen, getting things done).<br />
<br />
Peter Scholtes (via Glyn Lumley) - Bureaucracy is a form of waste.. people with no real work to do impose needless tasks on those with real work to do.<br />
<br />
Scott Duncan - I see "giving" offense as different from "taking" it. I can avoid the former, but likely not the latter.<br />
<br />
Scott Duncan - In general we do not expect perfection, but in particular, we do.<br />
<br />
Scott Duncan - Waste: Write on board; copy to paper; transcribe to elec doc; have a bunch of people review to check for mistakes, etc.<br />
<br />
Tim Ottinger - Between the placebo effect and the hawthorne effect it is hard to know anything about anything involving human beings.<br />
<br />
Tim Ottinger - Biggest tip for remote pairing: Latitude hurts, longitude kills. Common hours are helpful. [Actually, a general comment about distributed teams that I’ve heard various places.]<br />
<br />
Virginia Satir - Understanding and clarity, not agreement, is what's important in dialogue.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com2tag:blogger.com,1999:blog-224928398513703850.post-37154406438936004372009-11-09T09:16:00.000-05:002009-11-09T09:16:39.627-05:00“What do you think of …?”Long before I became involved with Agile ideas, I was doing internal (and some external) consulting in more traditional (software) quality and process improvement. And many years before that, even before I got involved with software, I taught some at the college level. My style, I came to learn, was “Socratic” in that I would use questions to encourage (self) learning by my classes, clients, and audiences rather than be too direct, too often with “answers.”<br />
<br />
I think this has been helpful as an Agile coach/trainer since, over the years, I do believe leading a horse to water will get most of them to drink. That is, most people are reasonable enough to arrive at decent conclusions if given the information that will allow them to do this. This does not mean people will not have years of experience pointing them in certain directions than my questions may be hoping to encourage. I also find that it is easier, in a group, to get more useful learning to occur using this question-driven approach since the group learns from itself in a sense.<br />
<br />
In another context in a Twitter post I stated you can control what you give, but not what others take. With at least some common base of agreed upon information, I do think you can encourage people to take and experience them asking you to give more. And what I do give, I try to do so by offering alternatives when I think they exist.<br />
<br />
The title of this post suggests what I typically do that seems to work. I’ll ask people to direct attention to some data or situation and ask them what they think of it. In general with any data related to quality/process, I suggest people take an “it’s ten o’clock, do you know where your children are”* approach. That is, I encourage them to know what’s going on to the greatest extent reasonable at that time, then consider whether they are or are not okay with that being the situation.<br />
<br />
That’s it. Nothing dramatic. Just something that I find has worked for me over the years in many different contexts.<br />
<br />
(By the way, I have even used this approach to teach 8yr olds, and up, about Newton’s laws of motion where they derive F=MA and eventually come to understand why satellites stay up in the air. Takes about one 30-45 minute class. And, no, they don’t all remember everything, but they do end up learning about learning and that they, in fact, can learn about some seemingly complex things.)<br />
<br />
<br />
*For those not familiar with this phrase, it was used in a US public service announcement on TV to urge parents to know what their kids are up to and where they are late at night.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-6848705894871627782009-11-08T08:27:00.005-05:002009-11-08T08:31:50.144-05:00Burndown & Control ChartsThe teams I’ve worked with have used burndown charts to track task hours remaining during their iterations. For them, the burndown baseline represents the optimal pace a team would need to be on to complete all work for the iteration. Assuming, of course, that all the work contributes to completing committed stories, the burndown chart helps indicate how well the team is doing in meeting the iteration goal. I say “helps” as the burndown is not the entire truth. (Some teams have tracked story points in a burndown, but, as that produces a stair-step chart, most teams have used a task hours chart for their iterations. Later I’ll mention how some teams track story completion as well.)<br />
<br />
Coming from a more traditional quality background originally, I view the burndown chart as a simplistic form of a classic control chart. The baseline is like the central line on a control chart. We have no upper or lower limits since we are not doing statistical sampling, of course. We are tracking actual data completely. But there are some similarities in how a control chart is used and how we can view the actual iteration progress line compared to the baseline.<br />
<br />
If the actual progress line hovers/fluctuates right around the baseline, the team is on track to complete the iteration goal. If the actual progress line is above the baseline constantly, it could mean the team is not headed to complete their Sprint commitment. If the actual progress line is below the baseline constantly, it may mean the team is headed to complete their Sprint commitment somewhat early. However, being not too far above or below the line is likely nothing to worry about if the trend is consistent. If a team’s ability to estimate and commit is effective, they should not be too far (or for too long) above, or below, the line.<br />
<br />
On the other hand being below the baseline and heading even further below or being above the baseline and heading even further above it, should be case to consider taking some action:<br />
<br />
<ul><li>A progress line that is below the baseline and increasingly headed down means the team is ahead of their schedule for completing tasks and getting further ahead. This may or may not be good news. If things are going very well during the iteration, the team might discuss with the customer/Product Owner/etc. the possibility of taking on more work. However, this pattern could suggest some tasks being skipped or downgraded in time. That ought to be looked into as well to be sure everyone understands what the pattern means.</li>
<li>A progress line that is above the baseline and increasingly headed up means the team is behind their schedule for completing tasks and getting further behind. This is not good news as this pattern suggests some tasks being added or increased in time. This ought to be looked into to find out why work is not converging on the iteration goal.</li>
</ul><br />
Earlier I said the task burndown chart is not the complete story and used the word “helps.” Like a control chart, the burndown chart is an indicator of whether or not further consideration needs to be given to team progress. Because of the statistical nature of control charts, deviations of certain kinds from the center line, in either direction, are reasons to investigate the cause of that deviation. The assumption is that this baseline represents expected results of sampling the production process and deviations either way could be either good or bad news, but, in either case, cause to look deeper into what is happening.<br />
<br />
The same goes for the burndown chart, but there is certainly more to know about iteration progress since completion of task hours does not, by itself, mean completion of stories which is the iteration goal. One could be completing many hours of task effort, even be below the baseline, and not have completed a single story. This can happen if a mini-Waterfall is occurring in the iteration, with testing tasks bunching toward the end of the iteration.<br />
<br />
One thing a couple teams I’ve worked with have done is to put story completion targets along their baseline, then note when each story actually gets completed. This gives both a daily progress indication based on the tasks and an iteration goal indication based on when stories show completion. If teams size stories effectively, a story should be getting completed every few days, at least.<br />
<br />
Now teams that are communicating well among their members usually know all these things without the chart. But the visual representation of what the team “knows” is a useful reminder and lets people outside the team see what is happening. The visibility/transparency provided by the burndown chart is important and, for me, is its basic value since it offers everyone the opportunity to understand iteration progress and discuss it objectively.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com7tag:blogger.com,1999:blog-224928398513703850.post-11620367616143705272009-10-27T06:33:00.001-04:002009-10-27T06:34:05.308-04:00Common Project Risks and Agile Mitigations, Part 8, EpiloguePart 7 closed out the discussion of issues that the various sources identified as contributing to project failure. As promised at the end of that Part, this Part looks back on the first 7 parts and offers some summary comments. I’ve also added some further bibliography entries that I encountered them while doing this series. While they were not used to compile the list of failure issues, they do discuss project failure issues.<br />
<br />
As implied in Part 1, the series was inspired by my having reviewed a number of surveys and articles on why projects failures occur. It seemed to me that the Agile Values and Principles, if adopted using a number of generally accepted Agile practices and techniques, could mitigate many of these issues. While an Agile approach cannot pretend to solve all the identified problems, its communication and feedback model for team-based work is far more likely to surface and deal directly with such problems when they are usually less severe and less costly to address.<br />
<br />
However, these project failure risks have existed, in some cases, for decades. People have been dealing with them long before the Agile Manifesto was created. Over the years, the failure rate has been declining, as some of the source surveys have noted. The recommended solutions have been codified in various bodies of knowledge (e.g., PMIBoK, SWEBoK, CSQE BoK), models (e.g., CMM®/CMMI®), and standards (e.g., ISO 9001, IEEE S2ESC, ISO/IEC JTC1/SC7). These approaches to the problems have been (often unfairly) characterized by voluminous documentation, significant cost, and bureaucracy. Agile methods have (equally as unfairly) been characterized by applicability only to small, low-risk efforts. The BoK, models, and standards approach is a reflection of what people believe to be currently understood “best” practices derived from those used in other (non-software) engineering and project domains. Agile methods reflect the view that a less complex, less prescriptive approach is possible which relies less on detailed process guidance and more on process transparency and person-to-person communication.<br />
<br />
What is interesting, however, is the position often taken by both approaches with regard to why projects employing them continue to have problems. From a phase-based, sequential project perspective, the view is that such problems can be avoided if only project personnel would follow the existing, accepted, and well-defined project management and software engineering BoKs, models, and standards. That is, projects fail because people do not follow known methods and procedures effectively, i.e., they do not carry out such guidance “right.” Interestingly, when an Agile project is not successful, we often hear the same things, i.e., it failed because people did not do Agile (or a specific method) “right.”<br />
<br />
So the question, in either case, is: can it merely be a matter of doing what is predetermined to be “right,” whether traditional or Agile? And, why is it so hard to do what is “right” to achieve the results expected from doing so in either case? Proponents of an Agile approach say the BoK/model/standards approach suffers from too much overhead, inapplicable detail, and inflexibility causing an inability to respond promptly to the circumstances and changes that lead to failures. Proponents of the BoK/model/standards approach say Agile methods suffer from ad hoc behavior, short-term thinking, and transfer of significant risk responsibility to the business and customers.<br />
<br />
What may be most true of either approach is that a formulaic application of their practices and techniques, with insufficient knowledge and understanding of their basic principles can produce an inflexibility (or inability) to respond when circumstances require. It may be that the “best” approach would be to ensure that the guidance in the BoKs, models, and standards is understood by those working on projects, but that the Agile Values and Principles are used as the structure within which to apply that knowledge.<br />
<br />
<em>Related Bibliographical Items</em><br />
<br />
<ul><li>Ellis, Keith, Business Analysis Benchmark – 2009. IAG Consulting, 2009. <a href="http://www.iag.biz/register.html">http://www.iag.biz/register.html</a> (free, but must register with an email address)</li>
<li>Pedersen, Alf A., “Project management failure - Why projects fail,” from his Database Design Resource website. <a href="http://www.databasedesign-resource.com/project-management-failure.html">http://www.databasedesign-resource.com/project-management-failure.html</a></li>
<li>Software Engineering Institute, Insights on Program Success, A Joint Publication of the Software Engineering Institute and the Systems and Software Consortium, Inc., October 2009, CMU/SEI-2009-SR-023. <a href="http://www.sei.cmu.edu/reports/09sr023.pdf">http://www.sei.cmu.edu/reports/09sr023.pdf</a></li>
<li>Ward, J. LeRoy, “What Troubled Projects Are Costing Us,” from PMStudent blog (Josh Nankivel). <a href="http://pmstudent.com/what-troubled-projects-are-costing-us/">http://pmstudent.com/what-troubled-projects-are-costing-us/</a></li>
<li>Winters, Frank, “The Top 10 reasons Projects Fail,” a 13-part series from Gantthead.com. Part 1 is at <a href="http://www.gantthead.com/content/articles/147229.cfm">http://www.gantthead.com/content/articles/147229.cfm</a> with links to all other parts.</li>
</ul>Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-49213810187462495512009-10-25T08:11:00.001-04:002009-10-25T08:18:21.080-04:00Common Project Risks and Agile Mitigations, Part 7, Everything Else<a href="http://agilesoftwarequalities.blogspot.com/2009/10/common-project-risks-and-agile_23.html">Part 6</a> addressed the topics of quality and stakeholders. This part will address the remaining categories of issues that the various sources identified as contributing to project failure. They involve issues with and between people, availability of information, failure to apply lessons learned, testing process and vendor performance.<br />
<br />
<em>Remaining Issues</em><br />
<br />
While a number of the issues noted below have impacts in many other categories, there are some specific instances if problems that were not assigned to other areas and mentioned on their own in the various surveys of problem failure risks. The remaining categories/issues are:<br />
<br />
<ul><li>tension in social relationships; people (often respected staff) who, for one reason or another, block progress.</li>
<li>missing, or delayed access to, information resulting in untimely decision-making. (Shari Pfleeger [May] notes the common situation that “there isn’t one person who has an overview of the whole project.”)</li>
<li>not learning from past problems and/or ignoring the need to act on what has been learned.</li>
<li>inadequate procedures, strategies, and tools to be used in testing; late involvement of the test team in the project.</li>
<li>poor vendor performance delivering on a contract; for vendors of contract staff, a concern was offshore-outsourcing relationships as engineers sometimes must train colleagues who do the same work for much less pay. (Vendor contract issues were not mentioned much, but were a high % item when they were.)</li>
</ul><em>Applicable Agile Values and Principles</em><br />
<br />
Regarding people issues, Agile’s emphasis on transparency, regular improvement, and a team-based approach, while not automatically solving problems, will surface them sooner and in a more constructive atmosphere when it can be less costly to address them.<br />
<br />
Agile’s expectation of frequent, direct communication between development team, business staff, and stakeholders, while not solving all information availability problems, can reduce them significantly and surface them earlier. Agile’s approach can also mitigate “stonewalling” around information that can occur in phase-based, sequential approaches.<br />
<br />
The inspection and adaptation potential in daily meetings and regular retrospectives greatly increases the opportunity for, and expectation of, improvement. Reflection occurs close to, if not immediately after, an opportunity to learn and improve. Improvements, then, take place or are identified almost immediately rather than waiting, sometimes months, before consideration of them and any action is taken in a traditional project cycle.<br />
<br />
Testing is given first-class status by most Agile methods and test staff are very much expected to be a part of the development team. In this way a quality focus not only drives development work but confirms its success in meeting customer functionality expectations. Agile’s expectation of working software as the primary measure of project progress and success, backed by a strong regression test suite, not only moves concern for quality to the forefront of the project but help ensure that changes can be made with confidence. There is also significant emphasis on test automation in Agile methods.<br />
<br />
[A side note here regarding the latter. In 1989-90, I conducted some interviews with many large, technology-based companies in the US regarding the technologies they found most important in addressing quality. I asked what 3 things, if they were denied use of them, would have the most negative impact on their development work/quality. Two of the things mentioned most frequently were automated source code control and automated builds. Today, these two are almost always found present in development organizations. The third thing mentioned was automated regression testing. Interestingly, today, test automation is still a subject of much concern, even after 20 years.]<br />
<br />
With regard to vendor performance, Agile Values and Principles do not directly address the issues noted. However, Agile’s team structure, communication expectations, collaboration emphasis, and success-focused contracting all provide a basis for working more effectively with vendors as with other participants and stakeholders. At the very least, an Agile approach will surface the issues of everyone’s performance from the very beginning of the project and offer the potential for a more constructive, early solution to problems when they are far less costly to address.<br />
<br />
[One thing I have personally noted in working on some large, distributed efforts, was the lack of Agile experience of and training offered to off-shore teams. I believe this was because, at least in those instances, the on-shore company making use of off-shore, contract staff had been working with the off-shore companies in traditional project situations for many years and just stayed with them. The problem was the lack of training off-shore folks were given though many on-shore people went to some level of Agile training. More than once, as a consultant myself, I was asked to train off-shore personnel when their lack of experience/familiarity with Agile methods became clear.]<br />
<br />
A final Part 8 will be posted within the next few days where I look back on the first 7 parts and make some summary comments.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-89224110414713554002009-10-23T07:36:00.006-04:002009-10-23T07:40:02.915-04:00Common Project Risks and Agile Mitigations, Part 6, Quality & Stakeholders<a href="http://agilesoftwarequalities.blogspot.com/2009/10/common-project-risks-and-agile_19.html">Part 5</a> addressed the category of technology. This part will address the next two most frequently mentioned categories of issues that can lead to project failure: quality and stakeholders.<br />
<br />
<em>Quality Related Issues</em><br />
<br />
The particular issues related to quality mentioned in the various survey sources include:<br />
<br />
<ul><li>general lack of focus on quality (i.e., assurance and control), leading to critical problems where quality and reliability end up being unacceptably poor.</li>
<li>No practical way to show software meets non-functional criteria (i.e., “ilities”) or that the delivered software will "work" for the user.</li>
<li>Misunderstanding of the role of quality assurance, giving it a secondary status to other activities and viewing it as just being about testing.</li>
</ul><em>Applicable Agile Values and Principles</em><br />
<div><br />
</div>Agile’s major contributions to addressing quality issues are:<br />
<br />
<ul><li>the insistence on working software as the actual measure of progress (and success) on a project;</li>
<li>early and frequent demonstration of functionality to the customer;</li>
<li>clear acceptance criteria that define what it means for functionality to be “done.”</li>
</ul><div>All of these work together to help reduce the possibility that what is built diverges from what the customer needs/expects and to increase the likelihood that what is built functions acceptably. Various development practices are used to implement these three main goals (e.g., TDD, continuous integration, pair programming, shared code ownership).<br />
</div><div><br />
</div><div>The brevity of this discussion on quality is not meant to trivialize its importance, just to indicate that an Agile approach has fairly straight-forward quality-related goals and techniques to met those goals.<br />
</div><div><br />
</div><div><em>Stakeholder Related Issues</em><br />
</div><div><br />
</div>It might have been expected that stakeholder related issues would be a bit higher, but some of the more frequently mentioned items have stakeholder impacts associated with them. The particular issues related to stakeholder attitudes and behaviors mentioned in the various survey sources include:<br />
<br />
<ul><li>Lack of sufficient user input/involvement leading to or as a result of most requirements coming from management or other user “proxies” who do not (or rarely) use the existing system.</li>
<li>Stakeholders unable to agree on answers related to requirements, resources, etc. and the consequences of these things, who then “paper over their differences” early on, pushing problems into development where they are revealed when software implementation concerns demand a specific answer.</li>
<li>Fear that project threatens their job: their influence (even working conditions) in the organization because many software projects result in one group assuming power and another losing it.</li>
<li>Stakeholders who are partners on this project may be competitors in other areas.</li>
</ul><div><em>Applicable Agile Values and Principles</em><br />
</div><div><br />
</div><div>Quite frankly, in my view, there aren’t significant Agile ideas that specifically address the last two of these issues. Certainly, the Value of “customer collaboration” applies here, but does not, in itself or in combination with any of the Principles, offer a solution to serious stakeholder personal or competitive differences.<br />
</div><div><br />
</div><div>As to the second issue, Agile advice is to give the development team a single individual to “represent” the customer(s) and deal with the differences before the team gets its direction on functionality and priorities. That person (e.g., Product Owner) deals with the stakeholder diversities. Not really a solution in itself as it just hands the issue to the business, saying it needs to handle this if the development team is going to be able to be as “agile” as desired.<br />
</div><div><br />
</div><div>With multiple, a perhaps disparate, stakeholders, there is not Agile “magic” to wipe away the problems. Early and frequent demonstration of working software, though, can help focus stakeholder attention on the work, giving them concrete functionality to consider. Being concrete often makes it easier to overcome, or at least discuss somewhat more openly, concerns of and differences between stakeholders.<br />
</div><div><br />
</div><div>The first issue is best addressed through Agile’s goal that there be regular, frequent involvement by the customer in discussing functionality and reviewing iteration output. However, this will not prevent the “customer” view from being dominated more by management than actual system user perspectives. Again, it is left up to the business side of the relationship to ensure the information the development team receives represents the actual needs of the business in a way that will allow the most benefit to be derived from the work produced.<br />
</div><div><br />
</div><div>[Note: In the case of both quality and stakeholder negotiation matters, there is a great deal of existing wisdom and practice that is not Agile-specific in nature, but certainly consistent with Agile Values and Principles. Indeed, one could say the same about all of the issues mentioned in this series. Certainly, the goal of the series has not been to suggest only Agile ideas exist to address them, just that Agile has something to contribute in the way it suggests conducting product development.]<br />
</div>Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-75500459937936964382009-10-22T16:26:00.000-04:002009-10-22T16:26:17.437-04:00My First “Agile” Experience in the Early 80sOf course, it wasn’t actually Agile according to any currently understood practices and techniques. But it did have aspects of some of the ideas now viewed as Agile and was the experience that came to mind when I first read Kent beck’s 1st edition of <em>eXtreme Programming Explained</em>. I’ll describe the working environment, the product (a bit) and how we interacted. You can judge for yourself where the experience fit on any scale of being or not being Agile.<br />
<br />
We were doing a commercial 4GL product (non-procedural language and associated database) known as RAMISII. It was written in FORTRAN and IBM 370 assembler so, of course, ran on IBM mainframes. There were 9 of us in the development group. Two focused mainly on the database code (and an access module to IMS DB/DC so the “language” could do reporting from those databases as if they were our own database). Two did “support” and non-development (regression) testing. So five of us worked on the language/reporting side. There were also a couple documentation folks who worked under the Marketing group which had 4-5 other folks in it. Marketing was our internal “customer,” though we never used that term or really thought of them that way formally.<br />
<br />
Once year, after relational databases started catching on but before DB2 was big in the IBM environment, it was decided we would redo the reporting/language side of the product to add substantial functionality, including language constructs to allow relational operations for reporting extract purposes. Since we were going to change some 70% of the system, it was also decided we’d get rid of all the FORTRAN and replace it with Assembler. That’ll give you an idea of the technical scope of what the five of us would tackle over the course of 9 months or so. The 9 month target was because it was early summer and the next major customer gathering/conference was the next Spring, so we needed to have a major release ready then as we did each Spring.<br />
<br />
[An aside on why assembler and not C, Pascal, even PL/I. We had to stick with languages that IBM was currently supporting on mainframes and an IBM C compiler was many years away at that point. But we could have used PL/I except that, at least back then, there were dynamic libraries associated with it that the customer would already have had to have, i.e., they had to be using PL/I, to then run our delivered system. Or the customer would have to license those libraries separately from IBM. Or we would have had to license them and pay IBM for each copy of our system that we released with them. Company senior management did not want to get involved with any of these concerns. So no PL/I.]<br />
<br />
As to our environment, besides just saying it as assembler and IBM mainframes. Our (two) machines were mid-sized mainframes running VM/CMS (a virtual memory system that allowed each of us to feel like we had a machine all to ourselves). We worked on, wait for it, TI Silent 700s, i.e., thermal printer terminals. No CRTs as it was before even 3270s were widely used. (A year or so later, we had to get into supporting 3270 full-screen, but, at that time, it was command-line interfacing.) Each of us had our own private office in a nice building in the suburbs of Princeton, NJ. Of the five of us, 3 were relatively new to the company (<1 year), one was just a bit over a year, and I had been there between 2-3 years. (The database access and support folks were more senior than I.) Everyone, save one very junior person, had several years of experience at that point (i.e., 5+ at least) in IBM or Honeywell mainframe environments with assembler (and other languages).<br />
<br />
Our immediate bosses were really fine folks with development experience from an operations research background. There was no obvious hierarchy among us. (Indeed. while I was there, I was "promoted" 3 times and never knew it. It never affected how I related to or was noticebly viewed by anyone, at least as far as I could see.) We each, and our managers, valued good ideas and enjoyed one another’s ideas as there was always lots of room for people to contribute. The product was thousands of lines of code. I can’t remember exactly how big but we had some 50-60 uniquely named FORTRAN and assembler modules that ranged from a couple hundred to a thousand lines each. Back then, it was a large footprint product that employed dynamically loaded overlays to limit memory use.<br />
<br />
That summer, those of us in development spent a month or so determining every module we felt we’d have to touch based on some very high-level specs from Marketing. These specs came from the last Spring’s meeting where customers would annually “vote” on the features they wanted from a long list compiled from everything they all had been submitting for the 6 months before that. As this was pre-32 bit addressing, we also had some decisions to make about how to restructure our pointer approach for our report record sorting. One of the features desired was the ability to print summary data before all the data actually printed on the page, so we had look-ahead selection and calculation issues to deal with so we could create, carry and sort summary data records within the detailed records.<br />
<br />
I have no recollection of how this started, but near the end of the summer, we started having regular meetings with the Marketing and documentation folks to flesh out functionality in more detail. We never had a formal requirements spec, but the user/support manuals became our “spec” as were interactively decided on features, new language syntax, etc. We would not have new functionality to show at each meeting, but we had ideas to present and questions to cover so Marketing and documentation knew, throughout, what we were up to and what it was going to look like. (Being syntax and command-line focused helped a lot since we did not have GUIs and full-screen formatting to worry about.)<br />
<br />
After a couple months, though, we did have features to show since we had updated/rewritten enough to have threads of functionality able to work. We could also start testing functionality, at least within development, though we were also sharing what we were doing (as was Marketing and documentation) with the support group so they could work on tests at their level to incorporate into the test suite. (We would give them ours, but they’d always enhance them and then move them into their large test suite where they thought the new tests would work best with existing test cases.)<br />
<br />
As we saw how our design ideas were working out, we began to offer to Marketing ideas we had on features, related to ones clients had requested, that we felt could “fall out” of work we were doing with little or no additional effort. If Marketing liked them and management accepted our evidence that it would not impact the Spring client meeting demo date, we’d put them in. An example of this were various summary calculations and totals we saw we could add if Marketing felt they’d be useful to clients. In some cases, we suggested ideas the clients had literally suggested but which were lower on the voting list than ones the Marketing identified as committed to the release. So, as we began to announce what features would be in the release, end customers were really happy to see everything they had voted for making it as well as other things they had not expected we would deliver.<br />
<br />
A couple months before the meeting, all the functionality was done as was all the user documentation. Actually, the documentation had been settled upon a month before that. The doc folks were just doing their own formatting and example insertion work. Examples often came from our test examples. In deed, tests we used often came from ideas Marketing had for typical user request streams. During the last two months, we started working more with performance improvements and internal structural changes. No new functionality was being worked. All defects found during that time were due to internal issues and had no functionality impacts, i.e., no missing or misunderstood requirements.<br />
<br />
At the Spring meeting, customers seemed really excited by the work we had done. They loved all the functionality as well as hearing, despite all that was added, that both memory footprint had been reduced and performance had been improved. There was also an explosion of functionality ideas from clients coming out of the meeting. (As the formal release date was early summer each year, we were able to incorporate a number of these successfully before the actual release, so clients did not have to wait a year for them.)<br />
<br />
In the process of making all these changes, we introduced no major defects and, in fact, found two serious defects that had been plaguing us on large reports and on customer system configuration changes, i.e., whether they allocated dynamic memory above or below the base load address of the main system modules.<br />
<br />
We never had a name for how we operated. It clearly wasn’t “Agile” in many aspects, but I think we hit every Manifesto Value dead on and several of the Principles.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com1tag:blogger.com,1999:blog-224928398513703850.post-70607654721797129302009-10-19T06:30:00.001-04:002009-10-19T06:31:08.181-04:00Common Project Risks and Agile Mitigations, Part 5, Technology<a href="http://agilesoftwarequalities.blogspot.com/2009/10/common-project-risks-and-agile_12.html">Part 4</a> addressed the topic of creating an initial plan (i.e., planning and estimation). This part will address a category of issues that can lead to project failure which was surprisingly high in the number of times mentioned: technology.<br />
<br />
<em>Technology Related Issues</em><br />
<br />
The particular issues related to technology mentioned in the various survey sources include two types. The first is application technology, revealing itself through<br />
<br />
<ul><li>Complex technical details (often hard to recognize or address early in a project)</li>
<li>Lack of sufficient technology competence to address the complexity.</li>
</ul>The second is development process technology, revealing itself through<br />
<br />
<ul><li>Poor up-front (inflexible, inadequate) architectural planning</li>
<li>Lack of effective, practical ways to show one approach is better than another.</li>
</ul>Another item also mentioned in connection with these was that technical decisions may be made by people without expertise in the domain, but with the managerial authority to make those decisions. One could argue that that this is not a technology matter, per se, as non-technical decisions could as easily be made under the same circumstances. But it was mentioned, so I wanted to note it.<br />
<br />
<em>Applicable Agile Values and Principles</em><br />
<br />
The Agile Values and Principles that seem to apply are those associated with individual & team performance and design approaches as well as frequent software delivery.<br />
<br />
With regard to application technology, if a commitment has to be made early to such directions before other work occurs, such commitments, if “wrong,” will unquestionably have a strong, negative impact on project success. The Agile approach is characterized by two phrases often seen in Agile literature: making decisions at “the last responsible moment” and focusing on “the simplest thing that could possibly work.” Key here, of course, are “responsible” and “could possibly work.” While Agile “embraces change” and seeks to “inspect and adapt,” that does not mean things are done ad hoc. It would be irresponsible not to make decisions using the best information possible, at that moment. However, to make progress and gain more information usually requires moving ahead, incrementally, at the point when a decision must be made (“the last responsible moment”) using that information in the most direct, clear manner known at that time (“simplest thing that could possibly work”). (Naturally, in a very complex domain, “the simplest thing” is still going to be complex, but likely better to deal with than a more complicated complex thing.)<br />
<br />
Regarding technical competence, especially in software, it can be quite difficult to assess because the evidence is often buried within the code and not obvious, especially in phased, sequential efforts, until very late in the project schedule when various pieces are integrated into the larger system. Agile techniques such as collective code ownership, pairing and general visibility within the team are one way this information can be revealed sooner rather than later. Also the Principles of commitment to continuing technical growth and regular reflection on how to work better provide a path toward increasing individual, team and project competence on a regular basis.<br />
<br />
These latter Agile techniques and Principles apply equally as much to the issue of development process technology, including architectural planning. There is always the question of how much up front work is necessary before useful progress can begin. The answer is usually less than might otherwise be expected if working software is delivered early and frequently thereafter since there will be concrete evidence of what “works” and what does not. In a complex project, what this will require is close communication between any architecture groups and development teams and a willingness of the former to work iteratively and incrementally rather than in a purely phased, sequential manner.<br />
<br />
This latter point is often the most challenging organizational issue faced early in an Agile adoption effort since adoption efforts often start within development teams, perhaps with some test participation, but often without direct involvement of other technology-based teams. Architectural teams are one; configuration and change control teams are another; very often build and deployment teams are a third. Failure to incorporate these areas into the Agile effort can produce, at best, delays and limitations on the velocity achieved by teams since other groups usually work in a less iterative manner. They will engage in more up-front planning, expect less frequent changes and follow well-defined timelines for availability later in a typical project cycle as they do for non-Agile projects.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-66934254652871741412009-10-17T09:21:00.000-04:002009-10-17T09:21:50.803-04:00And More Quotes From TwitterA fourth installment of interesting things I've captured from Twitter that people have said (including some of my own) either individually or as part of a thread of discussion (again sorted by first name):<br />
<br />
Alan Shalloway - biggest difference between adopting Lean now from adopting agile 10 yrs ago is customers r now more open-minded than th consultant community<br />
<br />
Bob Marshall - Common insight from Reinertsen, Goldratt, Seddon: Manage *queues*, not schedules, capacity, efficiency or costs.<br />
<br />
David Hussman - Detailed requirements are poorly written tests or what I call "tests in disguise".<br />
<br />
David Hussman: Project communities are bonded by common goals not by percentage of availability on org charts.<br />
<br />
Declan Whelan - I tire of people saying we were successful w/o agile as if success is binary. Agility fosters the ability to expand success.<br />
<br />
Eric Hoffer (via Steve Freeman) - “Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket.”<br />
<br />
Gloria Steinem (via Suhas Walanjoo) - The truth will set you free. But first, it will piss you off.<br />
<br />
James Bach - 3-word critical thinking process: Huh? Really? So? (question meaning, then question fact, then question significance)<br />
<br />
Jason Gorman - 1. Hire good programmers. 2. Give them clear goals. 3. Give regular constructive feedback. 4. Stay out of the way!<br />
<br />
Jason Yip - Isn't it kind of weird that Japan has a Deming prize and the US has a Shingo prize?<br />
<br />
Jean Tabaka - Scrum vs Kanban vs other systems/certification debates distract vs focus. Continuous systems improvement jazzes me. Pick & focus.<br />
<br />
Marcin Niebudeck - What I find the most difficult in #agile transition is not the legacy code, but the legacy people. For legacy code we have already good engineering techniques from #xp. What do we have for legacy people?<br />
<br />
Mark Twain (via Will Green) - Never argue with an idiot. He will drag you down to his level and beat you with his experience. Scott Duncan - A variation "Never argue with an idiot. Onlookers may not be able to tell the difference." Both from Twain, I think.<br />
<br />
Niklas Bjørnerstedt (via Kent Beck blog) - A good team can learn a new domain much faster than a bad one can learn good practices.<br />
<br />
Scott Duncan - I am just not convinced the way to combat dysfunction is with more easily dismissed forms of dysfunction.<br />
<br />
Scott Duncan (From the movie "Nightwatch") - "It's easier for a man to destroy the light within himself than to defeat the darkness all around him." (Anna Nachesa said the actual translation from the original Russian is: “It's always easier to put out the light within yourself than to cast away the darkness outside.”)<br />
<br />
Tim Ottinger - I think that the agile motto should be "Building a better next week."<br />
<br />
Timothy L. Johnson (via Josh Nankivel from Twitter)- Changing the world, surprisingly, looks a lot like living your life... day to day... with purpose... with focus... and with love. And there are days when looking at yourself in the mirror at the end of it all... and smiling... is really the best accomplishment. (28 September 2009)<br />
<br />
Tobias Mayer - Scrum & XP are incomparable. Scrum is a framework for organizational change, XP for individual craftsmanship.<br />
<br />
Unknown (via Kim Coles) - "The world is so fast that there are days when the person who says it can't be done is interrupted by the person doing it.”<br />
<br />
Vasco Duarte - My def: "a method scales iff the effort needed to manage "things" grows at a slower rate than the number of "things"."<br />
<br />
Will Rogers (via Ainsley Nies) - “Even if you're on the right track, you'll get run over if you just sit there.”<br />
<br />
William W. (Woody) Williams - Highly motivated, productive people working in the wrong direction do huge damage in a short time.<br />
<br />
Willie Colon (via Roy Atkinson) - The capacity to learn is a gift; The ability to learn is a skill; The WILLINGNESS to learn is a choice.<br />
<br />
Yves Hanoulle - "A shared vision is about shared state, not about a shared statement."Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-77810189290986488582009-10-12T07:49:00.000-04:002009-10-12T07:49:06.278-04:00Common Project Risks and Agile Mitigations, Part 4, Project & Risk Management<a href="http://agilesoftwarequalities.blogspot.com/2009/10/common-project-risks-and-agile_08.html">Part 3</a> addressed the topic of creating an initial plan (i.e., planning and estimation). This part will address related categories of issues that can lead to project failure: project and risk management.<br />
<br />
<em>Project Management Related Issues</em><br />
<br />
To hearken back a bit to the last part, consider some thoughts from Tom DeMarco [May] in noting how a “Lean and Mean” emphasis in companies has “goaded” managers and staff into unreasonable estimates and the need for overtime work. “Any failure will be viewed as a direct result of underperformance,” DeMarco says. However, underperformance is “not even a significant [project failure] factor” for most projects compared to simply having initially unattainable goals.<br />
<br />
Now consider some remarks from Ed Yourdon, quoted in [May] saying, “Nobody seems to acknowledge that disaster is approaching” even when they recognize it. “There is no early warning signal.” May goes on to state Yourdon’s belief that, “Until more organizations abandon waterfall-style development in favor of processes that demand early working code or prototypes…this scenario will continue to be familiar.”<br />
<br />
The particular issues related to project and risk management mentioned in the various survey sources include:<br />
<ul><li>Failure to apply (or understand) essential project management techniques and/or project control systems (e.g., tracking, measurement).</li>
<li>Inadequate visibility of progress (not just resources used) generally due to status reporting being misleading (e.g., generally more optimistic than pessimistic) or not having effective means of tracing a software development from requirements to completed code.</li>
<li>Not proactively managing risk or basing actions on “catching up” later (e.g., counting on overtime to handle contingencies).</li>
<li>Lack of knowledge of the actual probability of success, late failure warning signals, and reduction in resources needed for the project.</li>
</ul>The first of the issues noted above argues for traditional project management capabilities being needed. Yet, though such capabilities might, on the surface, be present, the latter three problems could still occur because of the things DeMarco and Yourdon mention. Part 3 mentioned some ways to try to address DeMarco’s concerns. In this part, Yourdon’s concern should also be addressed.<br />
<br />
<em>Applicable Agile Values and Principles</em><br />
<br />
Again, all the Agile Values and most of the Principles seem to apply in one way or the other.<br />
<br />
The first problem noted above could just as easily be an issue in an Agile project if the techniques and principles for how to conduct one are either not applied or understood. The key in an Agile project is that these techniques are very near-term, direct and based on visible indicators of what is happening every day rather than at weekly/monthly status reporting occasions. This promotes the Agile Principle of simplicity, especially in process and tools, applied to project management by taking advantage of close, regular communication among project stakeholders and regular reflection on and adjustment to plans and project conduct. Because of all this, an Agile project will not engage in “Project Management Chicken” where everyone waits to see who will be the first to have to admit they are behind schedule.<br />
<br />
Another important concept is how Agile projects measure progress based on working software rather than tasks accomplished. While it is true that an iteration burndown may track task, the ultimate measure of success will be completion of the committed to functionality and its acceptance by the customer. This is Agile’s “highest priority” and, as in planning, employs short timeframes (e.g., a few weeks) as the cycle for ensuring project direction meets customer expectations. And, as the demonstration of achievement of iteration goals is a very visible event, surprises are very unlikely if stakeholders maintain involvement with the team(s).<br />
<br />
Finally, as noted in Part 3, planning is organized to make changes easier, less costly, and very visible. Agile project management, then, is focused on how to best respond to change and address risks right away. Indeed, a risk-based approach to managing projects is very much in keeping with Agile principles. However, rather than try to defend against change and risk, Agile projects take advantage of the near-term focus and visibility to accommodate change and surface risks early. (Jim Highsmith has some good advice related to what he calls a “<a href="http://blog.cutter.com/2009/10/09/planning-and-scanning-adapting-isnt-always-the-solution/">Planning and Scanning</a>” approach to managing projects, encouraging us to “expand our anticipation practices to include both planning (working with what we know), and scanning (looking ahead to learn the unknown as quickly as possible).”)<br />
<br />
Regarding surfacing issues early, I have experienced managers responding to an Agile approach with the feeling, at least initially, that all they hear about day after day are the impediments the team is dealing with and the issues that need to be addressed. However, after a while, they see that these are issues that usually get dealt with immediately and which go on all the time, but are often not made visible in traditional projects. It is the visibility of the issues that initially produces the discomfort but, as time progresses, then produces greater confidence that teams are managing work well and ensuring stakeholders are kept informed. In this way, if large issues emerge, they are recognized earlier and addressed more promptly. This does not necessarily make them automatically easier to deal with, but does mean you’ll be dealing with them earlier, rather than later, increasing the likelihood of dealing with them at the least cost to the project.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0tag:blogger.com,1999:blog-224928398513703850.post-6298136811335786672009-10-08T11:27:00.000-04:002009-10-08T11:27:38.076-04:00Common Project Risks and Agile Mitigations, Part 3, Planning & Estimation<a href="http://agilesoftwarequalities.blogspot.com/2009/10/common-project-risks-and-agile.html">Part 2</a> covered issues related to requirements as the number one issue plaguing projects. This part will address two of the next most frequently mentioned category of issues that can lead to project failure: planning and estimation. Planning was the next most frequently mentioned category, but estimation, which is highly related to planning, was also high on the list. Therefore, these two have been combined to be discussed together.<br />
<br />
<em>Planning & Estimation Related Issues</em><br />
<br />
As with requirements, the fact that planning is a problem area should come as no surprise. Making plans, getting agreement to them, managing the project using the plan, and making changes to a plan all involve substantial effort. Later, project management will be discussed. But, for this post, the focus will be on creating a plan.<br />
<br />
The particular issues related to plan creation/initiation mentioned in the various survey sources include:<br />
<br />
<ul><li>Allowing a plan to diverge from project reality, or to be created which diverges from that reality in the first place, due to lack of estimation experience, estimation under pressure, rejection of reasonable estimates (usually resulting in underestimation), ignoring the obvious (e.g., back-of-the-envelope calculations), and/or not revising plans if scope changes.</li>
<li>Failure to plan, adequately or at all, to consider all project activities, to address risk management, or to inadequately document decisions and commitments (leading to later disagreements, disappointments, and costly rework).</li>
<li>Infrequent project milestones (i.e., project "chunks" too large), allowing too much time to elapse between opportunities to validate that work done meets intended needs.</li>
</ul>A telling comment from Watts Humphrey (as quoted in [May]) is that “any plan [project managers] put together won’t meet the [desired release] date, so they can’t plan.” Additionally, May asks states, “It is unfair to call a project a failure if it fails to meet budget and schedule goals that were inherently unattainable. Attempts to circumvent a project’s natural minimum limits will backfire. This problem occurs any time someone ‘makes up a number and won’t listen to anyone about how long other projects took,’ said Capers Jones.”<br />
<br />
There are also famous quotes (mostly from the military) about planning and what happens when plans start to be executed such as “a battleplan never survives contact with the enemy” and “plans are not important, but planning is everything.” Interestingly, the formality, rigor, and hierarchical control structure of the military is classic, but the military also realizes how important it is for the people on the front lines to be prepared to inspect and adapt. Remember Clint Eastwood’s comment as Gunny Highway in “Heartbreak Ridge” regarding plans and response to situations in the field: “Improvise. Adapt. Overcome.”<br />
<br />
<em>Applicable Agile Values and Principles</em><br />
<br />
As with the requirements category, most of the Values and Principles also seem to apply to planning and estimation.<br />
<br />
The key in Agile-based planning (as with requirements specification) is simplicity born of close collaboration with the stakeholder(s) and frequent validation that work is meeting needs. Because of the iterative and incremental nature of an Agile approach, detail is reserved for the near-term with progressively less detail the further out the planning goes. This approach is taken to reduce the initial cost of detailed plans which, in all likelihood, will be changing anyway.<br />
<br />
Because of this willingness to change plans if stakeholder needs and priorities change, Agile planning (and validation of the planning), as an activity, occurs frequently (i.e., daily, every few weeks). In this way, the plan will not diverge far from reality, can be adapted easily when changes occur, and will not consume significant effort to maintain. Most importantly, all planning is based on the regular, frequent delivery of working functionality as the basis for assessing the validity of the development activity.Scott Duncanhttp://www.blogger.com/profile/12817276021002716934noreply@blogger.com0